# Claude skill for Home Assistant: the product is the correction list > A Claude Code skill that teaches an agent how to work on a Home Assistant configuration. Deploy by scp, commit when stable, reload instead of restarting, verify automations by triggering them and reading the logs. The interesting part is that most of what it carries is a list of things language models get wrong. **komal-SkyNET/claude-skill-homeassistant** — Claude Code skill to supercharge and manage all Home Assistant workflows - Repository: https://github.com/komal-SkyNET/claude-skill-homeassistant - Stars: 963 · Forks: 59 - Language: Unknown - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/komal-skynet-claude-skill-homeassistant ## A skill with no code in it, and a release.txt instead of a tag The top level of the repository is .claude-plugin/, .github/, .gitignore, LICENSE, README.md, release.txt and skills/. There is no source file anywhere in that list, which is why the repository's declared primary language is empty. The product is a skill directory of instructions plus a plugin manifest, and the entire mechanism is that a coding agent reads the instructions before touching your configuration. Versioning is handled by a file called release.txt rather than by tags: the repository has no GitHub releases at all. That is a small decision with a practical consequence, since a user who wants to pin a version has nothing to pin except the text of that file on a given commit. Two demonstration videos sit near the top of the documentation, one checking that the agent can see the skill at all and one walking a full automation cycle at triple speed, which is the quickest way to judge whether the procedure is what you want. ## The marketplace route registers the skill globally The recommended install is two slash commands: ``` /plugin marketplace add komal-SkyNET/claude-skill-homeassistant /plugin install home-assistant-manager@claude-skill-homeassistant ``` They can be run from anywhere, and the documentation says they install the plugin and its skill globally for Claude Code. That word carries the decision: the Home Assistant expertise is then loaded whenever you open a Home Assistant config repository, and it is not scoped to one project or one machine. Updates have their own pair of commands, a marketplace update followed by a plugin update, so the upgrade path is also global rather than per checkout. Installation is verified with /plugin, which should list home-assistant-manager as enabled. With the manual options instead, the check is that the skill appears when Claude Code starts in the repository, which is a weaker signal because nothing confirms which version you received. ## Option two nests a git repository inside your configuration repository The manual install clones the skill into the Home Assistant config directory and then symlinks one subfolder into place: ```bash cd /path/to/your/homeassistant/config mkdir -p .claude/skills cd .claude/skills git clone git@github.com:komal-SkyNET/claude-skill-homeassistant.git home-assistant-manager-repo ln -s home-assistant-manager-repo/skills/home-assistant-manager home-assistant-manager ``` The consequence is structural. Home Assistant is expected to have a Git repository connected to its /config directory, and this puts a second, complete clone with its own .git inside that tree. A relative symlink then points from the skills folder at a path inside the nested clone. It works, and it also means the outer repository has to be told to ignore the clone, otherwise a status check shows an entire repository as untracked content. The documentation does not mention a .gitignore entry for it. The third option avoids git entirely, downloading and extracting the archive with curl piped to tar and a strip-components count, which leaves no version trail at all. ## Deploy by scp, commit when stable, and never restart to apply a change The deployment workflow is stated as a rule rather than an option. Changes go out over scp for instant testing, and Git is used for version control once the change is stable. A Git plus scp hybrid is named explicitly under workflow optimisation. Two rules protect the running instance. The skill decides whether a change needs a reload or a restart based on what changed, and it always validates before applying anything, with the stated purpose of preventing downtime. Dashboard changes have their own rule: no restart at all, because a Lovelace change is picked up with a browser refresh. That is the cheapest case in the whole system and the easiest to get wrong by reflex, since restarting is always available and always disruptive. A deployment decision tree is included to pick the path, which is the piece that turns a list of commands into a procedure the agent can follow without asking each time. ## Most of the skill is a list of what models get wrong The automation section reads as an errata list for a language model. It writes current automation YAML by default, the 2024.10 or later form with triggers, conditions and actions keys, and it insists on action: rather than the deprecated service:, giving the reason plainly: that is the syntax models tend to emit. It knows the gotcha where automation.trigger skips conditions, it knows when an automation needs mode: restart rather than mode: single, and it looks for template errors, type mismatches and execution failures. Verification is equally procedural. Automations are tested by triggering them manually and then reading the logs and traces, and the skill carries patterns for what a success indicator looks like next to an error indicator. The loop closes with an iterative fix cycle: debug, re-test, commit. The dashboard half is the same shape. Touch targets are sized for 7, 11 and 13 inch screens, card choices are narrowed to Mushroom and Tile cards with Panel against Sections views, and there are Jinja2 templates for door and window counting with colour coding, conditional display by time or state, and multi-condition indicators. ## The workflow expects SSH access and a long-lived token The prerequisites are a short list with real consequences. Claude Code must be installed and configured. The Home Assistant instance needs SSH access enabled and a Git repository connected to its /config directory. On the local side, the hass-cli command has to be installed, with pipx install homeassistant-cli given as the method, SSH key authentication configured, and two environment variables set: HASS_SERVER and HASS_TOKEN. That token is a Home Assistant long-lived access token, and it is what the agent holds while editing automation YAML, reloading configurations, reading traces and creating dashboard files. Combined with SSH into the machine, the skill is not a read-only assistant; it is a route to the house. The README does not discuss scoping that token, rotating it, or restricting which directories the SSH user can write. Those choices stay with whoever sets up the instance. ## MCP gives live tools, this gives procedure, and the case for both is made in one paragraph There is a section that answers the question a Home Assistant user asks first, which is how this differs from an MCP server. The answer is that MCP servers give the model live tools. The official mcp_server integration, or the community ha-mcp project, can read entity state, call services and control devices, but they do not teach the model how to work on your configuration. This skill carries the procedure and the judgment instead: the Git and scp pipeline, reload versus restart decisions, validating before restarting, verifying from logs and traces, template type-safety rules, dashboard storage cache gotchas, and the modern automation syntax. The argument is one sentence long and concrete. Without the skill, an MCP-equipped Claude can flip your lights, and will still happily restart Home Assistant on an unvalidated configuration or write deprecated automation YAML. Without MCP, the skill falls back to SSH and hass-cli, and the documentation notes it prefers MCP tools for live state when they exist. Official documentation is pulled in through Context7 over MCP when that is available. ## Conclusion The skill is worth reading even if you never install it, because the failure modes it names are the ones any assistant will hit on a live Home Assistant instance, and the reload versus restart discipline is the difference between a config change and an outage. Installing it is a larger decision than the two slash commands suggest: the marketplace route registers the skill globally, and the underlying workflow expects standing SSH access and a long-lived HASS_TOKEN against the house. Read it as a procedure, then decide how much of it you want an agent holding the keys for. ## FAQ ### What does the claude-skill-homeassistant skill do? It encodes Home Assistant procedure for Claude Code: a Git and scp deployment pipeline, automatic reload versus restart decisions, validating configuration before applying it, verifying automations by triggering them and reading logs and traces, and building tablet-friendly Lovelace dashboards. It ships instructions and a plugin manifest rather than code. ### How do I install the Home Assistant Manager skill for Claude Code? Through the plugin marketplace with /plugin marketplace add komal-SkyNET/claude-skill-homeassistant followed by /plugin install home-assistant-manager@claude-skill-homeassistant, which installs globally. The alternatives are cloning the repository into your config's .claude/skills folder and symlinking the skill directory, or downloading and extracting the archive. ### What does the Home Assistant skill need before it can run? Claude Code installed and configured, a Home Assistant instance with SSH access enabled and a Git repository connected to /config, the hass-cli command installed with pipx install homeassistant-cli, SSH key authentication, and the environment variables HASS_SERVER and HASS_TOKEN set. ### Is the Home Assistant skill the same thing as an HA MCP server? No, and the documentation says they compose. An MCP server, whether the official mcp_server integration or the community ha-mcp project, gives the model live tools to read state and call services, while this skill teaches the procedure and judgment. Without MCP the skill falls back to SSH and hass-cli. ### Which automation syntax does the Home Assistant skill enforce? Current YAML from 2024.10 onward, with triggers, conditions and actions keys and action: rather than the deprecated service:, because that is the syntax models tend to emit. It also handles the automation.trigger skips-conditions gotcha, knows when mode: restart is needed instead of mode: single, and looks for template errors and type mismatches. ## Sources - [Issues](https://github.com/komal-SkyNET/claude-skill-homeassistant/issues) - [komal-SkyNET/claude-skill-homeassistant on GitHub](https://github.com/komal-SkyNET/claude-skill-homeassistant) - [License: MIT](https://github.com/komal-SkyNET/claude-skill-homeassistant/blob/main/LICENSE) - [README](https://github.com/komal-SkyNET/claude-skill-homeassistant/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/komal-skynet-claude-skill-homeassistant