Document Home Assistant MCP validation for dashboard skill

codex_skills/homeassistant-dashboard-designer/README.md

@@ -67,6 +67,25 @@ Invoke in chat:
 
 Then provide the structured intent block described in `SKILL.md` (dashboard intent, view name, entity map, and layout constraints).
 
+## Home Assistant MCP (Built-In) Enablement
+
+The Home Assistant MCP lets Codex validate entity IDs and service calls against your *real* HA instance before it edits YAML.
+
+1. Create a Home Assistant Long-Lived Access Token (Profile page in HA).
+2. Set an environment variable (do not commit tokens):
+   - `HOMEASSISTANT_MCP_AUTH=Bearer <your_long_lived_access_token>`
+3. Add this to your `~/.codex/config.toml`:
+
+```toml
+[mcp_servers.homeassistant]
+url = "http://<your-ha-host>:8123/api/mcp"
+env_http_headers = { "Authorization" = "HOMEASSISTANT_MCP_AUTH" }
+```
+
+Notes:
+- Use `https://` if your HA is behind TLS.
+- Keep tokens in environment variables, not in files under git.
+
 ### Notes
 - This skill intentionally contains no secrets. Configure MCP credentials via environment variables in your local Codex setup.
 
@@ -84,4 +103,3 @@ Then provide the structured intent block described in `SKILL.md` (dashboard inte
 <a href="https://www.vCloudInfo.com/p/affiliate-disclosure.html">
 Affiliate Disclosure
 </a></p>
-

codex_skills/homeassistant-dashboard-designer/SKILL.md

@@ -127,7 +127,9 @@ Max layout nesting depth: 2. No horizontal-stack inside grid cells.
 
 1. Read the target dashboard/view/partials/templates to understand existing patterns and avoid drift.
 2. Determine intent: `infra` (NOC), `home`, `energy`, or `environment`. Keep one intent per view.
-3. Validate entities and services before editing (prefer Home Assistant MCP live context; otherwise ask user to confirm entity IDs).
+3. Validate entities and services before editing:
+   - Prefer the Home Assistant MCP for live entity/service validation (required when available).
+   - If MCP is not available, ask the user to confirm entity IDs and services (do not guess).
 4. Draft layout with constraints: a top-level `grid` and optional `vertical-stack` groups.
 5. Implement using Tier 1 cards first; reuse existing templates; avoid one-off styles.
 6. If fallback cards are necessary, add an inline comment explaining why Tier 1 cannot satisfy the requirement.
@@ -141,3 +143,16 @@ Max layout nesting depth: 2. No horizontal-stack inside grid cells.
 ## References
 
 - Read `references/dashboard_rules.md` when you need the full constraint set and repo-specific mapping notes.
+
+## Home Assistant MCP Validation (Required When Available)
+
+Before writing Lovelace YAML, confirm:
+- Every `entity:` (and any entities referenced via variables) exists.
+- Every service you plan to call exists and the payload shape is correct (especially `service_data`).
+
+When Home Assistant MCP is enabled, use it to:
+- List/confirm entities (avoid typos like `sensor.foo_bar` vs `sensor.foobar`).
+- Confirm the dashboard card references match real entities.
+- Validate service names and fields before committing YAML changes.
+
+If MCP is not enabled or not reachable, stop and ask for the missing entity/service IDs rather than inventing them.

codex_skills/homeassistant-dashboard-designer/references/dashboard_rules.md

@@ -117,3 +117,11 @@ If working in this repo's `config/dashboards/` tree:
 - Includes must use absolute container paths starting with `/config/`.
 - Views are one file per view, and the dashboard file uses `!include_dir_list`.
 - Files under `config/dashboards/**/*.yaml` must include the standard `@CCOSTAN` header block.
+
+## Validation (Home Assistant MCP)
+
+When available, use the Home Assistant MCP to validate:
+- Entity IDs referenced by Lovelace cards/templates.
+- Service names and payload fields used by actions (for example, `button.press`, `script.*`, etc.).
+
+If MCP is not available, do not guess entity IDs. Ask the user to confirm them.