Home Assistant Dashboard Designer

Home Assistant Dashboard Designer is a public skill by CCOSTAN from the standalone Home-Assistant-Codex-Skills repository. The original Smithery registration pointed to codex_skills/homeassistant-dashboard-designer inside the larger Home-AssistantConfig repository. According to the commit history, that path was moved into a dedicated repository. The currently reachable primary source is homeassistant-dashboard-designer/SKILL.md, accompanied by reference material, a Lovelace validator, and focused tests. The skill is working guidance for Codex, not a Home Assistant server, a finished dashboard application, or a replacement for official Home Assistant documentation.

Purpose and inputs

According to the provider, the skill supports planning, updating, and refactoring Lovelace views written in YAML. Users should state the goal, the exact view or partial path under config/dashboards, screen-size requirements, and areas that must not change. When those details are missing, the instructions call for focused questions rather than an uncontrolled broad edit. The source names infrastructure, home, energy, and environment as possible intents. A view should retain one clear intent so that its layout, metrics, and entities remain understandable.

Layout and components

The primary structure uses grid and vertical-stack with limited nesting. Horizontal stacks inside grid cells, freeform positioning, and layout logic inside card-mod are avoided. The source recommends custom:button-card first, with styling kept in centralized templates. card-mod is reserved for shared visual rules. Flex Horseshoe cards and Mini Graph cards are intended for one clearly defined metric at a time. Core cards such as entities or history-graph remain fallbacks that should be justified. Templates should be reused, and new templates should not be created without explicit instruction. These rules reduce visual drift, diff size, and hard-to-review special logic.

Validation and limits

Before editing, the target repository, includes, templates, and local instructions should be read. According to the provider, an available Home Assistant MCP must be used to check entities, services, and payload fields. If the MCP is unavailable, entity or service identifiers must not be invented; repository configuration and official integration documentation should be used instead. Existing dashboard validators, a Home Assistant configuration check, and the included validator should then run. Passing a YAML check proves neither that measurements are correct nor that the resulting presentation is meaningful.

Security and responsibility

A dashboard can expose private device, presence, energy, and environmental data. File and network access should remain limited to the intended project. The skill does not request credentials, tokens, or private keys, and such values must not appear in YAML, examples, logs, or skill files. An MCP or connected model provider may process inputs and results outside the local machine; local YAML storage does not prove local model processing. Prefer read access first. Changes to dashboards, services, scenes, or automations require human confirmation, explicit target review, and a recoverable rollback before application. Automated decisions cannot reliably eliminate wrong entities, stale states, or ambiguous intent. Therefore test changes in a non-production copy first, review the diff, and keep a recovery path. Actions such as switching, restarting, locking, unlocking, or triggering an automation must not follow solely from a plausible model response. A model cannot reliably know local safety rules, resident preferences, or physical consequences. The standalone repository is MIT licensed under its published terms, but that does not replace checking the Home Assistant version, custom cards, integrations, or local operating rules. A successful browser rendering also does not prove that a device is reachable or that an automation is correct.