Source-backed Claude agent prompt for contributing to the official home-assistant/core repository using its AGENTS.md guidance for PR templates, setup, Python 3.14, integration tests, translations, snapshots, and quality checks.
Open the source and read safety notes before installing.
Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.
Decision playbook
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
0
78
—
No baseline selected
No major trust-signal divergence detected in the current selection.
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Source provenance statusRequired
Marked as source-backed.
Metadata reviewed
Registry metadata indicates a reviewed listing.
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Trust level risk gateRequired
Trust level does not block evaluation.
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Package verification flag
No package verification flag provided.
Checksum metadata
No checksum provided for downloaded artifact.
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
Baseline comparison available
No baseline peer selected yet.
Diverging trust signals identified
No major trust-signal divergence found.
Setup at a glance
Copy-ready — paste the snippet to get started.
Adoption plan
Current risk score 16/100. Use staged verification before broader rollout.
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Confirm metadata review state
Listing has review metadata.
Verify install payload
Install/config payload exists and can be inspected.
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Review privacy notesRequired
Privacy notes are present.
Verify package integrity metadata
No package verification/checksum metadata.
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Evidence readiness
Required evidence gates are covered (5/6 signals complete).
Source repository/provenance is listed.
Required in this preset
Review metadata is present.
Required in this preset
Safety notes are present.
Required in this preset
Privacy notes are present.
Optional in this preset
Package integrity metadata is missing.
Optional in this preset
Install payload is available.
Required in this preset
Required evidence gates are covered for this preset.
Decision timeline
5/6 steps complete with no blocking gaps for this preset.
triage
Source/provenance metadata is available.
triage
Review metadata is available.
verify
Safety notes are available.
verify
Privacy notes are available.
verify
Package integrity metadata is missing.
rollout
Install payload is available.
No required blockers for this timeline preset.
Prerequisite readiness
7 prerequisites to line up before setup. Includes a review or approval gate.
Safety & privacy surface
8 safety and 4 privacy notes across 6 risk areas. Review closely: credentials & tokens, permissions & scopes, network access.
# Trigger
"Use the Home Assistant Core repository contributor agent for this home-assistant/core task."
# Required output
1) AGENTS.md, integration, test, translation, and PR-template context checked
2) Focused Home Assistant Core plan or patch summary
3) Relevant uv, pytest, translation, and prek validation commands and results
4) Safety, privacy, local-control, and remaining-risk notesCreate this file as
.claude/agents/home-assistant-core-repository-contributor.md:
---
name: home-assistant-core-repository-contributor
description: Use when the user asks Claude to investigate, patch, test, or review work in the official home-assistant/core repository from source-backed repository instructions.
tools:
- bash
- read
- edit
- grep
- web_fetch
---
You are the Home Assistant Core Repository Contributor Agent. Your job is to
help work in the official `home-assistant/core` repository while following the
current repository instructions, preserving Home Assistant's local-control and
privacy expectations, and validating integration behavior with the right setup,
translation, typing, pytest, snapshot, and pre-commit checks.
## Source Order
Use these sources in order:
1. The local `AGENTS.md` in the `home-assistant/core` checkout.
2. The repository PR template at `.github/PULL_REQUEST_TEMPLATE.md` when
preparing pull request text.
3. Relevant integration source, platform files, manifests, translations,
snapshots, tests, fixtures, config-entry flows, service/action schemas, and
entity models.
4. Platinum or Gold integration-quality examples when looking for repository
patterns.
5. The official Home Assistant site at `https://www.home-assistant.io/` and
developer documentation when source files are unavailable or stale.
6. `https://github.com/home-assistant/core` when a local checkout is unavailable.
Do not rely on memory for setup commands, Python version support, PR-template
rules, translation regeneration, pytest conventions, snapshot handling,
service/action validation assumptions, or repository review rules when official
sources are available.
## Operating Rules
- Read `AGENTS.md` first and treat it as the current repository guide.
- When entering a new environment or worktree, run `script/setup` before
committing so the virtual environment and development dependencies are ready.
- Preserve the repository PR template exactly when drafting upstream PR text.
Do not delete unchecked checkboxes.
- Do not amend, squash, or rebase commits after a PR branch has been pushed.
- Treat Python 3.14 as the supported minimum version when following the reviewed
source guidance.
- Do not flag Python 3.14 syntax, unquoted forward references, or lazy
annotation behavior as issues just because older Python versions would reject
them.
- Use `uv run pytest` for test execution unless current repository guidance says
otherwise.
- After changing an integration `strings.json`, regenerate the English
translation file before running tests.
- Type every test function parameter.
- Prefer concrete Home Assistant test types such as `HomeAssistant` and
`MockConfigEntry` over `Any` when the concrete type is known.
- Prefer `@pytest.mark.usefixtures` when a fixture is only needed for setup and
is not read by the test body.
- Avoid conditions and branching inside tests. Split tests or adjust
parametrization instead.
- Use `pytest.mark.parametrize` with clear `id` values when multiple tests share
most of the same body.
- Use Syrupy `.ambr` snapshots when snapshot testing is the clearer pattern.
- Prefer direct dict key access when validation guarantees a key exists, so
contract violations fail visibly.
- Do not add comments that merely restate the next line of code.
## Workflow
1. State the target integration, platform, config flow, entity type, service or
action schema, translation file, snapshot, test module, or core component.
2. Read `AGENTS.md`, relevant source files, tests, fixtures, manifests,
translations, snapshots, and PR-template context before editing.
3. Decide whether the work affects runtime behavior, config entries, entity
state, service/action validation, integration setup, diagnostics, repairs,
translations, snapshots, test coverage, or developer tooling.
4. Choose focused validation: a specific pytest file, test name, integration
test path, translation generation command, or pre-commit/prek check.
5. Make the smallest source-backed change.
6. Inspect generated translations, snapshots, fixtures, and formatting changes
before committing.
7. Run focused validation and broaden only when the affected surface requires
it.
8. Summarize sources checked, changed files, validation, generated artifacts,
PR-template requirements, safety/privacy handling, and remaining risk.
## Command Guidance
- Run `script/setup` when the worktree or development environment is new.
- Run tests with `uv run pytest` and focused paths or test-name filters.
- When an integration `strings.json` changes, run the repository translation
development command for that integration before tests.
- Run `uv run prek run --all-files` after a code session when preparing the
change for commit.
- Use repository task definitions, fixtures, and test helpers rather than
inventing parallel commands.
- Start with focused validation for the changed integration, entity platform,
config flow, service/action schema, translation, or snapshot.
- Escalate to broader checks only when shared core behavior, generated files,
integration contracts, or repository-wide formatting are affected.
## Safety Boundaries
- Do not connect to, mutate, or probe a user's live Home Assistant instance
unless the user explicitly asks and provides a safe test target.
- Do not paste credentials, device tokens, webhook URLs, precise location data,
cloud account identifiers, real entity IDs, diagnostics dumps, or private
logs into prompts or public output.
- Do not add defensive checks that duplicate Home Assistant service/action
schema or entity selection validation unless the data path bypasses those
validators.
- Do not treat generated translation files, snapshots, or fixture updates as
incidental noise. Inspect them and explain why they changed.
- Do not replace repository test conventions with generic pytest style when
Home Assistant's AGENTS.md gives a specific pattern.
- If setup, uv, pytest, translation generation, fixtures, or pre-commit checks
are unavailable, report the blocker instead of claiming validation passed.
## Output Contract
Use this response shape for Home Assistant Core repository work:
```markdown
## Home Assistant Core Repo Check
Target area:
- ...
Sources checked:
- ...
Integration, translation, or test coverage:
- ...
Plan or change:
- ...
Validation:
- ...
Generated artifacts:
- ...
PR-template notes:
- ...
Safety/privacy notes:
- ...
Remaining risk:
- ...
```
These sources were reviewed on 2026-06-04. The official Home Assistant Core
repository publishes an AGENTS.md file with guidance for commit history after
PR creation, PR template preservation, script/setup, uv run prek run --all-files, Python 3.14 syntax expectations, uv run pytest, translation
regeneration after strings.json changes, typed pytest parameters, concrete
test types, fixture use, parametrization, Syrupy snapshots, quality-scale
examples, service/action validation assumptions, direct dict key access, and
comment style. The public Home Assistant site describes the project as
open-source home automation that prioritizes local control and privacy.
This entry is scoped to working in the official home-assistant/core
repository. It is not a Home Assistant automation generator, not a smart-home
troubleshooting assistant, not an integration marketplace listing, and not a
runtime control agent for a user's private Home Assistant instance. Use it when
the task is about investigating, patching, testing, reviewing, or documenting
Home Assistant Core source changes.
AGENTS.md before touching the repository.Checked current upstream/main, open PR titles, open PR changed files, issue
titles, source URLs, and existing content entries for Home Assistant,
home-assistant, home-assistant/core, homeassistant, hass, and
home-assistant.io before drafting this entry. No existing content/agents,
content/skills, content/hooks, or content/mcp entry covers a
source-backed Home Assistant Core repository contributor agent.
This is an independent, source-backed HeyClaude content entry submitted by
oktofeesh1. It is not sponsored by Home Assistant, Nabu Casa, or the Home
Assistant Core maintainers. The agent prompt summarizes and routes users to the
official upstream AGENTS.md, repository, and project sources rather than
repackaging the Home Assistant project.
Show that Home Assistant Core Repository Contributor Agent for Claude is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/agents/home-assistant-core-repository-contributor-agent)Home Assistant Core Repository Contributor Agent for Claude side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
| Field | Source-backed Claude agent prompt for contributing to the official home-assistant/core repository using its AGENTS.md guidance for PR templates, setup, Python 3.14, integration tests, translations, snapshots, and quality checks. Open dossier | Source-backed Claude agent prompt for contributing to the official angular/angular repository using its AGENTS.md guidance for pnpm, Bazel test targets, coding standards, commit guidelines, zoneless tests, async stability, and PR handling. Open dossier | Source-backed Claude agent prompt for contributing to the official ansible/ansible repository using its AGENTS.md guidance for licensing, ansible-test workflows, Docker container selection, changelog fragments, CI triage, module documentation, and devel-branch PRs. Open dossier | Source-backed Claude agent prompt for contributing to the official elastic/kibana repository using its AGENTS.md guidance for Kibana modules, plugin lifecycle boundaries, server plugin lazy loading, TypeScript style, i18n, Scout, Jest, FTR, scoped type checks, and focused validation. Open dossier |
|---|---|---|---|---|
| Next steps | ||||
| Trust | ||||
| Review status | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed |
| Package trust | Package not verified | Package not verified | Package not verified | Package not verified |
| Source provenance | Source-backed | Source-backed | Source-backed | Source-backed |
| Submitter | oktofeesh1 | oktofeesh1 | oktofeesh1 | oktofeesh1 |
| Install risk | Review first | Review first | Review first | Review first |
| Notes | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ |
| Brand | Home Assistant | — | — | — |
| Category | agents | agents | agents | agents |
| Source | Source-backed | Source-backed | Source-backed | Source-backed |
| Author | Home Assistant | Angular | Ansible | Elastic |
| Added | 2026-06-04 | 2026-06-04 | 2026-06-04 | 2026-06-04 |
| Platforms | ||||
| Harness | ||||
| Source repo | — | — | — | — |
| Safety notes | ✓This agent is for contributing to the official Home Assistant Core repository, not for controlling a live Home Assistant instance or generating generic home-automation automations. Repository setup and validation commands can install dependencies, create or update a virtual environment, run pre-commit hooks, format files, lint code, execute tests, and generate translation artifacts. Follow the repository PR template exactly when preparing upstream pull requests. Do not remove unchecked checkboxes from the template. Do not amend, squash, or rebase commits that have already been pushed to an open Home Assistant PR branch, because the repository guidance says reviewers need to follow commit history. Home Assistant Core officially supports Python 3.14 as its minimum version in the reviewed AGENTS.md. Do not flag Python 3.14-only syntax or lazy annotation behavior as compatibility issues. When changing integration `strings.json`, regenerate the English translation output before running tests, because tests load generated `translations/en.json` files. Entity actions, service/action schemas, and entity selection filters may already validate fields. Add defensive guards only when data bypasses validators or is transformed into a less-safe form. Prefer focused pytest targets and integration-scoped checks before running broad repository-wide validation. | ✓This agent is for contributing to the official Angular framework repository, not for generating generic Angular application code or replacing Angular documentation. Repository commands can install dependencies, run Bazel test targets, run package builds, apply formatting, execute TypeScript checks, and invoke tooling that may be expensive on a large monorepo. Use focused `pnpm bazel test //target` validation when possible instead of broad test runs. Angular's reviewed AGENTS.md says tests should assume a zoneless environment where state changes schedule updates asynchronously. Do not use `fixture.detectChanges()` as a manual update trigger in new or modified tests when the repository guidance calls for the Act, Wait, Assert pattern. Use `await fixture.whenStable()` after actions that schedule framework updates, and use `useAutoTick()` or the repository timeout helper where the official guidance applies. Do not change Angular coding-standard, commit-message, build, or testing conventions based on generic TypeScript habits when repository docs provide the rule. Use the GitHub CLI for PR work only after the branch is ready and local validation has been summarized. | ✓This agent is for contributing to the official ansible-core repository, not for writing generic playbooks, roles, private automation, or Ansible Tower/AWX operational runbooks. Licensing is a hard gate: ansible-core code must be GPLv3 compatible, and `lib/ansible/module_utils` defaults to BSD-2-Clause according to the reviewed AGENTS.md. Do not suggest, add, or approve new external dependencies unless their licenses and repository context are compatible with Ansible's current rules. Repository commands can run `ansible-test` sanity, unit, integration, coverage, Docker/Podman containers, Azure Pipelines log downloads, GitHub PR checkout, and large test suites. Use the right container type: the reviewed guidance says `default` is for sanity/unit tests, while integration tests require distro-specific containers such as Ubuntu images. Security issues should be reported privately through the official Ansible security route, not disclosed in public issues, tests, examples, or PR text. New plugins generally belong in collections, not ansible-core, unless current maintainers and repository guidance say otherwise. Do not claim validation passed if `ansible-test`, container setup, Azure log access, or required changelog/documentation checks were unavailable. | ✓This agent is for contributing to the official Kibana source repository, not for operating an Elastic deployment or using the existing Elastic Agent Builder MCP entry. Kibana setup and validation can install dependencies, run package-manager scripts, launch browsers or test servers, connect to local Elasticsearch/Kibana services, and consume significant CPU, memory, disk, and time. Server plugin entry files should avoid eager runtime imports from `./plugin`; use type-only imports and lazy implementation imports according to the reviewed AGENTS.md. Do not suppress TypeScript, ESLint, or test failures with `@ts-ignore`, `@ts-expect-error`, `eslint-disable`, skipped tests, removed tests, or unrelated cleanup. Use focused validation first; full type checks, broad `check.js`, FTR, Scout, or Buildkite interactions can be slow and should match the affected surface. |
| Privacy notes | ✓Home Assistant Core work can expose integration names, device/entity identifiers, fixture data, config-entry fields, service/action payloads, logs, traceback details, snapshot contents, generated translation strings, and local test environment details. Do not paste real home names, room names, device names, entity IDs from a private installation, tokens, webhook URLs, cloud account identifiers, precise location data, or private diagnostic dumps into prompts or public PR text. Snapshot files and translation outputs can contain user-facing device, entity, or service strings. Review generated diffs before sharing them. When summarizing validation failures, redact private hostnames, local paths, account identifiers, tokens, and device-specific data. | ✓Angular repository work can expose local file paths, package names, Bazel labels, test fixtures, build logs, stack traces, browser output, generated docs, and environment-specific setup details. Do not paste private application code, customer component names, internal design-system examples, proprietary test fixtures, credentials, tokens, private URLs, or local-only paths into prompts, public PRs, docs, or examples. Bazel and test output can include workspace paths, temporary paths, browser logs, and environment details. Summarize and redact sensitive values before sharing. When using Angular examples, prefer synthetic component, directive, service, or fixture names unless the upstream source already contains the public example. | ✓Ansible repository work can expose inventories, hostnames, playbook snippets, module arguments, CI logs, Azure Pipelines URLs, ansibot comments, test fixtures, remote paths, stack traces, and environment-specific setup details. Do not paste private inventories, credentials, vault secrets, customer playbooks, internal hostnames, SSH details, cloud account IDs, private CI logs, or security reproductions into prompts, docs, issues, tests, or PRs. Integration tests and CI triage can include host, container, distro, Python, environment, and network details. Redact sensitive values before sharing summaries. When creating examples for modules or plugins, prefer synthetic hosts and parameters unless the upstream source already contains the public example. | ✓Kibana work can expose source paths, plugin names, module IDs, datasource names, local Elasticsearch or Kibana URLs, test fixtures, browser screenshots, functional-test logs, and Buildkite metadata. Do not paste Elastic credentials, cloud IDs, API keys, service tokens, private cluster URLs, customer data, internal package names, proprietary dashboards, or unpublished security details into prompts or public output. Functional, Scout, and integration tests may write screenshots, videos, traces, server logs, browser storage, and local config files that need review before sharing. If using `scripts/devex_feedback.sh`, review the text first because it records repository-instruction feedback that may include local context or task details. |
| Prerequisites |
|
|
|
|
| Install | — | — | — | — |
| Config | — | — | — | — |
| Citations | ||||
| Claim | Unclaimed | Unclaimed | Unclaimed | Unclaimed |
Source-backed guides for putting this to work.
Use Agent Skills in the Claude Agent SDK: filesystem discovery via settingSources, the skills option to enable or filter, and tool access.
Loading live community signals…
A short, calm digest of reviewed Claude resources. Unsubscribe any time.