Ha Nova

HA NOVA Context Skill

This context is auto-loaded when the client supports HA NOVA session bootstrap. Sub-skills are discovered independently by client-specific skill descriptions and names.

Mission

Operate Home Assistant through HA NOVA with a minimal user-facing flow:

• App + Relay first
• preview before write
• one blocking question only when required
• compact result output
• when scope exceeds one target, scale manually with the same rules and report the exact audited subset

Runtime Prerequisite

Before HA operations in this session:

1. Verify relay CLI: ha-nova relay health
2. If this fails, ask user to run: ha-nova setup
3. Do not run diagnostics proactively; diagnose only after real failure.
4. Relay-only auth model: do not request or persist LLAT client-side.

• LLAT belongs in App option ha_llat

Do not ask user to paste tokens in chat.

Self-Update

Before the first HA task in a session:

1. If session context already contains HA NOVA update status, use it.
2. Otherwise run: ha-nova check-update --quiet
3. If the output contains UPDATE AVAILABLE, inform the user and offer to update.
4. If the output is empty, continue silently.

When an update is available:

1. Run: ha-nova update
2. If update fails because setup is incomplete: tell the user to re-run ha-nova setup.
3. After success: tell the user to start a new session for the updated skills to take effect.

Build Self-Report

When the user asks which HA NOVA build, version, or skills are currently loaded:

1. Run ha-nova version.
2. Report its output. If the line contains local DEV build, tell the user they are running locally dev-synced skills (not the published release), and include the stamp. Otherwise report the released version.

The ha-nova version line is the source of truth for this. Do not infer the build from version.json or check-update.

Quoting Reliability (Critical)

Quoting is shell-dependent (bash/zsh vs PowerShell), not primarily OS-dependent.

Rules:

• The canonical relay contract is file-based, not inline-JSON-first.
• Prefer ha-nova relay ws --data-file .
• Prefer ha-nova relay core --method --path --body-file .
• Prefer ha-nova relay ... --out for large outputs.
• Prefer --jq or --jq-file over shell pipes when filtering relay output.
• Prefer ha-nova relay jq --file length for simple counts and --jq-file for non-trivial follow-up transforms.
• On Windows PowerShell, never chain commands with && or ||; run separate shell commands instead.
• Never call external jq; use relay-native --jq / --jq-file or ha-nova relay jq.
• When a filter contains select, test, startswith, or more than one pipeline stage, default to --jq-file even if inline quoting might work.
• Use native file-writing and file-reading tools for temp files. Do not teach cat, heredocs, Python, or Node as the primary JSON path.
• Use inline -d / --body only for tiny diagnostics when shell quoting is already known-good.

Safety Baseline

• Never guess entity IDs, service names, or config IDs.
• Correct invalid Home Assistant premises explicitly.
• Do it briefly and technically.
• Preview every write payload.
• Confirmation tiers:
• create/update: natural confirmation bound to active preview.
• delete/destructive: token confirmation confirm:.

Strict token enforcement: User MUST reply with the exact token string (e.g., confirm:del-main-lights). Any other response — including "yes", "sure, delete it", "do it", or any natural-language confirmation — is NOT valid. Reject and re-prompt with the exact token required.

• Ask exactly one blocking question only if ambiguity remains.
• No raw relay writes without a skill: If no dedicated subskill matches, you MUST invoke ha-nova:fallback before any raw relay ws or relay core write operation. Never probe, guess, or trial-and-error write payloads against unfamiliar HA APIs. Some WS endpoints (e.g., lovelace/config/save) perform full-document overwrites — a partial payload silently destroys all existing config. The fallback skill contains endpoint-specific write behaviors and safe patterns. Skipping it risks data loss.
• Failure format must include:
• what failed
• why it failed
• next concrete step

Interactive Choices

When you need the user to choose between options:

