bump-core-req
Updates the minimum core version requirement for a fleet plugin in all three canonical places: `required_core_version` and `requires["claude-code-hermit"]` in…
Detect pending Home Assistant updates (Core, OS, Supervisor, add-ons, HACS) from the update.* domain and surface them as actionable proposals. Runs daily as a routine via reflect --check-id ha-update-check --check claude-code-homeassistant-hermit:ha-update-check.
$ npx -y skills add gtapps/claude-code-hermit --skill ha-update-check --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/ha-update-checkContext preview
The summary Claude sees to decide when to auto-load this skill.
Detect pending Home Assistant updates (Core, OS, Supervisor, add-ons, HACS) from the update.* domain and surface them as actionable proposals. Runs daily as a routine via reflect --check-id ha-update-check --check claude-code-homeassistant-hermit:ha-update-check.
name: ha-update-check description: Detect pending Home Assistant updates (Core, OS, Supervisor, add-ons, HACS) from the update.* domain and surface them as actionable proposals. Runs daily as a routine via reflect --check-id ha-update-check --check claude-code-homeassistant-hermit:ha-update-check. allowed-tools: - Bash
Home Assistant surfaces pending updates as `update.*` entities — one domain covering Core, OS/Supervisor, add-ons, and HACS integrations, each carrying `installed_version`/`latest_version`/`release_summary`/`release_url`. This skill lists what's pending and reports it in a fixed format the proposal pipeline can fan out into per-update proposals.
Native fields only — no web fetch for breaking-change detail (keeps this check cheap; fetch on accept if that's ever needed). HA-native `skipped_version` is honored: an update the operator skipped in the HA UI stays quiet here too.
Run the update check via the CLI:
${CLAUDE_PLUGIN_ROOT}/bin/ha-agent-lab ha updatesThe CLI:
`reflect --check-id ha-update-check --check claude-code-homeassistant-hermit:ha-update-check` routes the findings block through the proposal pipeline. The stdout shape is fixed:
ha-update-check findings — <date> Updates pending: N - [core] Home Assistant Core: 2026.6.3 → 2026.7.1 — <release_url> - [addon] Mosquitto broker: 6.4 → 6.5 — <release_url> - [hacs] 7 HACS updates pending
If nothing is pending: `No actionable findings. (no updates pending)`. If HA is unreachable: `No actionable findings. (skipped: <error>)`.
Keep stdout to this shape — no prose, no extra sections. Each proposal title should carry the concrete target version (e.g. `[ha-update] HA Core → 2026.7.1`) — that keeps same-version re-emits byte-identical so proposal-triage reliably suppresses repeats; Core/OS/Supervisor and each add-on become individual proposals, all pending HACS updates aggregate into one.
If `ha_update_auto_apply` is enabled in `.claude-code-hermit/config.json`, route acceptance through `/claude-code-homeassistant-hermit:ha-apply-update` rather than applying directly — it enforces the tier rule (add-ons/HACS may auto-apply; Core/OS/Supervisor always wait for an explicit operator go-ahead). If the flag is absent or false, the proposal is purely advisory: resolve it once the operator has applied the update themselves in the HA UI.
If you know Claude Tag, the idea will feel familiar: hand Claude work through a channel, such as Discord, Telegram, or your custom integration, and get results back there.
Repo: gtapps/claude-code-hermit
Updates the minimum core version requirement for a fleet plugin in all three canonical places: `required_core_version` and `requires["claude-code-hermit"]` in…
Changelog and commit — lightweight motion for day-to-day plugin dev work in the monorepo. One commit per plugin scope; CHANGELOG and staging routed by detected…
Documentation-drift audit for the plugin monorepo. Audits either each scoped plugin's unreleased changelog claims or its latest shipped release from the…
Explain in plain language what a fix, feature, PR, or plan will actually change for downstream hermits and the operators chatting with them — a before/after…
Use this skill whenever the user wants to release, ship, prep, or cut versions for two or more plugins together on the current branch. Trigger on phrasings…
Daily release-pipeline digest with a change gate — reports which plugins are pending release, whether main's CI is green, which branches went stale, and GitHub…