core integrations.instructions.md

Repository instructions for developing Home Assistant integrations, which connect the home-automation system to devices and services. They cover file locations, validation, polling, naming, tests, and code structure.

In plain words
What is it for?
Developing integration code and tests, choosing reference integrations, handling configuration flows, defining entity actions, and separating protocol logic into libraries.
Why use it?
They explain project rules that are easy to miss when adding or changing an integration, helping keep the code and tests consistent with Home Assistant.

Instructions file for GitHub Copilot

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add instructions/home-assistant/core/integrations
Clone the repo
git clone --depth 1 https://github.com/home-assistant/core

Made for: GitHub Copilot.

Per session 733 This file is loaded in full into every session.
When invoked 733 The same file — it is already loaded in full.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00733 $0.00733
Opus 5 $0.00367 $0.00367
Sonnet 5 $0.00147 $0.00147
Haiku 4.5 $0.00073 $0.00073

Measured today against content hash 2f338b8f7e79, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

core integrations.instructions.md 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 today.

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.

.github/instructions/integrations.instructions.md · 52 lines

How it starts

The opening of the file, as written. The whole thing — 52 lines — stays where its author put it; the contents beside it link to each section on GitHub.

File Locations

  • Integration code: ./homeassistant/components/<integration_domain>/
  • Integration tests: ./tests/components/<integration_domain>/

General guidelines

  • When looking for examples, prefer integrations with the platinum or gold quality scale level first.
  • Polling intervals are NOT user-configurable. Never add scan_interval, update_interval, or polling frequency options to config flows or config entries.
  • Do NOT allow users to set config entry names in config flows. Names are automatically generated or can be customized later in UI. Exception: helper integrations may allow custom names.
  • For entity actions and entity services, avoid requesting redundant defensive checks for fields already enforced by Home Assistant validation schemas and entity filters; only request extra guards when values bypass validation or are transformed unsafely.
  • When validation guarantees a key is present, prefer direct dictionary indexing (data["key"]) over .get("key") so invalid assumptions fail fast.
  • Integrations should be thin wrappers. Protocol parsing, device state machines, or other domain logic belong in a separate PyPI library, not in the integration itself. If unsure, ask before inlining.
  • Integrations should not implement fixes or workarounds for limitations in libraries. Instead, the library should be updated to fix the issue.

The following platforms have extra guidelines:

Entity platforms

  • Ensure async_added_to_hass() and async_will_remove_from_hass() have symmetrical behavior. For example, if a subscription is created in async_added_to_hass(), it should be unsubscribed in async_will_remove_from_hass(). Also, if something is torn down in async_will_remove_from_hass(), it should be set up in async_added_to_hass().
  • Entity base class (e.g. SensorEntity, TrackerEntity) provide a stable API for child classes to inherit from. Do not suggest redeclaring or duplicating attributes, properties, or methods the base class already provides, and do not add guards against the parent's behavior changing — rely on the base class instead.

Read the full file on GitHub · 52 lines

Changes

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.

  1. today First seen · 52 lines · 733 tokens per session scan A 2f338b8f7e79

Subscribe to this mod's changes

core integrations.instructions.md is an instructions file published in the GitHub repository home-assistant/core (90,198 stars, last pushed today), licensed Apache-2.0. It adds 733 tokens to every session, about $0.0037 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-31.