# Home Assistant Frontend > Home Assistant frontend skill routing and personal engineering overlays. Use when editing or reviewing the Home Assistant frontend so repository-local `ha-frontend-*` skills stay authoritative and applicable Lit, TypeScript, cleanup, and HA companion skills are also loaded. - Skill: `timmo001/home-assistant-frontend` (Agent Skill) - Install (CLI): `npx skillmds@latest add timmo001/home-assistant-frontend` - Raw SKILL.md: https://api.skillmd.com/api/skills/timmo001/home-assistant-frontend/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - License: Apache-2.0 - Author: timmo001 (https://skillmd.com/u/timmo001) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/timmo001/home-assistant-frontend --- # Home Assistant Frontend Use this skill when working in the Home Assistant frontend repository or on code that follows its conventions. It routes to the project's own guidance and adds only cross-project engineering preferences. ## Primary Source of Truth The frontend repository owns Home Assistant implementation conventions through its `AGENTS.md` and `.agents/skills/ha-frontend-*` skills: 1. Read the repository's applicable instructions before editing or reviewing. 2. Discover and load every applicable repo-local `ha-frontend-*` skill based on its description. 3. Treat those repo-local skills as authoritative for components, contexts, styling, testing, user-facing text, and review conventions. 4. Do not replace repository guidance with a global pattern or copy repository conventions into this skill. ## When to Apply - Editing files in a Home Assistant frontend checkout - Reviewing or writing `ha-*` prefixed Web Components - Working with HA dialogs, panels, Lovelace cards, or selectors - Applying HA localization, theming, or design token patterns ## Personal Overlay Layer these global skills over the repository guidance when their scopes apply: - applicable `home-assistant-*` specialists for cross-repository workflows; - applicable `lit-*` skills for Lit concerns; - applicable `*-ts` skills before editing or reviewing TypeScript; - `cleanup-*` and `remove-single-use-*` skills whenever their safe code-quality rules apply. For Home Assistant rendering or picker work, load both `lit-rendering` and `home-assistant-lit-rendering`. Preserve the stricter TypeScript and cleanup guidance unless it conflicts with an explicit repository rule. Apply these cross-project engineering preferences without overriding explicit repository rules: ### Scope And Surface - Make one independently reviewable change at a time unless batching is explicitly requested. Stay within the requested area and preserve existing semantics during migrations unless changing them is in scope. - Prefer a narrow canonical helper or shared module over callback-heavy abstractions, pass-through wrappers, widened signatures, duplicate types, or ceremonial aliases. - Challenge optional feature surface that adds network, lifecycle, consistency, or documentation cost without supporting the core task. ### Async State And Readiness - Model asynchronous UI as transitions: establish immutable baselines before awaits, guard stale responses, preserve unsaved mounted state, and classify an action's current meaning before dirty-gating it. - Treat readiness as the first displayable terminal result, including stable empty and error states. Do not resolve between a failed request and its fallback. - Every value affecting memoized output must participate in invalidation, either as an explicit key or through deliberate cache invalidation. - Model logical open and close lifecycle independently from DOM connection when managers can retain closed elements. Global-listener registration must be idempotent or return a cleanup handle. ### Processes And Input - Make check-then-act filesystem and PID operations atomic. Locks must cover every mutated shared resource, including watcher regeneration. - Terminate processes with SIGTERM, wait and verify exit, then escalate to SIGKILL. Remove process state only after confirmed exit and guard against stale PID reuse. - Handle child `spawn` and `error` events, and treat null or unknown exit codes as failures. - Reject contradictory or malformed CLI and configuration values with a positive grammar rather than permissive suffix checks. ### Test Boundaries - Keep test infrastructure changes in dedicated work. Install error tracking before navigation, assert rendered content rather than wrappers, and never let report-merging failures suppress the original failed-suite result. - Prefer watched background development servers while iterating, but treat CI as final verification when local and CI environments may differ. ## Sibling Repositories The Home Assistant core, documentation, custom cards, custom dashboards, and core packages commonly live alongside the frontend. When working across repositories, reference the available sibling checkout directly rather than guessing APIs or conventions. Follow each target repository's own instructions and skills. ### Core (`../core`) - Read the Core repository instructions when the frontend change involves backend APIs, WebSocket commands, entity models, or integration data structures. - Reference core source (e.g. `homeassistant/components//`) to understand data shapes, service schemas, and WebSocket API handlers before consuming them in frontend code. - When adding or modifying frontend calls to backend APIs, verify the API exists in core and match parameter names, types, and response shapes to the core implementation. - If asked to make changes that span both frontend and core (new WebSocket command, new entity feature), work in both repos and follow each repo's own `AGENTS.md` for its conventions. ### User Docs (`../home-assistant.io`) - Read the user documentation repository instructions when asked to create or update user-facing documentation. - Documentation for new frontend features, integrations, or UI changes goes here. - Follow the documentation repository's writing style rather than imposing global frontend copy guidance. - When a frontend change adds user-visible functionality, remind that corresponding docs may be needed and offer to create them following the docs repo's conventions. ### Developer Docs (`../developers.home-assistant`) - Developer documentation for custom cards, custom dashboards, frontend architecture, and core packages lives here (developers.home-assistant.io). - When creating or updating documentation for custom card APIs, dashboard strategies, Lovelace extensibility, or frontend development guides, work in this repo. - Reference `docs/frontend/` and `docs/frontend.md` for existing frontend developer documentation. - Core packages are cloned here — use them as reference for documenting Python package APIs and integration development patterns. - Discover and follow that repository's `AGENTS.md` and repo-local skills before making changes.