claude-skill-homeassistant: a Claude Code skill that encodes Home Assistant deploy discipline
Claude Code skill to supercharge and manage all Home Assistant workflows
At a glance
- What is it?
- The repository is a Claude Code skill, not an integration. It packages a git and scp deployment pipeline, reload-versus-restart rules, and automation verification steps for Home Assistant configs, with SSH and hass-cli as the fallback when no MCP server is present.
- Who is it for?
- Adopt it if you already run Claude Code against a Home Assistant config repository with SSH access and a git remote, and you want the assistant to validate before restarting and to test automations through logs and traces rather than assume success. Skip it if your config is edited only through the Home Assistant UI, if you have no SSH access to the instance, or if you expect it to control devices on its own; it encodes procedure, not live tools.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 73 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this skill fills: procedure, not device control
An assistant with access to Home Assistant can read entity state and call services. What it does not know, unless someone tells it, is the order of operations for changing a configuration file safely. The README makes this distinction directly: MCP servers give Claude live tools, while this skill encodes "the procedure and judgment" around them. The concrete claim is that an MCP-equipped Claude will still restart Home Assistant on an unvalidated config or write deprecated automation YAML. That is the problem being solved. The audience is a Home Assistant owner who keeps /config under git, has SSH enabled, and drives changes through Claude Code rather than the web UI. If you edit automations by clicking in the UI, this skill has nothing to attach to.
What the skill actually contains
This is a skill directory, not a running service. The repository is laid out so that the skill lives at skills/home-assistant-manager, and the installation instructions point Claude Code at that path. The README describes its contents as encoded knowledge: a git and scp deploy pipeline, reload-versus-restart decisions, a validate-before-restart discipline, a verification loop that reads logs and traces, template type-safety rules, dashboard storage-cache gotchas, and modern automation syntax. So the mechanism is prompt-level. Claude Code loads the skill when you start a session in a Home Assistant repository, and the skill's instructions steer how the assistant plans and executes changes. There is no daemon, no API surface, and no state of its own. Everything it does runs through tools you already have: SSH, scp, hass-cli, git, and optionally a Home Assistant MCP server.
The deploy loop: scp to test, git to keep
The README's worked example is the clearest statement of the intended data flow. Asked to create an automation that notifies when the front door is left open for more than five minutes, the described sequence is: write the automation YAML, deploy via scp for testing, reload automations rather than restart, trigger manually, check logs for execution, verify the notification arrived, and commit to git once it works. The hybrid is deliberate. scp gives a fast path to the running instance; git records the version that survived testing. The same pattern applies to dashboards, where the README states that dashboard changes deploy with only a browser refresh and no restart. Two details in that loop matter more than the rest. First, validation happens before applying changes, which the README frames as preventing downtime. Second, the reload-versus-restart choice is made from the change type, so an automation edit does not take down the whole instance.
Automation syntax and the verification protocol
The skill defaults to the current automation YAML form, described in the README as triggers, conditions, and actions, with action rather than service, and attributes the deprecated style to what LLMs tend to emit. That is a specific, checkable claim about model behaviour, and it is the kind of thing a skill can correct cheaply. The verification protocol is the more interesting part. The README says the skill tests automations by triggering them manually and then checking logs and traces, and it calls out the automation.trigger-skips-conditions gotcha by name. That gotcha is the reason manual triggering alone is not proof: a trigger fired this way does not evaluate the condition block, so an automation can appear to work while its conditions are broken. The skill also covers blueprint structure and the choice between mode: restart and mode: single, which is the difference between an automation that re-fires mid-run and one that drops the new event.
Lovelace work is where the opinionated parts show
Dashboard guidance is aimed at tablets, with the README naming 7, 11, and 13 inch targets and touch-friendly controls. It takes positions on card selection (Mushroom versus Tile, Panel versus Sections views) and ships Jinja2 template patterns for door and window counting with colour coding, conditional display by time or state, and multi-condition status indicators. It also lists pitfalls it claims to solve: dashboard registration, auto-entities failures, and template type errors. The screenshot in the repository is captioned as an example tablet dashboard with colour-coded status and a responsive grid. Treat the template snippets as starting points rather than finished cards. A Jinja2 expression that counts open doors is short; making it render correctly inside a specific card type on a specific screen is where the time goes, and the README's claim is that the skill knows which card types tolerate which templates.
Installation and the assumptions it bakes in
The recommended route is the plugin marketplace, run from anywhere: /plugin marketplace add komal-SkyNET/claude-skill-homeassistant followed by /plugin install home-assistant-manager@claude-skill-homeassistant. Updates use /plugin marketplace update claude-skill-homeassistant and /plugin update home-assistant-manager. The manual alternative clones the repository into .claude/skills inside your Home Assistant config and symlinks skills/home-assistant-manager into place, or downloads the tarball with curl and extracts with --strip-components=2. Verification is /plugin to confirm the plugin is listed and enabled, or simply starting Claude Code in the config repository. The prerequisites are the real constraint: SSH access on the instance, a git repository connected to /config, hass-cli installed (pipx install homeassistant-cli), SSH key authentication, and HASS_SERVER and HASS_TOKEN exported in the environment. Miss any of those and the deploy loop in the README has nothing to run against.
Limits, and when an MCP server is the better fit
The honest boundary is stated by the project itself: without MCP, the skill falls back to SSH and hass-cli. That fallback is slower and depends on your network path to the instance, and it cannot read live entity state as directly as an MCP tool call. The skill also cannot help if your Home Assistant setup does not expose SSH or does not keep /config in git, because both are load-bearing in every workflow it describes. If your goal is conversational control (turn off the lights, read a sensor), the official mcp_server integration or the community ha-mcp is the right tool; the skill adds nothing there. The two compose, and the README says the skill prefers MCP tools for live state and service calls when they are available. There is also a currency question. The README pins its syntax guidance to 2024.10 and later, and Home Assistant changes automation and dashboard behaviour on a monthly cadence, so the skill's rules are only as current as its last commit. The repository shows no retrieved releases, so there is no versioned changelog to check against.
Maintenance cost and licence
The licence is MIT, which permits commercial and private use, modification, and redistribution provided the copyright notice and permission notice are retained. That is the whole of the licence implication here; nothing in the repository's description suggests additional terms, and this is not legal advice. The maintenance picture is different from a normal dependency. A skill is prose and examples, so it does not break at runtime, but it drifts: when Home Assistant deprecates a syntax form or changes a dashboard behaviour, the skill's instructions become wrong in a way that is invisible until Claude follows them. Because it is installed as a plugin, updates are a two-command sequence, and because it is cloned into your config repository under the manual route, it also becomes part of your git history. The practical cost is periodic review of the skill's automation and dashboard guidance against the Home Assistant release notes for whatever version you run.
Editorial conclusion
Adopt it if you already run Claude Code against a Home Assistant config repository with SSH access and a git remote, and you want the assistant to validate before restarting and to test automations through logs and traces rather than assume success. Skip it if your config is edited only through the Home Assistant UI, if you have no SSH access to the instance, or if you expect it to control devices on its own; it encodes procedure, not live tools. Before installing, confirm that hass-cli is present or that a Home Assistant MCP server is configured, that HASS_SERVER and HASS_TOKEN are exported, and that /config is a git repository, because the skill's deploy loop assumes all three.
Community notes