{"owner":"frenck","repo":"awesome-home-assistant","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nGuidance for AI coding agents (and the humans driving them) working on this\nrepository. `CLAUDE.md` is a symlink to this file because Claude is the\nodd one out; everyone else already reads `AGENTS.md`.\n\nThis is a curated awesome-list, not a software project. Most agent work\nhere is editing `README.md` and a small set of supporting scripts. The\nmechanical rules (entry format, quality bar, license requirements, link\nhygiene) already live in `.github/CONTRIBUTING.md` and the scripts under\n`scripts/`. This file covers the things those don't: taxonomy, audience,\nvoice, and behaviors specific to working with an AI agent.\n\n## What this repo is\n\n`Awesome Home Assistant` is a community-curated index of resources that\nlive *outside* Home Assistant itself: custom integrations installable via\nHACS, custom dashboard cards, themes, icon packs, Apps, ESPHome and DIY\nprojects, blogs, podcasts, YouTube channels, and more. The deployed site\nis <https://awesome-ha.com>, built with `mkdocs-material` from `README.md`.\n\nThe audience is **Home Assistant users**, with a strong tilt toward\n**newcomers and less-technical users**. Section intros and entry\ndescriptions should make sense to someone setting up their first\ndashboard, not to someone who already knows what HACS is.\n\n## Where the actual rules live\n\nBefore editing the list or reviewing a PR, read these:\n\n- `.github/CONTRIBUTING.md` for entry format, license requirements,\n  acceptance criteria, and link hygiene.\n- `scripts/check_listing.py <repo-url>` validates a single contribution\n  end-to-end (age, license, activity, HACS metadata). Run it on every\n  proposed addition before merging.\n- `scripts/check_activity.py` flags entries whose upstream is archived,\n  deleted, or stale. Runs weekly; opens a maintenance PR.\n- `scripts/update_stars.py` keeps the `(N,NNN★)` counts current. Don't\n  hand-edit star counts.\n- `scripts/update_youtube_subs.py` keeps the `(N subs)` counts in the\n  YouTube Channels section current. Don't hand-edit subscriber counts.\n\nIf a rule appears here *and* in CONTRIBUTING.md, CONTRIBUTING.md wins.\n\n## Curation principles\n\nThese are judgement calls a linter cannot make for you.\n\n1. **Outside Home Assistant only.** This list does not duplicate\n   home-assistant.io. Anything documented at\n   `home-assistant.io/integrations/<name>` is a built-in integration and\n   does not belong here. Same for HA-internal sections (Hardware, Project\n   & roadmap, Open Home Foundation, Works With Home Assistant); reference\n   them sparingly in the intro, never as their own section.\n\n2. **Taxonomy is structural, not topical.** Top-level sections describe\n   *what kind of thing* an entry is (custom integration, dashboard card,\n   app, blueprint, blog), not *what topic* it covers (Voice, AI, Energy,\n   Matter, Zigbee). Topic groupings live as subsections inside a\n   structural parent. The exception is standalone community projects with\n   their own ecosystem (ESPHome, Music Assistant, Z2M); those can be\n   top-level on their own merit.\n\n3. **Detect HACS-as-bootstrap.** Some HACS \"integrations\" are actually\n   cards, themes, icon packs, or dashboards using a `custom_component` as\n   bootstrap glue. Tells: \"card\", \"theme\", \"dashboard\", \"icon pack\",\n   \"frontend\" in the description. Those go under Dashboard Cards / Themes\n   / Icon packs / Dashboards, never under Custom Integrations.\n\n## Voice and writing style\n\nThese apply to any prose an agent writes: section intros, entry\ndescriptions, PR titles and bodies, commit messages, code comments.\n\n- **Lead with the user-facing problem, then name the technology.** \"Pull\n  data from sensors that broadcast over Bluetooth, or use Bluetooth itself\n  for room-level presence detection\" beats \"BLE-related integrations\".\n- **Never call the project anything other than \"Home Assistant\".** Not\n  \"HA\", not \"Hass\", not \"Hass.io\", not \"HASS\", not \"hassio\". This applies\n  to prose *we* write. Project names that contain those strings (the\n  \"HASS Aarlo\" repo, the \"Hass.io Google Drive Backup\" project, the\n  `hassio-addons` GitHub org in URLs) stay as-is because they are the\n  actual names.\n- **Don't say \"Home Assistant\" inside an entry description.** The list's\n  title already implies it. \"A card for controlling robot vacuums\" beats\n  \"A Home Assistant card for controlling robot vacuums\".\n- **No em dashes or en dashes anywhere.** They're a tell that text was\n  generated by an AI. Use commas, parentheses, or restart the sentence.\n- **No marketing fluff.** Strike \"powerful\", \"amazing\", \"easy to use\",\n  \"next-gen\", \"robust\". State what the thing does.\n- **Don't reference issue or PR numbers in committed comments.** They rot\n  as the codebase evolves; that context belongs in commit messages and PR\n  descriptions instead.\n\n## Reviewing a PR that adds an entry\n\nRun the checks in this order; the first failure ends the review.\n\n1. Does it belong on the list at all? (Outside HA, type-correct, not a\n   built-in.)\n2. `python scripts/check_listing.py <url>` is green.\n3. Right section *and* right subsection. Watch for HACS-as-bootstrap.\n4. Description follows the voice rules above.\n5. `awesome-lint` and `lychee` are green.\n\nIf a check fails and the project is close to meeting it (e.g., will pass\nthe age bar in three weeks), say so and invite resubmission. Be friendly;\nmany contributors here are first-time open-source contributors and the\nlist rejecting their submission is often their first OSS feedback.\n\n## Behaviors specific to AI agents\n\n- **Do not push directly to `main`.** Always work on a branch and open a\n  PR, even for typo fixes.\n- **One concern per PR.** Don't bundle a description fix, a section\n  reorder, and a workflow change. Reviewers and `git revert` both prefer\n  small, focused changes.\n- **Don't claim CI passed unless you saw it pass.** \"All checks green\" is\n  a verifiable claim, not a polite closing.\n- **Don't fabricate star counts, license names, or last-commit dates.**\n  Read them from the repo or via `scripts/check_listing.py`. If you\n  can't, say so.\n- **Side quests stay in scope.** If you notice something unrelated worth\n  fixing, surface it as a follow-up rather than smuggling it into the\n  current PR.\n\n## Files an agent will touch most often\n\n- `README.md` — the list itself\n- `.github/CONTRIBUTING.md` — contributor-facing rules\n- `scripts/check_listing.py` / `check_activity.py` / `update_stars.py` /\n  `update_youtube_subs.py` — maintenance scripts\n- `mkdocs.yml` — site config\n- `.github/workflows/*.yaml` — link checks, listing checks, weekly maintenance\n","CLAUDE.md":"The guidance for AI agents in this repository lives in\n[AGENTS.md](AGENTS.md). Read that file before doing anything else.\n\nThis file exists because Claude Code reads `CLAUDE.md` while every other\nagent reads `AGENTS.md`. Ideally this would be a symlink to `AGENTS.md`\nso the two stay byte-identical; see the PR description for the\none-command conversion.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\nGuidance for AI coding agents (and the humans driving them) working on this\nrepository. `CLAUDE.md` is a symlink to this file because Claude is the\nodd one out; everyone else already reads `AGENTS.md`.\n\nThis is a curated awesome-list, not a software project. Most agent work\nhere is editing `README.md` and a small set of supporting scripts. The\nmechanical rules (entry format, quality bar, license requirements, link\nhygiene) already live in `.github/CONTRIBUTING.md` and the scripts under\n`scripts/`. This file covers the things those don't: taxonomy, audience,\nvoice, and behaviors specific to working with an AI agent.\n\n## What this repo is\n\n`Awesome Home Assistant` is a community-curated index of resources that\nlive *outside* Home Assistant itself: custom integrations installable via\nHACS, custom dashboard cards, themes, icon packs, Apps, ESPHome and DIY\nprojects, blogs, podcasts, YouTube channels, and more. The deployed site\nis <https://awesome-ha.com>, built with `mkdocs-material` from `README.md`.\n\nThe audience is **Home Assistant users**, with a strong tilt toward\n**newcomers and less-technical users**. Section intros and entry\ndescriptions should make sense to someone setting up their first\ndashboard, not to someone who already knows what HACS is.\n\n## Where the actual rules live\n\nBefore editing the list or reviewing a PR, read these:\n\n- `.github/CONTRIBUTING.md` for entry format, license requirements,\n  acceptance criteria, and link hygiene.\n- `scripts/check_listing.py <repo-url>` validates a single contribution\n  end-to-end (age, license, activity, HACS metadata). Run it on every\n  proposed addition before merging.\n- `scripts/check_activity.py` flags entries whose upstream is archived,\n  deleted, or stale. Runs weekly; opens a maintenance PR.\n- `scripts/update_stars.py` keeps the `(N,NNN★)` counts current. Don't\n  hand-edit star counts.\n- `scripts/update_youtube_subs.py` keeps the `(N subs)` counts in the\n  YouTube Channels section current. Don't hand-edit subscriber counts.\n\nIf a rule appears here *and* in CONTRIBUTING.md, CONTRIBUTING.md wins.\n\n## Curation principles\n\nThese are judgement calls a linter cannot make for you.\n\n1. **Outside Home Assistant only.** This list does not duplicate\n   home-assistant.io. Anything documented at\n   `home-assistant.io/integrations/<name>` is a built-in integration and\n   does not belong here. Same for HA-internal sections (Hardware, Project\n   & roadmap, Open Home Foundation, Works With Home Assistant); reference\n   them sparingly in the intro, never as their own section.\n\n2. **Taxonomy is structural, not topical.** Top-level sections describe\n   *what kind of thing* an entry is (custom integration, dashboard card,\n   app, blueprint, blog), not *what topic* it covers (Voice, AI, Energy,\n   Matter, Zigbee). Topic groupings live as subsections inside a\n   structural parent. The exception is standalone community projects with\n   their own ecosystem (ESPHome, Music Assistant, Z2M); those can be\n   top-level on their own merit.\n\n3. **Detect HACS-as-bootstrap.** Some HACS \"integrations\" are actually\n   cards, themes, icon packs, or dashboards using a `custom_component` as\n   bootstrap glue. Tells: \"card\", \"theme\", \"dashboard\", \"icon pack\",\n   \"frontend\" in the description. Those go under Dashboard Cards / Themes\n   / Icon packs / Dashboards, never under Custom Integrations.\n\n## Voice and writing style\n\nThese apply to any prose an agent writes: section intros, entry\ndescriptions, PR titles and bodies, commit messages, code comments.\n\n- **Lead with the user-facing problem, then name the technology.** \"Pull\n  data from sensors that broadcast over Bluetooth, or use Bluetooth itself\n  for room-level presence detection\" beats \"BLE-related integrations\".\n- **Never call the project anything other than \"Home Assistant\".** Not\n  \"HA\", not \"Hass\", not \"Hass.io\", not \"HASS\", not \"hassio\". This applies\n  to prose *we* write. Project names that contain those strings (the\n  \"HASS Aarlo\" repo, the \"Hass.io Google Drive Backup\" project, the\n  `hassio-addons` GitHub org in URLs) stay as-is because they are the\n  actual names.\n- **Don't say \"Home Assistant\" inside an entry description.** The list's\n  title already implies it. \"A card for controlling robot vacuums\" beats\n  \"A Home Assistant card for controlling robot vacuums\".\n- **No em dashes or en dashes anywhere.** They're a tell that text was\n  generated by an AI. Use commas, parentheses, or restart the sentence.\n- **No marketing fluff.** Strike \"powerful\", \"amazing\", \"easy to use\",\n  \"next-gen\", \"robust\". State what the thing does.\n- **Don't reference issue or PR numbers in committed comments.** They rot\n  as the codebase evolves; that context belongs in commit messages and PR\n  descriptions instead.\n\n## Reviewing a PR that adds an entry\n\nRun the checks in this order; the first failure ends the review.\n\n1. Does it belong on the list at all? (Outside HA, type-correct, not a\n   built-in.)\n2. `python scripts/check_listing.py <url>` is green.\n3. Right section *and* right subsection. Watch for HACS-as-bootstrap.\n4. Description follows the voice rules above.\n5. `awesome-lint` and `lychee` are green.\n\nIf a check fails and the project is close to meeting it (e.g., will pass\nthe age bar in three weeks), say so and invite resubmission. Be friendly;\nmany contributors here are first-time open-source contributors and the\nlist rejecting their submission is often their first OSS feedback.\n\n## Behaviors specific to AI agents\n\n- **Do not push directly to `main`.** Always work on a branch and open a\n  PR, even for typo fixes.\n- **One concern per PR.** Don't bundle a description fix, a section\n  reorder, and a workflow change. Reviewers and `git revert` both prefer\n  small, focused changes.\n- **Don't claim CI passed unless you saw it pass.** \"All checks green\" is\n  a verifiable claim, not a polite closing.\n- **Don't fabricate star counts, license names, or last-commit dates.**\n  Read them from the repo or via `scripts/check_listing.py`. If you\n  can't, say so.\n- **Side quests stay in scope.** If you notice something unrelated worth\n  fixing, surface it as a follow-up rather than smuggling it into the\n  current PR.\n\n## Files an agent will touch most often\n\n- `README.md` — the list itself\n- `.github/CONTRIBUTING.md` — contributor-facing rules\n- `scripts/check_listing.py` / `check_activity.py` / `update_stars.py` /\n  `update_youtube_subs.py` — maintenance scripts\n- `mkdocs.yml` — site config\n- `.github/workflows/*.yaml` — link checks, listing checks, weekly maintenance\n","CLAUDE.md":"The guidance for AI agents in this repository lives in\n[AGENTS.md](AGENTS.md). Read that file before doing anything else.\n\nThis file exists because Claude Code reads `CLAUDE.md` while every other\nagent reads `AGENTS.md`. Ideally this would be a symlink to `AGENTS.md`\nso the two stay byte-identical; see the PR description for the\none-command conversion.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\nGuidance for AI coding agents (and the humans driving them) working on this\nrepository. `CLAUDE.md` is a symlink to this file because Claude is the\nodd one out; everyone else already reads `AGENTS.md`.\n\nThis is a curated awesome-list, not a software project. Most agent work\nhere is editing `README.md` and a small set of supporting scripts. The\nmechanical rules (entry format, quality bar, license requirements, link\nhygiene) already live in `.github/CONTRIBUTING.md` and the scripts under\n`scripts/`. This file covers the things those don't: taxonomy, audience,\nvoice, and behaviors specific to working with an AI agent.\n\n## What this repo is\n\n`Awesome Home Assistant` is a community-curated index of resources that\nlive *outside* Home Assistant itself: custom integrations installable via\nHACS, custom dashboard cards, themes, icon packs, Apps, ESPHome and DIY\nprojects, blogs, podcasts, YouTube channels, and more. The deployed site\nis <https://awesome-ha.com>, built with `mkdocs-material` from `README.md`.\n\nThe audience is **Home Assistant users**, with a strong tilt toward\n**newcomers and less-technical users**. Section intros and entry\ndescriptions should make sense to someone setting up their first\ndashboard, not to someone who already knows what HACS is.\n\n## Where the actual rules live\n\nBefore editing the list or reviewing a PR, read these:\n\n- `.github/CONTRIBUTING.md` for entry format, license requirements,\n  acceptance criteria, and link hygiene.\n- `scripts/check_listing.py <repo-url>` validates a single contribution\n  end-to-end (age, license, activity, HACS metadata). Run it on every\n  proposed addition before merging.\n- `scripts/check_activity.py` flags entries whose upstream is archived,\n  deleted, or stale. Runs weekly; opens a maintenance PR.\n- `scripts/update_stars.py` keeps the `(N,NNN★)` counts current. Don't\n  hand-edit star counts.\n- `scripts/update_youtube_subs.py` keeps the `(N subs)` counts in the\n  YouTube Channels section current. Don't hand-edit subscriber counts.\n\nIf a rule appears here *and* in CONTRIBUTING.md, CONTRIBUTING.md wins.\n\n## Curation principles\n\nThese are judgement calls a linter cannot make for you.\n\n1. **Outside Home Assistant only.** This list does not duplicate\n   home-assistant.io. Anything documented at\n   `home-assistant.io/integrations/<name>` is a built-in integration and\n   does not belong here. Same for HA-internal sections (Hardware, Project\n   & roadmap, Open Home Foundation, Works With Home Assistant); reference\n   them sparingly in the intro, never as their own section.\n\n2. **Taxonomy is structural, not topical.** Top-level sections describe\n   *what kind of thing* an entry is (custom integration, dashboard card,\n   app, blueprint, blog), not *what topic* it covers (Voice, AI, Energy,\n   Matter, Zigbee). Topic groupings live as subsections inside a\n   structural parent. The exception is standalone community projects with\n   their own ecosystem (ESPHome, Music Assistant, Z2M); those can be\n   top-level on their own merit.\n\n3. **Detect HACS-as-bootstrap.** Some HACS \"integrations\" are actually\n   cards, themes, icon packs, or dashboards using a `custom_component` as\n   bootstrap glue. Tells: \"card\", \"theme\", \"dashboard\", \"icon pack\",\n   \"frontend\" in the description. Those go under Dashboard Cards / Themes\n   / Icon packs / Dashboards, never under Custom Integrations.\n\n## Voice and writing style\n\nThese apply to any prose an agent writes: section intros, entry\ndescriptions, PR titles and bodies, commit messages, code comments.\n\n- **Lead with the user-facing problem, then name the technology.** \"Pull\n  data from sensors that broadcast over Bluetooth, or use Bluetooth itself\n  for room-level presence detection\" beats \"BLE-related integrations\".\n- **Never call the project anything other than \"Home Assistant\".** Not\n  \"HA\", not \"Hass\", not \"Hass.io\", not \"HASS\", not \"hassio\". This applies\n  to prose *we* write. Project names that contain those strings (the\n  \"HASS Aarlo\" repo, the \"Hass.io Google Drive Backup\" project, the\n  `hassio-addons` GitHub org in URLs) stay as-is because they are the\n  actual names.\n- **Don't say \"Home Assistant\" inside an entry description.** The list's\n  title already implies it. \"A card for controlling robot vacuums\" beats\n  \"A Home Assistant card for controlling robot vacuums\".\n- **No em dashes or en dashes anywhere.** They're a tell that text was\n  generated by an AI. Use commas, parentheses, or restart the sentence.\n- **No marketing fluff.** Strike \"powerful\", \"amazing\", \"easy to use\",\n  \"next-gen\", \"robust\". State what the thing does.\n- **Don't reference issue or PR numbers in committed comments.** They rot\n  as the codebase evolves; that context belongs in commit messages and PR\n  descriptions instead.\n\n## Reviewing a PR that adds an entry\n\nRun the checks in this order; the first failure ends the review.\n\n1. Does it belong on the list at all? (Outside HA, type-correct, not a\n   built-in.)\n2. `python scripts/check_listing.py <url>` is green.\n3. Right section *and* right subsection. Watch for HACS-as-bootstrap.\n4. Description follows the voice rules above.\n5. `awesome-lint` and `lychee` are green.\n\nIf a check fails and the project is close to meeting it (e.g., will pass\nthe age bar in three weeks), say so and invite resubmission. Be friendly;\nmany contributors here are first-time open-source contributors and the\nlist rejecting their submission is often their first OSS feedback.\n\n## Behaviors specific to AI agents\n\n- **Do not push directly to `main`.** Always work on a branch and open a\n  PR, even for typo fixes.\n- **One concern per PR.** Don't bundle a description fix, a section\n  reorder, and a workflow change. Reviewers and `git revert` both prefer\n  small, focused changes.\n- **Don't claim CI passed unless you saw it pass.** \"All checks green\" is\n  a verifiable claim, not a polite closing.\n- **Don't fabricate star counts, license names, or last-commit dates.**\n  Read them from the repo or via `scripts/check_listing.py`. If you\n  can't, say so.\n- **Side quests stay in scope.** If you notice something unrelated worth\n  fixing, surface it as a follow-up rather than smuggling it into the\n  current PR.\n\n## Files an agent will touch most often\n\n- `README.md` — the list itself\n- `.github/CONTRIBUTING.md` — contributor-facing rules\n- `scripts/check_listing.py` / `check_activity.py` / `update_stars.py` /\n  `update_youtube_subs.py` — maintenance scripts\n- `mkdocs.yml` — site config\n- `.github/workflows/*.yaml` — link checks, listing checks, weekly maintenance\n","category":"root","tokens":1639},{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"The guidance for AI agents in this repository lives in\n[AGENTS.md](AGENTS.md). Read that file before doing anything else.\n\nThis file exists because Claude Code reads `CLAUDE.md` while every other\nagent reads `AGENTS.md`. Ideally this would be a symlink to `AGENTS.md`\nso the two stay byte-identical; see the PR description for the\none-command conversion.\n","category":"root","tokens":89}]}