Borrowing it
Nothing to install: this file belongs to jpawlowski/hacs.integration_blueprint. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/jpawlowski/hacs.integration_blueprint/main/.agents/skills/ha-breaking-changes/SKILL.mdgit clone --depth 1 https://github.com/jpawlowski/hacs.integration_blueprintWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/jpawlowski/hacs.integration_blueprint/ha-breaking-changes)<a href="https://agentmods.dev/skills/jpawlowski/hacs.integration_blueprint/ha-breaking-changes"><img src="https://agentmods.dev/badge/skills/jpawlowski/hacs.integration_blueprint/ha-breaking-changes/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/jpawlowski/hacs.integration_blueprint/ha-breaking-changes"><img src="https://agentmods.dev/badge/skills/jpawlowski/hacs.integration_blueprint/ha-breaking-changes.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Memory Poisoning · line 182 Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.Fix: Protect agent memory and state from modification by untrusted content. Use read-only memory for critical instructions and validate all state changes.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00214 | $0.02362 |
| Opus 5 | $0.00107 | $0.01181 |
| Sonnet 5 | $0.00043 | $0.00472 |
| Haiku 4.5 | $0.00021 | $0.00236 |
Grade A, and why
ha-breaking-changes scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 187 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Breaking changes
Users have automations, dashboards, scripts, and long-term statistics wired to this integration's entity IDs, unique IDs, states, and action names. Breaking any of them is a real cost to real people, and the integration cannot see who it broke.
Which side of 1.0.0 is this?
Everything below assumes a released, stable integration. Before 1.0.0 the trade-off is genuinely different, and
applying the post-1.0 rules early is its own kind of damage: compatibility code accumulates in a codebase whose
shape is not settled yet, which is exactly what makes reaching a stable 1.0.0 harder.
Before 1.0.0:
- A breaking change is an acceptable outcome, and usually the right one. Getting the shape right beats preserving a shape you already regret.
- What still needs asking is whether to build the migration — not whether to break. Do not write
async_migrate_entry, rewrite registry entries, or bumpVERSION/MINOR_VERSIONon your own initiative. Put the choice to the developer: break cleanly now, or carry the migration. - Recommend. "The cleanest fix is to rename the key and let existing test entries be recreated; a migration would cost ~40 lines we would then maintain" is the useful form. Not "shall I migrate?"
- Do not record each one in
DECISIONS.md. That log is for architecture. A key renamed before the first stable release is not an architectural decision, and a log padded with them is one nobody reads. - Keep the
BREAKING CHANGE:footer anyway. It costs one line, and it is the whole price of this freedom: HACS installs0.xversions too, and the people testing early deserve a changelog entry rather than a silent surprise. Release-please turns it into a minor bump pre-1.0 (ha-release), so it is cheap.
This is also the window in which unique IDs stop being free. {entry_id}_{key} is the documented last resort — if the
device exposes a serial or MAC, switch to it before 1.0.0, because afterwards it is a migration
(blueprint.entities).
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 187 lines · 214 tokens per session scan A 8f62bdca0cc6
ha-breaking-changes is a skill published in the GitHub repository jpawlowski/hacs.integration_blueprint (49 stars, last pushed 2d ago), licensed MIT. It adds 214 tokens to every session and 2,362 once invoked, about $0.0011 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
API Catalog
Reference guide for connecting popular APIs to Home Assistant via Node-RED, YAML, or custom integrations. Covers authentication, endpoints, and complete working examples for: energy APIs (Tibber, Nordpool), weather (SMHI, OpenWeatherMap, yr.no), transport (SL, Trafikverket, Resrobot), smart home clouds (Shelly, Tuya…
homeassistant
Source-layer Home Assistant guide material preserved behind the runtime guide.
bat-story-eval
Compare MCP tool behavior between target and baseline versions using pre-built and custom stories with diff-based triage.
contrib-pr-review
Review a contribution PR for safety, quality, and readiness. Checks for security concerns, test coverage, size appropriateness, and intent alignment. Use when reviewing external contributions.
bat-adhoc
Run bot acceptance tests to validate MCP tools work correctly from a real AI agent's perspective. Use when testing PRs, detecting regressions, or verifying tool changes end-to-end with Claude/Gemini CLIs.
contributors-update
Find merged PR authors missing from README and update the contributors list after approval.