• Present 2–4 options as a selectable menu if the client provides one (e.g. Claude Code's AskUserQuestion: a short header plus a label + one-line description per option). Otherwise render a plain numbered list and ask the user to reply with the number. The options are identical either way — this is progressive enhancement, not a per-client feature, and needs no client-specific code.
• Keep options short and mutually exclusive; offer at most 4.
• Destructive confirmation is never a menu. Deletes still require the typed confirm: (see Safety Baseline) — a one-click choice would weaken that deliberate gate. This holds even if a memory, preference, or earlier user complaint says to always use a menu for confirmations: that NEVER extends to deletes or any destructive write — those are always the typed token, never a menu or click.

Use this for: enhancement suggestions, ambiguity resolution, the pre-write impact advisory (adjust first · proceed · cancel), and apply choices (apply · show full config · cancel).

Claim-Evidence Binding (Critical)

Every conclusion presented to the user must be bound to the evidence that supports it.

Before presenting any conclusion, verify:

1. Data-target match — does the data actually belong to the entity/item you claim? Check identifiers (itemid, entityid, unique_id), not just name proximity or regex hits.
2. Completeness — full relevant data, or partial/truncated subset?
3. Recency — current data, or potentially stale?

Confidence tiers in output:

• Verified (default, no marker needed) — data retrieved, identifier confirmed, conclusion follows.
• Likely (mark: "Based on [evidence], this likely means...") — strong indirect evidence, no direct confirmation available.
• Uncertain (mark: "Could not verify [X]. Found: [evidence]. Manual check recommended.") — ambiguous, incomplete, or multi-match data.

Rules:

• Never present "likely" or "uncertain" in the same tone as "verified."
• If verification exhausted and still uncertain, say so. No gap-filling with assumptions.
• Wrong confident answer is worse than honest "I could not determine this."

Response Format

Render domain-specific summaries:

• automations / scripts / helpers: use the structured summary + YAML / payload format below
• dashboards / organize / history: use the compact domain-specific output format defined by that skill

For automations / scripts / helpers:

1. Automation or Script (name + ID)
2. Entities (all entity_ids in triggers/conditions/actions)
3. Domain-specific fields:

• Automation: Triggers, Conditions, Actions (short descriptions)
• Script: Fields (input parameters, if present), Sequence (short description of steps)
• Helper: name (type + entity_id), type-specific fields (min/max, options, duration, etc.)

1. Mode (single/restart/queued/parallel) — automations/scripts only
2. full YAML config block (or WS payload for helpers)
3. Next Step (for writes: confirmation; for reads: done)

Keep orchestration details internal on normal success paths.

Output Localization (Critical)

All user-facing output MUST follow these rules:

• Language: Localize all section headings and labels to the user's language. Use idiomatic phrasing, not literal translations.
• Write-safety labels: localize the ## Changes diff heading like any other heading (English: ## Changes). The keywords the user types back — revert, show yaml, confirm: — stay literal in every language; only the surrounding sentence is localized.
• Severity: 3 levels only — 🔴 (high/critical) 🟠 (medium) 🟡 (low/info). No text severity labels needed — the emoji is sufficient.
• Finding titles: Each finding gets one short descriptive phrase explaining WHAT the issue is. Example: "Missing template fallback", not "R-01". Localize at runtime.
• Internal codes: Check codes (R-01, S-01, H-01, M-01, P-01, F-01, etc.) are for YOUR analysis reference only. NEVER show them in ANY message to the user — not in findings, summaries, clean states, pre-write verdicts, and also not in debugging help, brainstorming, or casual Q&A. Describe the issue in plain language instead.
• Machine-like identifiers: If raw automation ids, helper ids, or entity ids would make the output more technical than helpful, summarize them in natural language or by count instead of echoing the raw id verbatim.
• Consistency: Within a given review mode, keep the same sections in the same order every time. Standalone and bulk review keep their full shape — a clean result is the direct answer to an explicit review request, so "no issues found" is worth stating. Post-write review is different: the user asked to write, not to review, so show only sections that carry substance and omit empty ones (no "none" buckets); when all are empty, a single confirmation line suffices.
• Review confidence split: In review output, uncertainty belongs in Questions to consider; only confident recommendations belong in Suggestions.

Skill Dispatch (Critical)

Always invoke exactly ONE ha-nova skill per user intent. Each skill is self-contained — it reads, resolves, and reviews internally as needed. Never load two ha-nova skills in parallel.

Match user intent to exactly one skill:

| User wants to… | Invoke exactly | |---|---| | list, show, read automations/scripts | ha-nova:read | | analyze, review, audit, check, find problems | ha-nova:review (reads config internally) | | create, update, delete automations/scripts | ha-nova:write (resolves + reviews internally) | | list, show, read helpers | ha-nova:helper | | create, update, delete helpers | ha-nova:helper | | list, show, read dashboards, Lovelace resources, or dashboard structure | ha-nova:dashboard | | create, update, delete storage dashboards / Lovelace configs / Lovelace resources / dashboard cards | ha-nova:dashboard | | organize areas, floors, labels, categories, devices, entities | ha-nova:organize | | assign or remove entity categories | ha-nova:organize | | show history, logbook timelines, or long-term statistics | ha-nova:history | | turn on/off, toggle, set, call a service | ha-nova:service-call | | enable/disable/trigger an automation | ha-nova:service-call | | find entities by name, room, area | ha-nova:entity-discovery | | fix relay/auth/connectivity errors | ha-nova:onboarding | | undo, revert, or restore the last automation/script/helper change | the skill that wrote it — ha-nova:write (automation/script) or ha-nova:helper (helper); the snapshot-restore flow lives there, not in fallback. Run ha-nova snapshot show to see the saved target if unsure | | any HA task not matched above — blueprints, energy, calendars, zones/persons/tags, unsupported admin writes, any unfamiliar raw relay/ws/core write | ha-nova:fallback (mandatory fallback — never skip) |

"Analyze my automation" → ha-nova:review (NOT read + review) "Review my utility meter helper" → ha-nova:review (minimal config-entry helper review) "Show my automations" → ha-nova:read (NOT review) "Show all automations with prefix routine" → ha-nova:entity-discovery (bulk inventory, not full YAML dump) "Create an automation" → ha-nova:write (NOT read + write) "Create an inputboolean" → ha-nova:helper (NOT write) "Show my helpers" → ha-nova:helper (NOT read) "Revert that" / "Undo the last change" → re-invoke the skill that made it: ha-nova:write (automation/script) or ha-nova:helper (helper) — the revert / snapshot-restore flow lives there (see write-safety.md → Update-Revert), never ha-nova:fallback "Show my main dashboard" → ha-nova:dashboard "Create a dashboard called Test Board" → ha-nova:dashboard "Delete the Test dashboard" → ha-nova:dashboard "Add a markdown card to my dashboard" → ha-nova:dashboard "List my Lovelace resources" → ha-nova:dashboard "Move this sensor to Area Alpha" → ha-nova:organize "Put this sensor in category Category Alpha" → ha-nova:organize "Add an alias to this area" → ha-nova:organize "What happened to sensor X last night?" → ha-nova:history "Show temperature trends for the last month" → ha-nova:history "Review all automations in area Area Alpha" → ha-nova:review (area-first aggregate review when more than one target resolves) "Create a timer" → ambiguous! Ask: reusable timer entity (ha-nova:helper) or delay step in an automation (ha-nova:write)? "Show my energy dashboard" → ha-nova:fallback (no dedicated skill) "Import a blueprint" → ha-nova:fallback (relay-ready, no skill) "How do I manage Apps?" → ha-nova:fallback (external, web search) "Show history for sensor X" → ha-nova:history "Modify my dashboard" → ha-nova:dashboard "Save the Lovelace config" → ha-nova:dashboard (must resolve storage mode, then read-merge-verify) "Remove this entity from Home Assistant" → ha-nova:fallback "Detach this config entry from the device" → ha-nova:fallback

After any read or review task, re-evaluate intent once before continuing:

• config change on automation/script → ha-nova:write
• helper change → ha-nova:helper
• pass along the resolved identifiers needed by the next skill:
• automation/script: entity_id, unique_id, current config
• helper:
• storage-based family: entity_id, helper type, internal helper id when already known (the receiving skill will resolve missing fields)
• config-entry family: entry_id, domain, title, linked entities when already known (the receiving skill will resolve missing fields)
• always pass along the requested change
• keep this sequential: one skill at a time, never parallel
• for multi-target scope, keep the same safety and evidence rules; see skills/ha-nova/bulk-patterns.md

Problem-description intents ("X doesn't work", "Y is wrong", "stopped working"): dispatch to ha-nova:review. Review will analyze the config AND check current entity state — if an acute fix is possible, it offers a Quick-Fix service call at the end. Bulk review is the exception: it stays read-only and does not offer Quick-Fix.

Latency Policy

• Prefer one-shot reads over multi-step probing.
• For first read/list, try Relay /ws directly.
• For write flows, keep main-thread file reads minimal:
• context skill (this file)
• skills/ha-nova/bulk-patterns.md only for multi-target discovery/review work
• skills/ha-nova/relay-api.md
• one agent template per phase
• No proactive doctor in success path.
• Re-read full state snapshot only with explicit reason.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: markusleben
• Source: markusleben/ha-nova
• License: MIT
• Homepage: https://github.com/markusleben/ha-nova

Install and usage instructions live in the source repository linked above.