home-assistant/core

ha-integration-knowledge

Everything you need to know to build, test and review Home Assistant Integrations. If you're looking at an integration, you must use this as your primary reference.

First seen Apr 29, 2026

Installation

$ npx skills add home-assistant/core --skill ha-integration-knowledge

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from home-assistant/core.

npx skills add home-assistant/core

Browse all from home-assistant/core

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 90.3K
License LICENSE.md
Default branch dev
Open issues 2,615
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,601 B
  • docs SUMMARY.md 196 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 69 installs

SKILL.md

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 scaninterval, updateinterval, 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:

  • Diagnostics: [platform-diagnostics.md](platform-diagnostics.md) for diagnostic data collection
  • Repairs: [platform-repairs.md](platform-repairs.md) for user-actionable repair issues

Entity platforms

  • Ensure asyncaddedtohass() and asyncwillremovefromhass() have symmetrical behavior. For example, if a subscription is created in asyncaddedtohass(), it should be unsubscribed in asyncwillremovefromhass(). Also, if something is torn down in asyncwillremovefromhass(), it should be set up in asyncaddedto_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.

Integration Quality Scale

Template scale file: ./script/scaffold/templates/integration/integration/quality_scale.yaml

How Rules Apply

  1. Check manifest.json: Look for "quality_scale" key to determine integration level
  2. Bronze Rules: Always required for any integration with quality scale
  3. Higher Tier Rules: Only apply if integration targets that tier or higher
  4. Rule Status: Check quality_scale.yaml in integration folder for:

- done: Rule implemented - exempt: Rule doesn't apply (with reason in comment) - todo: Rule needs implementation

Testing Requirements