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.
npx agentmods add agents/homeassistant-ai/ha-mcp/github-workflowgit clone --depth 1 https://github.com/homeassistant-ai/ha-mcpWhat 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 | $0.00000 | $0.02504 |
| Opus 5 | $0.00000 | $0.01252 |
| Sonnet 5 | $0.00000 | $0.00501 |
| Haiku 4.5 | $0.00000 | $0.00250 |
Grade A, and why
github-workflow 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.
How it starts
The opening of the file, as written. The whole thing — 224 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitHub workflow reference
Read this document before triaging issues, changing GitHub automation, managing
a pull request, or preparing a release. Repository-wide behavioral rules remain
in AGENTS.md; this file owns the detailed commands,
labels, bot behavior, and workflow inventory.
Automated review
Codex reviews pull requests through pr-codex-review-request.yml and
pr-codex-review-delivery.yml, posting as
chatgpt-codex-connector[bot]. The request explicitly applies
.gemini/styleguide.md. Gemini Code Assist is
retired; .gemini/config.yaml disables the app, but the style guide remains
the repository's code-review criteria.
CodeRabbit reviews drafts. .coderabbit.yaml deliberately sets:
reviews.auto_review.drafts: trueauto_pause_after_reviewed_commits: 0(the schema default pauses after five reviewed commits)reviews.pre_merge_checks.docstrings.mode: "off"(the default 80% repository-wide coverage quota is disabled; ordinary guideline-based docstring review remains enabled)
The second setting spends the per-developer hourly review allowance faster. A
rate-limited push reports that state in a comment and does not block merging;
@coderabbitai rate limit reports availability without requesting a review.
CodeRabbit auto-detects AGENTS.md; the style guide is added through
knowledge_base.code_guidelines.filePatterns.
Repository YAML outranks CodeRabbit UI settings and does not merge with them.
Omitted keys use schema defaults. On public repositories, a change to
.coderabbit.yaml does not govern its own pull request because CodeRabbit
uses the base branch configuration.
The tell on the pull request changing the file is
Configuration used: defaults; the new rules take effect only after merge.
Dependabot, Renovate, and github-actions[bot] webhook-proxy promotion pull
requests are excluded from automatic Codex and CodeRabbit review. Their exact
lists are kept in lockstep by test_coderabbit_config.py. A maintainer can
still request review on a promotion pull request with
@coderabbitai review, or request Codex with a comment that is exactly
/review or @ghhamcp review.
.coderabbit.yaml's ignore_usernames and the
pull_request_target admission list enforce the exclusion. The
issue_comment admission list deliberately omits github-actions[bot], so
a maintainer's exact manual-review command remains the only way to admit a
promotion pull request.
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.
- today First seen · 224 lines · 0 tokens per session scan A bc47c80ea34f
github-workflow is an agent published in the GitHub repository homeassistant-ai/ha-mcp (4,594 stars, last pushed today), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,504 tokens. 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-09-02.
Other agents, from other repositories
raise-pull-request
Use this agent when creating a pull request for the Home Assistant core repository after completing implementation work. This agent automates the PR creation process including running tests, formatting checks, and proper checkbox handling.
blocky-bump-review
The concrete definition of what CLAUDE.md calls the manual review a Blocky bump requires. Renovate opens these as a one-line change to BLOCKYVERSION in blocky/Dockerfile (Tempio bumps are the same shape via TEMPIOVERSION). Most bumps merge as that bare one-liner — this runbook is how you earn that conclusion instead…
ha-esphome-config-reviewer
Produces one bundled, read-only device-level review of an ESPHome device configuration: config-pattern conformance, credential and API/OTA hardening, schema currency against the official ESPHome docs, Home-Assistant-driven binding correctness, display rendering discipline, display design conformance (palette roles…
ha-integration-reviewer
Produces one bundled, read-only integration-review report for a Home Assistant Custom Integration: quality-scale tier assessment, security/hardening review, and cross-cutting consistency checks (manifest-tier coherence, translations, diagnostics redaction, device classes, spec drift, upstream-docs spot-check).…
ha-dev-instance-provisioner
Provisions a disposable development Home Assistant instance into a local Kubernetes cluster (typically Kind) by applying a self-generated StatefulSet + Service + /config PVC manifest, waiting for rollout, and preparing /config/customcomponents — so that ha-integration-deployer can then copy an integration into it.…
ha-integration-verifier
Diagnoses a deployed Home Assistant Custom Integration in a running HA pod inside a Kind / local Kubernetes cluster — pod-status check, recent-log scan with error-pattern detection, installed-files verification — and return a structured health report. Read-only: never deploys, never restarts, never modifies state. Use…