Install
$ agentstack add skill-komal-skynet-claude-skill-homeassistant-home-assistant-manager ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ● Environment & secrets Used
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Home Assistant Manager
Operate a remote Home Assistant instance precisely: make a change, get it live, prove it worked. Optimize for the fewest safe round-trips.
Assumptions
- The repo you're editing is the HA
/configdir, git-connected to the instance
(typically root@homeassistant.local). Edits aren't live until pulled on the instance.
- Access via one or more of:
hass-cli(REST), SSHha, or an MCP server (see below). - Only edit
.yaml/.yml/.md. Never read/write.envorsecrets.yaml; use!secret.
Remote access — pick the right tool
- SSH
ha— always works, needs no local env. Use forha core check|restart|logs|info. hass-cli(REST) — state/service calls, but needsHASS_SERVER/HASS_TOKENin the
shell before the session starts. If they're unset, hass-cli falls back to the wrong host (localhost) and errors — don't retry, check [ -n "$HASS_TOKEN" ] once, then use SSH or MCP instead.
- MCP (preferred when available) — first-class tools for live state/control, no env
juggling. Official mcp_server integration (HA core ≥2025.2) or community ha-mcp (richer, 80+ tools). Use it instead of shelling out when present.
The deploy pipeline (the one canonical flow)
Changes are not live until step 4.
- Edit YAML locally.
- Validate:
ssh root@homeassistant.local "ha core check"(slow, ~30-60s — see "when to
skip" below).
- Commit + push:
git add … && git commit -m "…" && git push. - Make it live:
ssh root@homeassistant.local "cd /config && git pull". - Apply: reload if possible, else restart (table below).
- Verify (next section).
Rapid iteration: skip git and scp straight to the instance, then reload — good for dashboards and tight test loops. Commit to git only once stable. scp automations.yaml root@homeassistant.local:/config/ → reload.
When to skip ha core check: it parses the whole config and is slow. For an isolated YAML edit you're confident in, a domain reload surfaces errors faster and the logs tell you immediately. Always run it before a restart or for configuration.yaml changes.
Reload vs restart
| Change | Action | |--------|--------| | automations, scripts, scenes, groups, template entities, themes | reload the domain (hass-cli service call automation.reload, etc.) | | configuration.yaml core, new integrations, platform sensors (min/max), MQTT sensor/binary_sensor platforms, dashboard registry (lovelace_dashboards) | restart (ssh … "ha core restart", ~30s) |
Prefer reload. Never restart without a passing ha core check.
Verify — don't assume it worked
- Reload/restart the right domain.
- For automations, trigger manually for instant feedback:
hass-cli service call automation.trigger --arguments entity_id=automation. (or call the service via MCP).
- Read the logs filtered to your change:
ssh root@homeassistant.local "ha core logs | grep -iE '|error' | tail -20". Good: Running automation actions, Executing step …. Bad: Invalid data for call_service, TypeError, Template variable warning, Error executing script.
- Confirm the real outcome: device/sensor state (
hass-cli state get), or ask
the user for notification-type actions.
- On error: fix → re-pull/scp → reload → re-check. Loop until clean.
Templates — the precision rules
- Always coerce types before comparing:
states('sensor.x') | int(0) /dev/null. After deploying, **validate the UI
visually in the browser** (see the reference) — logs/state won't catch a broken card or a mis-sorted popup.
Full dashboard reference (view types, card catalog, template cards, tablet layout, pitfalls, debugging) → read [reference/dashboards.md](reference/dashboards.md) when doing UI work. Modern HA: native sections view (drag-drop grid, badges, heading cards) and feature-rich tile cards now cover most needs without custom cards; reach for Mushroom only when you want its specific look.
Quick reference
# Validate / apply
ssh root@homeassistant.local "ha core check"
ssh root@homeassistant.local "ha core restart"
ssh root@homeassistant.local "cd /config && git pull" # make pushed changes live
# Logs
ssh root@homeassistant.local "ha core logs | grep -iE 'error|' | tail -20"
# State / services (needs env loaded, or use MCP)
hass-cli state get
hass-cli service call .reload
hass-cli service call automation.trigger --arguments entity_id=automation.
# Rapid deploy
scp .yaml root@homeassistant.local:/config/ && hass-cli service call automation.reload
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: komal-SkyNET
- Source: komal-SkyNET/claude-skill-homeassistant
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.