nolte
UserShared Claude Code skills and agents for consistent development workflows across projects.
Categories
Indexed Skills (114)
api-error-check
Statically checks a web API's error-handling surface for conformance against the project's own declared error contract — uniform error-body shape, populated required fields, a dynamically-generated error/correlation id, correct HTTP status-code semantics, and no internal-detail leakage (stack traces, raw driver messages, rendered queries, secrets). Detects the web framework (FastAPI / Flask / Django REST / Express / NestJS / Spring and comparable) and the error contract from project signals, falling back to RFC 9457 defaults only when none is declared. Invoke after adding or changing endpoints, before a release, or as a pre-PR error-handling gate; also on requests like "check the API error handling", "audit error responses", or equivalent German-language requests. Read-only: reports and recommends, never edits handler code. Don't use for the whole-codebase security audit (code-security-reviewer) or general code review (review skill).
dependency-audit
Scans the current project's dependency tree for known vulnerabilities (CVEs) and, when requested, license-compliance issues. Dispatches dependency-audit-scanner agent for the read-only scan step. Detects project kind from `pyproject.toml` / `requirements*.txt` / `poetry.lock` / `uv.lock` for Python and `package.json` / `package-lock.json` / `pnpm-lock.yaml` / `yarn.lock` for Node, runs the appropriate auditors, and produces a severity-sorted report with direct vs transitive attribution. Invoke when the user asks to "audit dependencies," "run a CVE scan," "check for vulnerable packages," "check the license allowlist," "run pip-audit," "run npm audit," or equivalent German-language requests. Also handles a pre-PR / pre-release dependency gate. Don't use for upgrading dependencies (an author's decision), for writing Renovate configs (`project-structure-apply`), or for the full license inventory / SPDX compliance process (`license-check`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
dockerfile-audit
Audits a project's Dockerfiles against spec/project/dockerfile-best-practices/ and produces a severity-classified audit artifact. The default `audit` operation dispatches the read-only dockerfile-audit-scanner agent, then hard-fails on any missing mandatory OCI core label (source, title, description, version, revision, created) present in neither the Dockerfile nor CI injection, and on any of the four mandatory non-label pillars (non-root numeric USER, in-layer secrets, base not pinned by tag+digest, missing .dockerignore); advisory pillars are scored. The opt-in `apply` operation inserts or merges the OCI LABEL block into the final stage. Invoke when the user asks to "audit a Dockerfile," "check OCI image labels," "run a Dockerfile best-practices check," or equivalent German-language requests. Don't use for dependency CVEs (dependency-audit), license inventory (license-check), or Kubernetes runtime hardening (deployment-bestpractices-reviewer). Supports resume per spec/claude/resumable-work/.
kpi-derive
Derives a business application's project-specific KPIs from its goals, requirement documents, and source code, writing a human-readable artifact to project/kpis/<slug>.md per spec/project/kpi-definition-process/. The `derive` operation dispatches the read-only kpi-signal-scanner agent, walks a GQM refinement (goal to question to metric), selects the key metrics as KPIs with the operator, and defines each against the SMART gate with a leading/lagging class; `revisit` re-derives against changed goals. Consumes an existing project/requirements/<slug>.md under a soft gate (warns and recommends requirements-elicit when absent, never blocks). Determination and definition only — never measurement, instrumentation, telemetry, or dashboarding. Invoke to derive KPIs, determine an app's KPIs, or define its key metrics; also German requests. Don't use to elicit requirements (requirements-elicit) or to build instrumentation or dashboards (fullstack-developer). Supports resume per spec/claude/resumable-work/.
license-check
Runs an end-to-end license-compliance check on the current project per spec/project/license-check/ and produce a license-check audit artifact. Dispatches license-check-scanner agent for the read-only inventory (SBOM with resolved licenses, SPDX identification, category classification), then applies the permissive-leaning allow/review/deny policy gate against the project's own outbound license, drives per-finding remediation (replace / exception with rationale / satisfy the obligation), verifies attribution/NOTICE and REUSE, records AI provenance, and writes the artifact under .audits/license-check/. Invoke when the user asks to "run a license check," "check license compliance," "audit licenses," "do a Lizenzcheck," "prüfe die Lizenzen," or for a pre-PR / pre-release license gate. Don't use for CVE / vulnerability scanning (that's dependency-audit) or for choosing the project's own outbound license. Supports resume on re-invocation per spec/claude/resumable-work/.
observability-audit
Audits an app's observability against spec/project/monitoring-observability/ and produces a severity-classified audit artifact plus an implementation plan for the gaps. The default `audit` operation dispatches the read-only observability-audit-scanner agent, then hard-fails on any missing-or-unwired mandatory pillar (metrics, structured logs, distributed traces, health + SLO + alert), the frontend and third-party floors, and the cardinality and PII-redaction guardrails; runtime-only behaviour is documented verify-at-runtime. The `plan` operation dispatches implementation-plan-author with the findings so a specialist (fullstack-developer) implements the instrumentation — there is no mechanical apply. Invoke to audit observability, check OTel instrumentation, or run an observability best-practices gate; also German. Don't use for Kubernetes probe wiring (deployment-bestpractices-reviewer), the PII/GDPR verdict (gdpr-data-protection-reviewer), or Dockerfile labels (dockerfile-audit). Supports resume.
release-regression-scope
Determines the release-relevant regression/E2E test scope from a release change-set per spec/project/release-regression-scope/, so a team runs targeted-but-safe regression before rollout. The default `scope` operation resolves the release range, dispatches the read-only release-regression-scope-scanner to attribute each change to its impacted areas via traceability inversion (change → requirement/TC-ID → verifying tests), selects the minimal tier/test set (E2E emphasised) covering those areas, widens non-attributable changes to worst-case full-area regression, and reports an auditable scope (in-scope areas, selected tests, exclusions + rationale, residual risk). A missing verifying test is a coverage-gap blocker. Invoke to scope release regression, pick targeted E2E, or gate a rollout on a fast subset; also German. Don't use to derive test cases (test-case-extractor), run tests (quality-gate), audit pyramid shape (test-pyramid-check), or drive the release (release-publish-trigger). Supports resume.
test-pyramid-check
Audits a feature's or module's test-tier completeness against the closed functional-tier taxonomy in spec/project/test-pyramid-foundation/ (are the applicable tiers — unit, component, integration, contract, E2E — present and written at the lowest tier that gives confidence?) and whether the E2E tier follows the disciplines in spec/project/e2e-test-automation/ (page-object encapsulation, condition-based waits, screenshot checkpoints, markers, TC-ID traceability). Detects the stack, globs the test files per tier, and returns a gap report. Invoke when the user asks to "check the test pyramid," "audit test-tier completeness," "verify all test levels exist," after a feature is implemented, or before a release; also handles equivalent German-language requests. Don't use to scaffold E2E tests (use e2e-test-generator), to review/repair an E2E suite (use e2e-test-reviewer), to review a run's screenshots (use e2e-result-reviewer), or to run the lint/typecheck/test gate (use quality-gate).
webview-ui-optimize
Audits a browser-rendered frontend against the canonical-language file under spec/frontend/webview-ui-optimization/ and, with per-item user approval, patches findings across five domains: Performance, Security, Accessibility (WCAG 2.2 AA), Internationalisation, and UX. Three operations: `audit` (written to `.audits/webview-ui-optimize/`), `patch` (one finding at a time), `expert-review` (dispatches `webview-ui-expert`). Invoke when the user asks to "audit the frontend", "check the UI against the webview-ui spec", "optimise for performance / a11y / i18n / UX / security", "fix the CSP", "wire up vitest-axe", or equivalent German-language requests. Don't use for brand-design decisions, audience artefact (`audience-identify`), prose linting (`prose-vale-curator`), CVE audits (`dependency-audit`), or the release pipeline (`release-publish-trigger`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
gemini-image-handoff
Runs a semi-automatic Gemini image-generation handoff. The automated half authors a Gemini-optimised prompt from a brief per `spec/design/gemini-image-generation/`; the manual half guides the operator to paste it into the Gemini web UI (the Gemini app or AI Studio) and download the image from the chat. No API call, no billing, no `GEMINI_API_KEY`, and the skill writes no image and no sidecar — the operator places the downloaded file. Invoke when the user wants a Gemini image without enabling API billing, asks for a "Gemini prompt to paste into the UI", wants the manual Gemini chat route, or makes an equivalent German-language request ("Bild über die Gemini-UI generieren", "Prompt zum Einfügen in Gemini"). Don't use to call the Gemini API and write a file (use image-generate --provider gemini), to author a brand-conformant prompt document (use graphic-prompt-generator), or for FLUX/Cloudflare generation (use image-generate). Resume is not applicable: the handoff is a single interactive turn.
image-generate
Generates an image from a text prompt via a pluggable provider backend, writing the image plus a `<image>.meta.json` sidecar to an operator-chosen path. Backends are swappable via `--provider`: cloudflare (Cloudflare Workers AI FLUX.1-schnell, real free tier, DEFAULT), pollinations (auth-free, but public-feed/undocumented-licence — the tool forces private=true and shows a disclaimer), gemini (gemini-2.5-flash-image, requires billing). Wraps the bundled, stdlib-only `scripts/image_generate.py`. Invoke when the user asks to "generate an image", "create a hero image or icon from a prompt", "render this prompt to a PNG", "turn a graphic-prompt-generator document into an image", or equivalent German-language requests. Don't use for image editing, in-painting, or multi-turn refinement; for batch pipelines; or to author the prompt itself (use graphic-prompt-generator). Supports resume is not applicable: a generation is a single terminal call.
agent-review
Reviews a Claude Code agent against spec/claude/agent-management/ and spec/claude/skill-vs-agent/, and emit an actionable review plan per spec/claude/review-plan/ under .audits/agent-review/ keyed by the target agent's name. Invoke when the user asks "review this agent", "audit a specific agent file", "check whether this agent is spec-compliant", or "agent review for a specific agent". Also handles closing an existing review plan once every item is addressed — "close the agent review plan for a specific agent". Also handles equivalent German-language requests. Do NOT use for skill review (use skill-review) or for pull-request-level review (`review` skill). Supports resume on re-invocation per `spec/claude/resumable-work/`.
audience-identify
Runs the audience-identification methodology from spec/project/audience-identification/ against a bounded context (software module, service, library, or whole project) and produces an authoritative audience artifact. Invoke when the user says things like "identify audiences for this module", "who are the consumers/users of X", "stakeholder identification for X", "audience analysis before I write the README / SLA / threat model", "list the audiences of this library", or equivalent German-language requests. Also triggers when another spec or skill (readme-structure, future SLA or threat-modeling specs) needs to reference an audience list that does not yet exist for the current context. Don't use to review an existing audience artifact for compliance (use audience-review). Supports resume on re-invocation per `spec/claude/resumable-work/`.
backstage-catalog-generate
Generates a schema-valid Backstage catalog-info.yaml from an existing software project, conforming to spec/project/backstage-catalog-generation/. Inspects the repo (language/structure, remote slug, CODEOWNERS, OpenAPI/AsyncAPI/GraphQL/gRPC specs, colocated docs), infers the per-kind MUST-floor fields, confirms what it cannot infer (owner, spec.system, dependsOn, lifecycle) with the operator, writes the descriptor at the repo root, and self-validates. Invoke when the user asks to "generate a catalog-info.yaml", "onboard this repo into Backstage", "create a Backstage Software Catalog entity", "add this service to our developer portal", or German equivalents ("erzeuge eine catalog-info.yaml", "nimm dieses Repo in Backstage auf"). Optionally emits a Tech Radar TechRadarLoaderResponse JSON (never a catalog entity). Don't use to configure a Backstage backend / catalog.providers, install the Tech Radar UI plugin, or ingest Group/User org entities. Single-shot; resume not applicable.
blog-author-trigger
Operationalises spec/project/blog-author-trigger/: on a feature→done transition it derives a blog-post briefing from the feature record, computes a new/update/defer suggestion from the blog consumer's existing-post index, presents the three-way operator choice, and either dispatches blog-author with the derived briefing (Choices 1 and 2, via the cross-repository handover with explicit operator confirmation) or writes a deferral artefact under project/blog-triggers/ (Choice 3). Typically automatically dispatched by sprint-execute right after a feature reaches done; also invocable directly ("trigger a blog post for feature X", "Blog-Trigger für Feature X", "soll ich zu Feature X bloggen?"). Don't use to draft the post itself (use blog-author), to define the feature record (feature spec), to close a sprint (sprint-review), or to publish a release (release-publish-trigger). Supports resume on re-invocation per spec/claude/resumable-work/.
blog-author
Drafts a bilingual EN-canonical + DE-translated blog-post pair per this plugin's blog-author, post-writing-style, and post-audience-communication specs. Walks the operator through briefing inputs (topic-as-thesis, grounded artefact, primary audience, source list, slug, cross-language binding key), writes the EN draft, runs the pre-handover self-check, writes the DE translation, runs the per-pair self-check, executes the consumer's build command (reference `task build`), and dispatches `lektorat-apply` for the editorial audit. Invoke when the user asks to "schreibe einen neuen Blogpost", "draft a blog post about X", "neuer Eintrag zu Y", "operationalize blog-author", or equivalent German-language requests. Don't use to lektor an existing post (use `lektorat-apply`), to author portfolio pages (those live in the consumer's portfolio collection), or to redefine the consumer's post-frontmatter schema. Supports resume on re-invocation per `spec/claude/resumable-work/`.
continuous-improvement-triage
Operationalises spec/project/continuous-improvement/ by triaging portfolio audit findings, classifying them against the available specialist catalog, and dispatching hands-on remediation to the most specialised available Claude agent or skill. Invoke when the user asks to "triage continuous-improvement findings", "classify a portfolio-improvement opportunity", "dispatch findings to specialised agents", "run the quarterly specialist-coverage review", "check whether a finding class needs a new specialist", or equivalent German-language requests. Drives the three-operation loop: audit (periodic specialist-coverage review), update (record decisions and dispatch specialists), close (terminate the triage cycle). Applies the three-recurrence gap-closure rule and records all dispatch decisions in fix-PR Risk / rollout notes. Do not use to perform the hands-on remediation itself—that belongs to the dispatched specialist. Supports resume on re-invocation per `spec/claude/resumable-work/`.
cookiecutter-template-manage
Manages the lifecycle of a Cookiecutter template: scaffolds a new template or refactors an existing one (with mid-flow user confirmation of variable names and choice defaults), hardens Cookiecutter hooks, and sets up a pytest-cookies test harness. Invoke when the user says "manage a Cookiecutter template lifecycle", "scaffold or refactor a Cookiecutter template (with name + purpose confirmation)", "harden cookiecutter hooks", "set up pytest-cookies harness", "Cookiecutter-Template anlegen", "Cookiecutter-Template überarbeiten", "Cookiecutter-Hook absichern", or "pytest-cookies einrichten". Don't use for plain template consumption (a bare `cookiecutter <url>` call needs no orchestration), generic Python bootstrap, Copier or cruft work, or intentionally diverging templates. Supports resume on re-invocation per `spec/claude/resumable-work/`.
docs-audience-tracks-apply
Audits a repository against the canonical-language file under spec/project/docs-audience-tracks/ and, with per-item user approval, scaffolds or patches the documentation-tracks layer: per-page `track:` frontmatter across the per-language docs/ tree, required user-docs and developer-docs content blocks, and the audience-to-track mapping in the project's audience artefact. Three operations: `audit` (read-only conformance report), `migrate` (brownfield), `patch` (additive fixes one finding at a time). Invoke when the user asks to apply, audit, migrate, or patch documentation tracks against the spec; also handles equivalent German-language requests. Don't use for the MkDocs skeleton (`mkdocs-structure-apply`), audience artefact (`audience-identify`), page content (`audience-doc-author`), drift detection (`docs-freshness-checker`), or prose mechanics (`prose-vale-curator`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
docs-dry-refactor
Operationalises spec/project/mkdocs-structure/ §Snippet inclusion (DRY). Detects paragraph duplication across MkDocs pages and, with per-snippet user approval, extracts duplicates into `mkdocs-include-markdown-plugin` includes pointing at a canonical source (preferring a live source file over a dedicated per-language _snippets/ folder). Three operations: `audit` (read-only ranked findings), `propose` (surface canonical source, markers, include directives for a target snippet ID, await approval), `apply` (write markers, replace consumer blocks, verify via `mkdocs build --strict`). Invoke when the user asks to dedupe, DRY-refactor, extract snippets, or factor out duplicated MkDocs content; also handles equivalent German-language requests. Don't use for non-MkDocs markdown trees, single-file snippet authoring, prose linting (`prose-vale-curator`), structural scaffolding (`mkdocs-structure-apply`), or drift detection (`docs-freshness-checker`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
github-issue-templates-apply
Applies the canonical-language file under spec/project/github-issue-templates/ to a target repository — detect the project type, resolve or dispatch the audience artefact, derive triage questions, and scaffold or update .github/ISSUE_TEMPLATE/ (bug_report.yml, feature_request.yml, config.yml, plus project-type-specific extras) as GitHub Issue Forms. Invoke when the user asks to "generate issue templates for this repo", "scaffold GitHub issue forms", "create bug and feature templates", "set up .github/ISSUE_TEMPLATE", "apply the github-issue-templates spec", or equivalent German-language requests. Don't use for pull-request templates (that's `pull-request-workflow`), CODEOWNERS / SECURITY.md, discussion templates, or generic .github/ scaffolding (that's `project-structure-apply`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
lektorat-auto-revise
Autonomously works off a `lektorat audit` findings report by routing each artefact by type — documentation to the `audience-doc-author` agent (fully autonomous), blog posts to the `blog-author` skill (assisted) — composing a per-file briefing that binds the audience artefact and writing-style spec, letting the author revise, then re-auditing until no finding above the severity floor remains and there is no regression. Operationalises `spec/project/lektorat-auto-revise/`. Invoke when the user asks to "arbeite das Lektorat-Audit automatisch ab", "auto-revise the audit findings", "remediate the lektorat findings with the right author", or equivalent EN/DE requests. Don't use for the read-only audit or interactive per-finding fixes (use `lektorat-apply`), or for first authorship (`audience-doc-author`/`blog-author`). Writes to `.audits/lektorat-auto-revise/<YYYY-MM-DD-HHMM>/`. Supports resume per `spec/claude/resumable-work/`.
mermaid-diagrams-apply
Audits and applies the MkDocs Mermaid setup of the current repository against `spec/project/mermaid-diagrams/<canonical_language>.md`, and helps an author add a single Mermaid diagram (hand-described or derived). Wires up `pymdownx.superfences`, pins `pymdown-extensions`, refuses `mkdocs-mermaid2-plugin`. Picks the diagram type from the supported catalog and prepends the mandatory `<!-- diagram-source ... -->` marker. Audits flag missing source markers, missing direction headers, inline styling, `gitGraph` usage, non-English labels, and derived-source drift. Invoke when the user asks to "wire up Mermaid", "audit Mermaid setup", "draft a flowchart", or equivalent German-language requests. Don't use for general MkDocs scaffolding (use `mkdocs-structure-apply`), spec authoring (use `spec`), the docs-freshness audit (use `docs-freshness-checker`), or non-Mermaid diagrams. Supports resume on re-invocation per `spec/claude/resumable-work/`.
mission-define
Authors a project's first `project/mission.md` per the canonical-language file under spec/project/mission/. Invoke when the user says "define the mission", "write project/mission.md", "set up the mission file", "draft the SMART mission", or equivalent German-language requests. Walks SMART one letter at a time (Specific statement, Measurable verifies_via pointer, Achievable MVP scope, Relevant outcome IDs, Time-bound shape), gathers a per-audience MVP-deliverable paragraph, composes the frontmatter plus the four required body sections (Statement, Audiences, Verification, Source), and writes the file with `mvp_status: defining`. Refuses to run when `project/mission.md` already exists (use `mission-revise`) or when `project/goals.md` or the audience artefact is missing. Supports resume on re-invocation per `spec/claude/resumable-work/`.
mission-revise
Revises an existing `project/mission.md` per the canonical-language file under spec/project/mission/. Invoke when the user says "revise the mission", "update project/mission.md", "flip mvp_status", "the MVP is achieved", "the stabilisation gate is satisfied", or equivalent German-language requests. Supports three operations: (1) revise statement, audiences, verifying-feature pointer, or time_bound; (2) flip `mvp_status` along the legal lifecycle (`defining→in_progress→achieved→stabilised`, plus regression path); (3) revise after stabilisation with the mandatory rationale. Verifies the stabilisation-gate conditions by reading `project/roadmap.md` and `project/sprints/` before allowing a flip to `stabilised`. Supports resume on re-invocation per `spec/claude/resumable-work/`.
mkdocs-structure-apply
Audits a repository against the canonical-language file under spec/project/mkdocs-structure/ and, with per-item user approval, scaffolds or patches the MkDocs skeleton: the per-language docs/ tree, seven standard nav sections, plugin baseline (incl. mkdocs-include-markdown-plugin), required `site_url`, pinned dep manifest, per-page frontmatter contract. Three operations: `audit` (read-only conformance report), `scaffold` (greenfield), `patch` (additive fixes). Invoke when the user asks to apply, audit, scaffold, or patch MkDocs against the spec; also handles equivalent German-language requests. Don't use for theme/typography decisions (per-repo), page-content authoring (use `audience-doc-author`), DRY refactoring (use `docs-dry-refactor`), per-page track frontmatter or audience-track content blocks (use `docs-audience-tracks-apply`), drift detection (use `docs-freshness-checker`), or catalog generator wiring (use `skill-agent-catalog-apply`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
permission-allowlist-maintain
Curates the committed `.claude/settings.json` `permissions.allow` list of the current repository per `spec/claude/permission-allowlist/`. Proposes additions sourced from the `fewer-permission-prompts` built-in or from the user, applies the spec's three-condition selection criteria (frequent + read-only + not-already-autoallowed), rejects forbidden pattern classes (interpreter wildcards, task-runner wildcards, mutation-capable `gh`/`git` wildcards), and routes every change through the standard pull-request flow. Invoke when the user asks to "tidy the permission allowlist", "add `Bash(task lint)` to the allowlist", "review `.claude/settings.json`", or equivalent German-language requests. Don't use to edit `.claude/settings.local.json` or `~/.claude/settings.json` (out of scope per spec). Supports resume on re-invocation per `spec/claude/resumable-work/`.
portfolio-audit
Audits, renders, and bootstraps the cross-repository capability portfolio across `nolte/*` per `spec/portfolio/portfolio-management/`. Audit dispatches portfolio-manifest-collector agent for read-only inventory collection, then detects capability duplicates, surfaces gaps, verifies tech-stack consistency per `spec/portfolio/tech-stack/`, and writes a Findings-Report under `.audits/portfolio/` using Critical / Warning / Suggestion / Info severities. Render regenerates the aggregated inventory under the per-language docs/ portfolio subtree. Bootstrap creates a repository's first `project/portfolio.yml`. Invoke when the user asks to "audit the portfolio", "check for portfolio duplicates", "render the portfolio inventory", "discover the tech stack" (audit view), or equivalent German-language requests. Don't use to consolidate duplicates (operator opens cross-repo PRs), to author new capabilities, or for per-repo tech_stack capture or refresh (use tech-stack-capture). Supports resume on re-invocation.
portfolio-inflight-triage
Runs the read-only periodic in-flight audit across nolte/* per `spec/portfolio/portfolio-inflight-management/`. Dispatches `portfolio-inflight-collector` for the four data sources (open issues, open PRs incl. drafts, branches without active PR, unresolved review threads + Discussions), applies spec stalling thresholds with optional `project/inflight.yml` overrides, classifies findings via the four-axis matrix into `Critical`/`Warning`/`Suggestion`/`Info`, attaches a specialist slug per finding, and writes a dated Findings-Report under `.audits/portfolio-inflight/`. Invoke when the user asks to "audit the portfolio in-flight", "run the in-flight triage", "check stalled PRs / issues / branches", or equivalent German-language requests. Don't use to merge / close / delete / resolve anything (operator dispatches), for per-repo CI triage (use `workflow-health-triage`), or for capability allocation (`portfolio-audit`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
project-structure-apply
Audits a repository against the canonical-language file under spec/project/project-structure/ and scaffolds or patches missing artefacts: README (delegated mid-flow to `readme-structure-apply`), top-level orientation file, .gitignore, .pre-commit-config.yaml, Renovate config, Taskfile, the MkDocs site skeleton (delegated mid-flow to `mkdocs-structure-apply`), .claude/ directory, and the full .github/ layout (workflows, settings.yml, release-drafter.yml, boring-cyborg.yml, stale.yml) with the portfolio-wide Probot extends pointers. Verifies via the GitHub API that the backing GitHub Apps (Probot apps `settings`, `boring-cyborg`, `stale`, plus Renovate) are installed; for Renovate also points at the Mend dashboard when the App is installed but no activity is visible. Invoke when the user asks to audit project structure, scaffold missing GitHub configs, generate release-drafter config, check Probot/Renovate app installation, or equivalent German-language requests. Supports resume on re-invocation.
pull-request-merge
Promotes an open draft pull request on the current branch to a merged state on `develop`, applying repository-declared labels and passing every gate from the pull-request-workflow spec. Invoke when the user asks to promote the draft PR, ship the PR, merge the draft, or bring the PR over the finish line. Also handles equivalent German-language requests. Delegates pre-merge review to the `review` skill (and `security-review` when the diff touches security-sensitive paths), derives labels from the Conventional-Commits type and touched paths, flips draft → ready, triggers automerge by applying the `automerge` label so the repository's automerge workflow squash-merges the PR once every required check is green, and verifies the merge commit landed on `develop`. Supports resume on re-invocation per `spec/claude/resumable-work/`.
readme-structure-apply
Audits the repository's `README.md` against the canonical-language file under spec/project/readme-structure/ and, with per-item user approval, scaffolds or patches the file: H1 + tagline, CI badges, six required sections in order (Purpose, Usage, Structure, Related repositories, Status, License), the consumer-first ordering rule, the ≤200-line length budget, and link rules. Three operations: `audit` (read-only conformance report), `scaffold` (greenfield), `patch` (additive fix). Invoke when the user asks to apply, audit, scaffold, or patch the README against the spec; also handles equivalent German-language requests. Don't use for docs/ page content (`audience-doc-author`), MkDocs nav (`mkdocs-structure-apply`), Vale prose linting (`prose-vale-curator`), or the audience artefact (`audience-identify`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
release-notes-curate
Augments the open release-drafter draft on develop with project-context-aware sections per the canonical-language file under spec/project/release-skill-layer/ §"Skill A — Draft notes curation". Reads the project's audience artefact, derives a section bundle from the detected project type, wraps the augmentation in stable HTML-comment markers so re-runs update in place, and writes the body back via `gh release edit` for a release tag. Invoke when the user asks to "curate the release notes", "shape the release notes for this repo", or equivalent German-language requests. Don't use to publish the release (use `release-publish-trigger`), to identify audiences (use `audience-identify`), to draft notes from scratch (use the `audience-doc-author` agent), or to scaffold issue / PR templates (use `github-issue-templates-apply`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
release-publish-trigger
Validates every release-automation pre-publish gate locally, then dispatches release-publish.yml via `gh workflow run` for the open release-drafter draft on develop, per the canonical-language file under spec/project/release-skill-layer/ §"Skill B — Release publish trigger". Verifies that exactly one open draft exists, the draft tag is reachable from the develop tip, version-bearing files align under their declared transform, every required status check on develop is SUCCESS, and `.github/workflows/release-publish.yml` exists. Refuses to dispatch on any failed gate; routes red checks to workflow-health triage. Never calls `gh release edit --draft=false` directly. Invoke when the user asks to "publish the release", "trigger release publish", "ship the release", or equivalent German-language requests. Typically called by sprint-review's opt-in chain, not directly after sprint closure.
requirements-elicit
Runs the requirements-elicitation interview methodology from spec/project/requirements-elicitation/ to capture a user's requirements precisely, assuming the user often does not know exactly what they want, expresses it imperfectly, or is misread. Drives a one-question-at-a-time funnel interview, maintains a per-dimension confidence score plus a gap matrix, asks confidence-gated clarifying questions only where understanding is weak, and writes an authoritative artifact to project/requirements/<slug>.md. Invoke when the user says things like "elicit the requirements for X" or "I want to build something but I'm not sure what exactly", or equivalent German-language requests. Also triggers as the upstream gate of roadmap-plan, feature-decompose, and issue-orchestrate when a requirement artifact is missing or below threshold. Don't use to decompose an existing requirement set (use feature-decompose) or author the downstream spec (use spec). Supports resume per `spec/claude/resumable-work/`.
roadmap-init
Scaffolds the project planning pair `project/goals.md` and `project/roadmap.md` for the first time, per `spec/project/roadmap/`. Invoke when the user asks to "set up the roadmap", "initialise project goals", "create goals.md and roadmap.md", "bootstrap the roadmap", or any equivalent fresh-bootstrap request. Also handles equivalent German-language requests. Verifies the audience artefact exists (and dispatches `audience-identify` when it doesn't), drafts the Vision plus numbered Outcomes in `project/goals.md`, drafts an empty queue plus optional phase headings in `project/roadmap.md`, presents both files for explicit approval, then writes them. Do NOT use to add roadmap items, retarget sprints, or flip MVP flags — that is `roadmap-plan`. Do NOT use to enforce the detail-level invariant — that is `roadmap-refine`. Supports resume on re-invocation per `spec/claude/resumable-work/`.
roadmap-plan
Adds, retargets, and reshapes roadmap items in `project/roadmap.md` per `spec/project/roadmap/` and `spec/project/mission/`. Invoke when the user asks to "add a roadmap item", "queue work for sprint N", "promote roadmap item to fine", "retarget R-3 to sprint 9", "flip MVP on this item", or equivalent German-language requests. Validates outcome IDs against `goals.md`, validates `target_sprint` against `project/sprints/`, enforces the lifecycle transitions declared in the roadmap and mission specs (including the asymmetric MVP-flag rule: `false→true` allowed before stabilisation, `true→false` forbidden after the item entered `status: active`), and refuses partial writes that would leave inconsistencies. Don't use to scaffold the roadmap from scratch (use `roadmap-init`) or to enforce the detail-level invariant (use `roadmap-refine`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
roadmap-refine
Enforces the detail-level invariant on `project/roadmap.md` per `spec/project/roadmap/` §Detail-level convention. Invoke when the user asks to "refine the roadmap", "check roadmap detail levels", "is the roadmap ready for the next sprint", "promote roadmap items to fine", or equivalent German-language requests. Resolves the current and next sprint by reading `project/sprints/`, walks every roadmap item, emits a structured violation record on stderr for every item with `target_sprint` equal to the current or next sprint and `detail` other than `fine`, exits non-zero when any violation is open, and walks per-item fix proposals one at a time. Don't use to add items, retarget sprints, or flip MVP flags (use `roadmap-plan`); don't use to scaffold the roadmap from scratch (use `roadmap-init`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
skill-agent-catalog-apply
Wires up the MkDocs skill-and-agent catalog in the current repository per the canonical-language file under spec/claude/skill-agent-catalog/. Audits the MkDocs config against the spec, scaffolds or patches the catalog generator surface (the `on_pre_build` hook by default, or a standalone pre-build step; gen-files is forbidden under mkdocs-static-i18n folder mode) plus literate-nav, writes the generator module that walks every configured plugin source root, and verifies a docs build produces Skills and Agents sections. Invoke when the user asks to "apply the skill-agent-catalog spec", "wire up the catalog generator", "scaffold the skills/agents navigation", or "add another plugin source root". Also handles equivalent German-language requests and checking whether a wired catalog is still in sync. Don't use for authoring individual skills/agents (use `skill-management`) or for general docs scaffolding (use `project-structure-apply`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
skill-review
Reviews a Claude Code skill against spec/claude/skill-management/ and spec/claude/skill-vs-agent/, and emit an actionable review plan per spec/claude/review-plan/ under .audits/skill-review/ keyed by the target skill's name. Invoke when the user asks "review this skill", "audit a specific skill folder", "check whether this skill is spec-compliant", or "skill review for a specific skill". Also handles closing an existing review plan once every item is addressed — "close the skill review plan for a specific skill". Also handles equivalent German-language requests. Do NOT use for agent review (use `agent-review`) or for pull-request-level review (`review` skill). Supports resume on re-invocation per `spec/claude/resumable-work/`.
skills-agents-sweep
Orchestrates a portfolio-wide audit of all skills and agents in the plugin inventory, producing a consolidated sweep report under .audits/skills-agents-sweep/ with cross-cutting findings (boundary conflicts, spec-induced gaps, operations-vocabulary drift, classification errors) and a wave-based implementation roadmap. Invoke when the user asks to "run a portfolio-wide skills and agents sweep audit", "check cross-cutting drift between skills and agents", "consolidate per-artefact reviews into a single sweep report", or "plan a wave-based implementation roadmap for sweep findings". Also handles equivalent German-language requests. Do NOT use for per-artefact reviews (use skill-review or agent-review for those); do NOT use for spec-versus-implementation reconciliation (use spec-drift-audit). Supports resume on re-invocation per `spec/claude/resumable-work/`.
spec-drift-audit
Audits every spec under spec/<topic>/<slug>/ against the repository implementation (source code, config, workflows, docs) and produces a traceable audit artifact per spec/project/spec-drift-audit/. Invoke when the user asks to "run the quarterly spec-drift audit", "check spec versus implementation", "spec drift reconciliation", "audit all specs against the repo", "find spec vs code drift", "open the next quarterly audit", or when a spec changes and requires a matching partial audit. Also handles equivalent German-language requests. Do NOT use for continuous CI health checks (use workflow-health-triage), single-spec readiness review (use spec-readiness-reviewer agent), or feature-level code drift on new features (use feature-consistency-reviewer agent within feature-decompose scope). Supports resume on re-invocation per `spec/claude/resumable-work/`.
maturity-assess
Assesses the build maturity of an application's capabilities per spec/project/capability-maturity-assessment/, writing project/maturity/<slug>.md to surface where implementation quality is lacking. The `assess` operation inventories business-facing capabilities top-down (never bottom-up from directories), maps each to an audience-identification audience, dispatches the read-only capability-maturity-scanner, then grades each on three axes — completeness, code quality, test coverage — into Bronze/Silver/Gold with a weakest-link overall tier and improvement lever; `reassess` re-grades as a diff. Consumes AUDIENCES.md under a soft gate (warns, never blocks). Grading only — never a merge gate, prioritisation, or dashboard. Invoke to assess capability maturity, grade an app's functions, or produce the maturity matrix; also German. Don't use for the binary PR gate (quality-gate), to define audiences (audience-identify), or KPIs (kpi-derive). Supports resume per spec/claude/resumable-work/.
source-code-review
Runs a holistic senior-engineer source-code review of production and test code against spec/project/source-code-review/ plus its frontend extension spec/frontend/source-code-review/, and persists a severity-classified report whose disjoint work packages are parallel-dispatchable to specialists. The default `review` operation detects each language and surface and dispatches the matching read-only reviewer agent (`python-code-reviewer`, `frontend-code-reviewer`; anything unprofiled is reported unsupported), then persists the report under .audits/source-code-review/. The `plan` operation hands that report to implementation-plan-author. Invoke to review a codebase like an experienced developer, find domain-knowledge duplication, or find business logic leaking into the client; also German. Don't use for the deep OWASP audit (code-security-reviewer), UX judgment (frontend-usability-optimizer), single-tier test conformance (tier reviewers), or to run lint and tests (quality-gate). Supports resume.
api-documentation-audit
Audits a repository's OpenAPI documentation against spec/project/api-documentation/ and produces a severity-classified audit artifact. Dispatches the read-only api-documentation-scanner agent to discover every OpenAPI document (checked in at a conventional location or exportable via a documented command), then classifies findings on the Critical/Warning/Suggestion/Info ladder — presence and 3.x version floor, info completeness, per-operation contract (operationId, tags, summary, parameters, request bodies), response and schema hygiene, security documentation, and the lint/drift wiring. An HTTP-API repo with no discoverable document is the report's most severe finding; the audit continues, never aborts. Invoke to audit API documentation, check an OpenAPI document for completeness, or run an API-docs gate; also German. Don't use for error-response conformance (api-error-check) or general code review (source-code-review). Supports resume.
error-tracking-audit
Audits an app's error-tracking wiring against spec/project/error-tracking/ and produces a severity-classified audit artifact plus a plan for the gaps. The default `audit` operation dispatches the read-only error-tracking-audit-scanner agent, then hard-fails on any static tool-contract violation (SDK init at process entry with global handlers, DSN from deployment config, environment and release tagging, explicit sampling, default-PII off plus a wired scrubbing hook, no log-sink misuse) and on a divergent stage vocabulary; tracker-side behaviour is verify-at-runtime. The `plan` operation dispatches implementation-plan-author so a specialist (fullstack-developer) wires the fix — there is no mechanical apply. Invoke to audit error tracking or check Sentry-protocol SDK wiring; also German. Don't use for the telemetry pillars (observability-audit), the PII/GDPR verdict (gdpr-data-protection-reviewer), or red CI runs (workflow-health-triage). Supports resume.
deployment-chart-manage
Provisions and maintains a Helm application chart on the bjw-s `common` library, applying spec/project/bjw-s-common-chart-deployment/ and spec/project/kubernetes-deployment-best-practices/. Two operations: `provision` generates a complete best-practice chart greenfield; `reconcile` is the change-noticing process that detects what an application change (for example from `fullstack-developer`) requires the chart to gain, presents the gaps, and on approval extends the chart and re-audits. Dispatches `deployment-change-analyzer`, `bjw-common-deployment-generator`, and `deployment-bestpractices-reviewer`, and owns the chart files plus the README manual-steps section. Invoke to provision a deployment chart or reconcile one after the app changed; also German requests. Don't use to write application code (`fullstack-developer`) or run the CI quality gate (`quality-gate`). Supports resume per `spec/claude/resumable-work/`.
test-cycle-orchestrate
Drives one or more turns of the iterative test cycle defined in spec/project/test-cycle-foundation/ — case determination → execution → result analysis → code adaptation → re-execute — dispatching each phase to its capability (test-case-extractor and the per-tier test-generators for cases, quality-gate for execution, test-result-analyzer for analysis, test-code-adapter for the fix) and looping until an explicit exit condition holds. Enforces the cycle's integrity rules: a regression case before fixing a defect, a flake quarantined not retried-until-green, and the no-cheating invariant (never weaken/skip a test to force a pass). Invoke when the user asks to run the test cycle for a feature, drive a feature to green, or iterate determine-execute-analyse-fix. Don't use to run the gate once (use quality-gate), to scaffold tests without the loop (use a tier generator), or to classify results without acting (use test-result-analyzer). Supports resume per `spec/claude/resumable-work/`.
feature-decompose
Decomposes a roadmap item into feature files under project/features/ per spec/project/feature/. Invoke when the user asks to decompose a roadmap item, break down a roadmap entry into features, draft features, scaffold a feature file, plan features for the next sprint, or write a new feature. Also handles equivalent German-language requests. Walks the operator through title, description, 3-7 testable acceptance criteria, and test hooks per feature; identifies which carries `verifies_sprint_value`; dispatches `feature-consistency-reviewer` (or records a manual fallback) before allowing the feature to leave `draft`. Don't use to transition feature status (`ready → in_progress` / `in_progress → done` is `sprint-execute` / `sprint-review`) or to author roadmap items, sprints, or the mission file. Supports resume on re-invocation per `spec/claude/resumable-work/`.
issue-orchestrate
Orchestrates a raw GitHub issue to an open, audit-trailed pull request per `spec/project/issue-orchestration/`. Comprehends the issue (body, comments, labels, linked items, repo surface), classifies it (`bug / feature-request / spec-change / security / docs / refactor / question / infra`), decomposes it into atomic specialist-ready work packages persisted as a pre-analysis artifact, routes large issues into the formal roadmap→feature→sprint pipeline, dispatches each package to the most specialised available skill or agent resolved by runtime lookup, and verifies via `quality-gate` and the standard PR flow. Invoke when the user asks to "analyse this issue", "orchestrate issue #N", "take this issue end-to-end", or equivalent German requests. Don't use to merge the PR (use `pull-request-merge`), to triage a red CI run (use `workflow-health-triage`), or to decompose an existing roadmap item (use `feature-decompose`). Supports resume per `spec/claude/resumable-work/`.
lektorat-apply
Reviews existing Markdown prose against six editorial dimensions (readability, comprehensibility, grammar, style, audience-fit, idiomatic naturalness) defined in `spec/project/lektorat/`. Three operations — `audit` (read-only report), `patch` (one finding, one diff, one approval), `revise` (full-artefact rewrite with diff review); dispatches `lektorat-scanner` for the detection phase. Invoke when the user asks to "lektoriere README.md", "audit docs for audience-fit", "revise this page with Lektorat", "prüfe auf Lesbarkeit", or equivalent EN/DE requests. Writes outputs to `.audits/lektorat/<YYYY-MM-DD-HHMM>/`. Don't use to author new prose (use `audience-doc-author`), curate Vale rules (use `prose-vale-curator`), lektor `spec/` files (out of scope), or edit code, configs, or LLM-instruction artefacts (SKILL.md, agents/*.md). Supports resume on re-invocation per `spec/claude/resumable-work/`.
pull-request-create
Creates a GitHub pull request that conforms to the repository's pull-request-workflow spec. Invoke when the user asks to open a PR, create a pull request, draft a PR description, create a merge request, or push the branch and open a PR. Also handles equivalent German-language requests. Don't use to merge or land an already-open PR (that's `pull-request-merge`). Verifies the feature branch is synchronized with develop, composes a Conventional-Commits title and the five-section body (Summary, Changes, Linked issues, Testing, Risk / rollout notes), autolinks any touched spec files under spec/, confirms with the user, and runs the GitHub CLI PR creation command. Supports resume on re-invocation per `spec/claude/resumable-work/`.
bdd-scenario-generate
Generates executable BDD scenarios from an abstract test-case document (TC-IDs plus behaviors) per spec/project/behavior-driven-development/, emitting English Gherkin `.feature` files and thin `pytest-bdd` step-definition skeletons that honor the page-object decoupling contract of spec/project/bdd-page-object-integration/ (thin steps delegate down, assertions only in the `Then` binding). Groups cases into Features, one Scenario per TC-level behavior, precondition/action/result mapped to Given/When/Then, `@TC-<id>` tags for traceability. Runs an advisory `lektorat-apply` audit over the scenario wording and emits a work-package list for any page-object or app change instead of touching it. Invoke to turn a test-case document into runnable BDD/Gherkin scenarios; also German. Don't derive the cases (test-case-extractor), scaffold a full E2E suite (e2e-test-generator), or audit the scenarios (bdd-scenario-reviewer). Supports resume.
cicd-pipeline-design
Designs, scaffolds, and audits a repository's CI/CD pipeline against spec/project/continuous-integration/ (pre-merge stage sequence, reproducible inputs, cache discipline, local↔CI parity), spec/project/continuous-delivery/ (artifact immutability, provenance, the artifact-to-securing-stage matrix, rollback, the handover boundary to deployment), and spec/project/github-actions-best-practices/ (digest pinning, least-privilege permissions, untrusted input, short-lived credentials, reusable-workflow reuse, concurrency, caching). Writes and patches workflow files in the target repository. Invoke when the user asks to design, set up, rework, harden, or audit a CI/CD pipeline or GitHub Actions workflows; also German. Don't use to triage a red run (`workflow-health-triage`), run the gate (`quality-gate`), or publish a release (`release-publish-trigger`). Supports resume on re-invocation per `spec/claude/resumable-work/`.
ha-automation-author
Authors one Home Assistant automation-logic or command artifact as spec-conformant YAML (or a sandboxed .py) from a described intent — an automation, script, scene, generic template entity, or a rest_command / shell_command / python_script — conforming to the matching spec/ha-automation/<topic>. Picks the artifact type, enforces a deliberate mode, stable id/unique_id, unavailable-guarded templates, shell-injection and python-sandbox safety, redirects legacy trigger helpers to modern equivalents, validates offline, and returns a conformance report. Activate on "write an automation that…", "create a script for…", "add a scene/template sensor/rest_command for…", "schreibe eine Automation, die…", "erstelle ein Script für…". Do not activate for blueprints (ha-blueprint-scaffold), stateful helpers (ha-helper-scaffold), derived/statistical sensors (ha-derived-sensor-author), Python custom integrations (ha-integration-scaffold), or deploying to a live HA instance.
ha-automation-solution
Plans and orchestrates a complete Home Assistant YAML solution from a result-oriented requirement, so the user never has to pick which authoring skill to use. Decomposes the requirement into the minimal combination of artifacts across the ha-automation skill family, presents a dependency-ordered artifact plan for approval, then dispatches ha-automation-author, ha-helper-scaffold, ha-derived-sensor-author, and ha-blueprint-scaffold in order — threading entity_ids between steps — and flags requirements that actually need a custom integration. Activate on "I want my heat pump's daily energy on the dashboard and an alert when it's high", "set up presence-based lighting that only runs in the evening", "baue mir eine Lösung, die…", "richte… ein". Do not activate for a single clear artifact (let the owning skill handle it), Python custom integrations (ha-integration-scaffold), or deploying to a live HA instance. Supports resume on re-invocation.
ha-backup-platform-add
Augments an existing Home Assistant Custom Integration with one backup-platform surface — pre/post backup hooks or a backup agent — conforming to spec/ha/backup-platform. For hooks it generates backup.py with async_pre_backup/async_post_backup that symmetrically pause and resume stateful operations around a backup; for an agent it generates the agent listing and listener wiring plus a BackupAgent subclass implementing the full upload/download/list/get/delete contract with the mandated error handling; exact signatures live in the body and spec. Disambiguates hooks-vs-agent by integration type before generating. Activate on "add backup hooks", "make my integration backup-aware", "provide a backup agent", or equivalent German requests. Do not activate for greenfield scaffolding (ha-integration-scaffold), the sibling diagnostics module (ha-diagnostics-augment), encryption/retention/restore orchestration (owned by the backup manager), or deploying to a live HA instance.
ha-badge-add
Adds a custom Lovelace badge to an existing Home Assistant frontend module, conforming to spec/ha/lovelace-badges. Generates the badge custom element (an HTMLElement or LitElement subclass with setConfig, the hass property setter, and render), the customElements.define call (the tag name becomes custom:<badge-type>), optionally getConfigElement / getStubConfig for the graphical editor, and the window.customBadges registration entry (type, name, description) so the badge appears in the dashboard badge picker. Documents dashboard referencing via type "custom:<badge-type>" and the module resource. Activate on "add a custom badge", "create a Lovelace badge", "register a custom badge", "füge ein Custom-Badge hinzu", "erstelle ein Lovelace-Badge". Do not activate for a custom card (ha-lovelace-card-scaffold), a tile card feature (ha/lovelace-card-features), a dashboard strategy (ha/lovelace-strategies), or deploying to a live HA instance.
ha-blueprint-scaffold
Scaffolds a single Home Assistant blueprint (automation, script, or template domain) as a self-contained, spec-conformant YAML file — by gathering the intent, running a pre-flight, and dispatching the ha-blueprint-author agent for the draft-validate-iterate loop, then relaying its conformance report. Activate on phrasings like "scaffold a blueprint for X", "create an automation blueprint", "turn this automation into a blueprint", "draft a motion-light blueprint", "schreibe ein Blueprint für X", "erstelle ein Automations-Blueprint", "mach aus dieser Automation ein Blueprint". Do not activate for custom-integration scaffolding (ha-integration-scaffold), Lovelace cards (ha-lovelace-card-scaffold), integration services (ha-service-definition-add), or importing/deploying into a running HA instance.
ha-bluetooth-augment
Augments an existing Home Assistant Custom Integration with Bluetooth support, conforming to spec/ha/bluetooth. Sets the manifest bluetooth matcher list plus the bluetooth_adapters dependency, subscribes to advertisements via bluetooth.async_register_callback with an explicit scanning mode bound through entry.async_on_unload, picks the right Bluetooth coordinator family (passive/active processor or DataUpdate variants), and wires device/service-info lookups over the shared scanner. Keeps passive (connectable=False) as the default. Part of the Gold discovery family, sibling of ha-discovery-augment. Activate on "add bluetooth discovery/support", "listen for BLE advertisements", or equivalent German requests. Do not activate for DHCP/SSDP/USB/HomeKit/Zeroconf discovery (ha-discovery-augment), the config-flow discovery step (ha-config-flow-augment), the generic polling coordinator (ha/coordinator-patterns), greenfield scaffolding (ha-integration-scaffold), or deploying to a live HA instance.
ha-card-editor-add
Adds an ha-form-based visual configuration editor to an existing custom Home Assistant Lovelace card, conforming to spec/ha/lovelace-card-editor. Generates the editor custom element (a LitElement implementing setConfig + a hass setter + a render() over <ha-form> with a schema, .data, and computeLabel, plus a _valueChanged handler that dispatches config-changed with bubbles/composed and detail.config), the card's static getConfigElement() returning that element, static getStubConfig() for a default config without the type parameter, and the customElements.define registration. Activate on "add a config editor to my card", "wire up the ha-form editor", "make my card configurable in the UI", "füge meiner Card einen Editor hinzu". Do not activate for scaffolding the card itself (ha-lovelace-card-scaffold), base card-level patterns (ha/lovelace-card-patterns), entity-selector filtering (ha/lovelace-card-entity-selector), or deploying to a live HA instance.
ha-card-features-add
Augments an existing Home Assistant frontend module with one custom tile/card feature — the interactive control row rendered inside the tile card and other host cards — conforming to spec/ha/lovelace-card-features. Creates the feature custom element implementing the card-feature contract (setConfig with an invalid-config reject path, the hass setter, a shared isSupported predicate resolving stateObj from context.entity_id, the render() of the control row calling hass.callService), optional static getStubConfig/getConfigElement, and registration via window.customCardFeatures.push plus customElements.define. Activate on "add a tile feature", "create a custom card feature", "add a control row to the tile card", or equivalent German requests. Do not activate for a full card (ha-lovelace-card-scaffold), a card config editor (ha-card-editor-add), badges (ha-badge-add), or deploying to a live HA instance.
ha-card-preview-add
Ensures an existing custom Lovelace card's preview is completely and correctly implemented, conforming to spec/ha/lovelace-card-preview — the card-picker gallery preview (preview flag plus a getStubConfig rendering a real non-error tile), the editor live preview (deterministic from setConfig/hass, re-rendered on config-changed), reading the preview element property (and legacy editMode), and preview correctness (no real service calls while previewing, a graceful placeholder over a thrown render). Completes the missing preview pieces on an existing card and validates them; produces a CONFORMANT / NEEDS-WORK report. Activate on "make my card show a preview in the card picker", "the card preview is broken / empty", or equivalent German requests. Do not activate for scaffolding a new card (ha-lovelace-card-scaffold), the config editor itself (ha-card-editor-add), card layout/sizing (ha/lovelace-layout-antipatterns), or deploying to a live HA instance.
ha-card-sizing-determine
Determines the optimal size declaration for an existing custom Lovelace card or panel — getGridOptions() (sections) and getCardSize() (masonry/panel/stacks) — so it renders correctly across devices in view and edit mode, then hands the result to an implementation step patching both callbacks. Classifies as content-dependent (rows:"auto" + min_columns) or deterministic (numeric rows + min_rows:rows), verifies the rows:"auto" CSS preconditions, and treats edit-mode overlay overlap as a sizing defect, per spec/ha/card-panel-sizing. Activate on "size this card correctly", "fix the edit-mode overlay overlap", "determine getGridOptions/getCardSize", or equivalent German requests. Do not activate for scaffolding a new card (ha-lovelace-card-scaffold), a full frontend solution (ha-lovelace-solution), panels/UX (ha-panel-add/-author/-ux-audit), feature rows (ha-card-features-add), or live-instance deploy/verify (ha-integration-deployer/-verify).
ha-config-entry-migrate
Adds or extend async_migrate_entry in an existing Home Assistant Custom Integration to migrate stored config entries across a schema change — bump ConfigFlow.VERSION (breaking) or MINOR_VERSION (backward-compatible), transform entry.data / entry.options (rename, move, default, split keys) via hass.config_entries.async_update_entry, reject a newer-than-current entry by returning False, and add a migration test. Non-destructive to unrelated keys; never drops data silently. Activate on phrasings like "migrate the config entry to the new schema", "I renamed a config key and need a migration", "bump the config entry version", "migriere den Config-Entry auf das neue Schema", "füge eine async_migrate_entry hinzu". Do not activate for greenfield scaffolding (ha-integration-scaffold), setup-time config-flow patterns (ha-config-flow-augment), adding a new option (ha-options-flow-augment), or deploying to a live HA instance.
ha-config-flow-augment
Augments an existing Home Assistant Custom Integration config flow with an additional pattern — multi-step tenant / account selection, zeroconf discovery, reauth flow, reconfigure flow, or OAuth as alternative to API key — non-destructively. Activate on phrasings like "add a multi-step tenant selection to the config flow", "add zeroconf discovery to the existing config flow", "add a reauth flow", "add reconfigure flow", "add OAuth login as alternative to API key", "erweitere den Config-Flow um Tenant-Auswahl". Do not activate for greenfield scaffolding (use ha-integration-scaffold), pure schema edits, or destructive refactors.
ha-conversation-agent-augment
Augments an existing Home Assistant Custom Integration with one or more Voice & AI surfaces — intent handlers, a conversation agent, and/or LLM API tools — conforming to spec/ha/intents-conversation plus spec/ha/llm-api. Decides with the user which surfaces are in scope, then generates the registered intent handlers, the conversation platform entity, and/or the LLM tools and API registration, implementing domain-appropriate built-in intents, avoiding deprecated ones, and signalling tool errors as HomeAssistantError; the full class-and-signature contracts live in the skill body and specs. Activate on "add a conversation agent", "register intents", "expose tools to the assistant via the LLM API", or equivalent German requests. Do not activate for assist_satellite/stt/tts/wake_word entities (ha/entity-platforms-voice), registered services (ha-service-definition-add), greenfield scaffolding (ha-integration-scaffold), or deploying to a live HA instance.
ha-coordinator-add
Appends a new DataUpdateCoordinator to an existing Home Assistant Custom Integration — separate role, separate update interval, full integration with RuntimeData mapping, options-flow entry, translations, and tests. Activate on phrasings like "add a new coordinator for alerts", "split the existing coordinator", "add a faster polling coordinator", "füge einen Coordinator für X hinzu". Do not activate for greenfield scaffolding (use ha-integration-scaffold) or coordinator removal; a push-style coordinator variant (async_set_updated_data) is supported for local_push / cloud_push integrations.
ha-derived-sensor-author
Authors one Home Assistant derived or statistical helper sensor as a spec-conformant YAML block from a described intent — bayesian, derivative, filter, min_max, statistics, threshold, trend, history_stats, integration, utility_meter, or group — conforming to the matching spec/ha-automation/<topic>. Picks the right integration, sets the math-bearing parameter (observations/prob_given_*, unit_time, window_size, state_characteristic, lower/upper/hysteresis, min_gradient, method, cycle), types the produced sensor and guards source unavailability, and reports runtime dependencies (recorder retention, integration→utility_meter). Activate on "add a sensor for the rate of change / energy from power / moving average / threshold / trend of…", "make a utility_meter / statistics / bayesian sensor for…". Do not activate for the generic template integration (ha-automation-author), stateful helpers (ha-helper-scaffold), real integration sensors (ha-integration-scaffold), blueprints, or deploying to a live HA instance.
ha-dev-workflow-apply
Applies and validates the HA code-style / strict-typing / validation workflow (spec/ha/dev-workflow) against an existing HA Custom Integration — Ruff format, ordered imports, f-strings (logging excepted), file-header docstrings, full type annotations, a local mypy-strict profile as the platinum strict-typing bridge, hassfest validation, and voluptuous config validation for YAML-configurable platforms — then reports CONFORMANT / NEEDS-WORK against the spec's MUST rules keyed to a target tier (bronze floor to platinum). Activate on "apply the HA dev workflow", "make this integration strict-typing / platinum-ready", "run ruff + mypy strict + hassfest", or equivalent German requests. Do not activate for a read-only quality-scale tier check (ha-quality-scale-audit), a security audit (ha-security-audit), the pytest harness (ha-test-harness-augment), devcontainer / Kind setup (ha/dev-environment), or deploying to a live HA instance.
ha-device-automation-add
Augments an existing Home Assistant Custom Integration with one device-automation kind — a device trigger, condition, or action — conforming to spec/ha/device-automations. Creates the matching platform module (device_trigger.py / device_condition.py / device_action.py) with its async_get_* list (CONF_PLATFORM/CONF_DOMAIN/CONF_DEVICE_ID/CONF_TYPE fields), a module-constant *_SCHEMA the core applies (never manually), the attach/check/call function, optional capabilities, and the device_automation strings.json entries. Runs an entity-vs-device value check and flags HA's stance that no new device automations are accepted. Activate on "add a device trigger for…", "expose a remote button press as a device trigger", "füge eine Device-Action hinzu". Do not activate for entity automations (ha/entity-architecture), registered services (ha-service-definition-add), greenfield scaffolding (ha-integration-scaffold), or deploying to a live HA instance.
ha-device-registry-augment
Wires the device-registry hierarchy of an existing Home Assistant Custom Integration so entities group into proper devices — DeviceInfo with identifiers / manufacturer / model / name, a via_device hub-to-child parent link, runtime addition of newly discovered devices, and removal of stale devices via async_remove_config_entry_device. Optionally adds async_get_device_diagnostics. Targets the Gold devices, stale-devices, dynamic-devices rules. Non-destructive to existing entities. Activate on phrasings like "group these entities into a device", "add a hub device with child devices via_device", "remove stale devices when they disappear", "gruppiere die Entitäten zu einem Gerät", "füge ein Hub-Gerät mit Kindgeräten hinzu". Do not activate for creating entity platforms (ha-entity-platform-add), config-entry diagnostics (ha-diagnostics-augment), device trigger/condition/action automations (ha-device-automation-add), greenfield scaffolding (ha-integration-scaffold), or deploying to a live HA instance.
ha-diagnostics-augment
Enriches an existing Home Assistant Custom Integration's diagnostics beyond the scaffold baseline, conforming to spec/ha/diagnostics. Creates or edits diagnostics.py with async_get_config_entry_diagnostics (and optional async_get_device_diagnostics) returning structured dicts, and routes every secret/PII/credential/coordinate field through async_redact_data with an explicit module-constant TO_REDACT frozenset — never manual truncation or field deletion. Includes redacted coordinator snapshots and version strings in the dump. Pairs with the diagnostics quality-scale rule (Silver). Activate on "enrich diagnostics", "add device diagnostics", "make sure diagnostics redacts secrets", or equivalent German requests. Do not activate to audit redaction gaps across modules (ha-security-audit), to scaffold the bare diagnostics stub at greenfield (ha-integration-scaffold), to score the quality-scale rule (ha-quality-scale-audit), or to deploy to a live HA instance.
ha-discovery-augment
Augments an existing Home Assistant Custom Integration with one network or bus discovery mechanism beyond Zeroconf — DHCP, SSDP/uPnP, USB, HomeKit, or MQTT discovery — conforming to spec/ha/discovery-mechanisms. Sets the manifest matcher list, implements the typed async_step_<mechanism> in config_flow.py, forwards into a confirm step (never a direct async_create_entry), and wires the unique_id plus _abort_if_unique_id_configured(updates=...) host/IP update path (the Gold discovery-update-info rule). Narrows generic OUI/bridge-chip matchers. Activate on "add DHCP/SSDP/USB/HomeKit/MQTT discovery", "discover the device by MAC/vid:pid/model", "füge DHCP-Discovery hinzu". Do not activate for mDNS/Zeroconf (ha/zeroconf-discovery, scaffold), Bluetooth (ha/bluetooth), greenfield scaffolding (ha-integration-scaffold), generic config-flow auth steps (ha-config-flow-augment), or deploying to a live HA instance.
ha-entity-description-map
Generates EntityDescription tuple lists for an HA Custom Integration platform module from a datapoint table or API-schema JSON, plus matching strings.json and icons.json entries. Activate on phrasings like "add sensors from this datapoint list", "generate EntityDescriptions from this CSV", "add binary_sensors for the alert types", "erweitere die Sensor-Plattform um folgende Datapoints". Do not activate for greenfield scaffolding (use ha-integration-scaffold) or when the platform file does not yet exist.
ha-entity-platform-add
Scaffolds one active platform entity into an existing Home Assistant Custom Integration — a command-driven domain (climate, cover, light, fan, lock, media_player, and peers) whose entity exposes async command methods — conforming to spec/ha/entity-platform-types plus the matching ha/entity-platforms-* family spec. Creates the platform module with the entity subclass, its EntityDescription where the family uses one, the supported_features bitmask, the async command methods, and the async_setup_entry wiring. The operator names the target domain and confirms the family first. Activate on "add a climate/cover/light entity", "scaffold an active platform entity", or equivalent German requests. Do not activate for declarative read-type entities via EntityDescription tables (ha-entity-description-map), the coordinator itself (ha-coordinator-add), greenfield scaffolding (ha-integration-scaffold), device-automation triggers (ha-device-automation-add), or deploying to a live HA instance.
ha-esphome-binding-add
Wires one Home-Assistant-driven value or command into an ESPHome device per spec/ha/esphome-ha-driven-content — choosing the mechanism by the spec's rule (continuously mirrored value → state subscription, one-shot instruction → callable action, person-set value → writable template entity, something HA must learn → event or action back), then emitting the verified configuration for it, always defining what the device does before the first value arrives and while the API connection is down, and routing anything visible through the display's single redraw script. Activate on "show a Home Assistant value on my device", "let an automation tell the device to do X", or equivalent German requests. Do not activate for rendering (ha-esphome-display-author), the voice pipeline (ha-esphome-voice-satellite-add), a local sensor (ha-esphome-config-augment), or HA-side automations (ha-automation-solution).
ha-esphome-ci-scaffold
Scaffolds the CI that validates an ESPHome fleet per spec/ha/esphome-project-structure §Validation — a pull-request workflow running esphome config for every device file on every change rather than only the diff, because a package edit breaks devices nobody touched, plus a scheduled or pre-release job for the far slower esphome compile, the static checks alongside them, a pinned ESPHome version, and the environment-variable strategy that lets a validation run resolve credentials without a secret ever being real. Emits workflows following the inherited GitHub-Actions rules: digest-pinned actions, least-privilege permissions, concurrency groups, no untrusted input in a run block. Activate on "add CI for my ESPHome repo", "validate all device configs in CI", or equivalent German requests. Do not activate to lay out the repository (ha-esphome-fleet-scaffold), to fix a red run (workflow-health-triage), to author CI for a custom integration (ha-integration-ci-scaffold), or to compile and flash locally.
ha-esphome-config-augment
Augments an existing ESPHome device-config YAML with one addition — a sensor/actuator platform block, an I2C bus or multiplexer channel, a locally consumed external component, or a new shared-package binding — conforming to spec/ha/esphome-config-patterns. Reads the device file and its shared packages first, verifies the component schema against the official ESPHome docs, keeps naming substitution-derived and credentials resolved from environment variables, and never duplicates a block a shared package already provides. Activate on "add a sensor to my ESPHome device", "wire a BME280 into box-01", or equivalent German requests. Do not activate for a brand-new device file (ha-esphome-config-scaffold), for reshaping the shared package itself (ha-esphome-package-author), for a Home-Assistant-driven value (ha-esphome-binding-add), for authoring a custom component (out of scope), for HA-side automations or dashboards, or for compiling/flashing.
ha-esphome-config-scaffold
Scaffolds one complete ESPHome device-config YAML file — substitutions-driven naming, shared blocks via packages, environment-variable-referenced wifi with AP fallback, natively encrypted api with a per-device key, password-protected ota, logger, and the first sensor/actuator platform blocks — conforming to spec/ha/esphome-config-patterns. Gathers device name, board family, shared-concern set, and initial platforms, runs a pre-flight (collision, credential inventory, device-config root), writes the new <device-name>.yaml, and reports which environment variables the operator must set. Activate on "scaffold an ESPHome device config", "new ESPHome device YAML", or equivalent German requests. Do not activate for extending an existing device file (ha-esphome-config-augment), for the repository layout and shared packages (ha-esphome-fleet-scaffold), for an ESPHome custom component in C++/Python (out of scope), for an HA Custom Integration (ha-integration-scaffold), or for compiling/flashing.
ha-esphome-display-author
Authors the on-screen content of an ESPHome display device per spec/ha/esp32-s3-box-display — fixing the rendering path (display with pages and lambdas, or lvgl, never mixed), then emitting a page for every reachable state including the degraded ones, the single redraw script that update_interval: never requires, the layout-zone geometry, fonts with explicit size and bounded glyph sets, images with explicit type and resize in the form matching the config's min_version, id-carrying colours, and lambdas guarded against unavailable values and zero divisors. Records the measured truncation budget and the framebuffer and asset flash cost. Activate on "design the screen for my ESPHome device", "add a page to the box display", or equivalent German requests. Do not activate for the panel's hardware binding (ha-esphome-config-augment), for where the values come from (ha-esphome-binding-add), for the voice pipeline (ha-esphome-voice-satellite-add), or for a Divoom Pixoo display (ha-pixoo-solution).
ha-esphome-fleet-scaffold
Scaffolds the repository layout of an ESPHome fleet per spec/ha/esphome-project-structure — the config root with flat device files, a common/ package tree grouped by consumer, include/ for C++ lambda headers, archive/ for retired devices, a keyed asset tree, the base package plus a first board package that pulls it in, the environment-variable documentation every credential needs, and the .gitignore entries keeping tool state and secrets out of version control. Works greenfield and on an existing flat collection, where it proposes the layout as a migration plan before touching anything. Activate on "set up an ESPHome repository", "restructure my ESPHome configs", or equivalent German requests. Do not activate to write or extend one device file (ha-esphome-config-scaffold / ha-esphome-config-augment), to cut a single package (ha-esphome-package-author), to wire CI validation (ha-esphome-ci-scaffold), or to audit a layout (ha-esphome-fleet-reviewer).
ha-esphome-package-author
Authors or reshapes exactly one shared ESPHome package under common/ per spec/ha/esphome-project-structure — cutting a concern out of duplicated device blocks, giving it a substitution interface with a defaults fallback, adding the id keys devices need to override a component, resolving a one-device deviation through !extend / !remove instead of a near-duplicate package, promoting a repeated override into a defaulted parameter, and pinning or vendoring a remote package. Reads every consumer first and states the merge consequences before writing. Activate on "factor this into a package", "parameterise the board package", "two configs share this block", or equivalent German requests. Do not activate to lay out the repository (ha-esphome-fleet-scaffold), to add a block to one device (ha-esphome-config-augment), to create a device file (ha-esphome-config-scaffold), or to audit the architecture (ha-esphome-fleet-reviewer).
ha-esphome-solution
Plans and orchestrates a complete ESPHome device or fleet result from a requirement, so the user never has to pick which ESPHome skill produces what. Decomposes it into the minimal dependency-ordered set of artifacts across the ha-esphome-* family — repository layout and packages, the device file, sensors and buses, Home-Assistant-driven bindings, display content, the voice satellite, CI validation — presents that plan for approval, then dispatches the owning skills resolved from the live inventory at runtime, threading device identities, package parameters, and entity ids between steps. Generation only: it never compiles, flashes, or rolls out, and never runs the review itself — the read-only reviewer agents stay a separately triggered pass, so an artifact is never judged by its own author. Activate on "build me an ESPHome device for…", "set up my ESPHome fleet", or equivalent German requests. Do not activate for a single clear artifact (the owning skill). Supports resume.
ha-esphome-voice-satellite-add
Turns an ESPHome device into a Home Assistant voice satellite per spec/ha/esp32-s3-box and spec/ha/assist-pipeline — emitting the generation-correct audio binding (one I2S bus, the external audio_adc / audio_dac pair the board actually carries, the capture/playback rate asymmetry, the power-amplifier switch), microphone and speaker, voice_assistant bound to both, on-device wake word, a discoverable mute control, and explicit no-Wi-Fi and no-Home-Assistant handling. Reports the HA-side steps it cannot perform: a pipeline per language, engine choice against host capacity, the assist_satellite binding, minimal entity exposure, and the debugging order. Activate on "make this device a voice satellite", "add Assist to my ESPHome box", or equivalent German requests. Do not activate for screen content (ha-esphome-display-author), for Home-Assistant-driven values (ha-esphome-binding-add), or for custom sentences and intent scripts (ha-automation-solution).
ha-hacs-release
Makes an existing Home Assistant Custom Integration HACS-release-ready by scaffolding and verifying the HACS-specific distribution layer defined in spec/ha/hacs-release — a valid hacs.json (name, zip_release plus filename, homeassistant floor, hide_default_branch, render_readme), the manifest.json version aligned to the vMAJOR.MINOR.PATCH release-tag scheme, the ZIP-release CD obligation (build and attach the domain.zip asset), and the brands registration pointer. Operationalizes the HACS layer on top of the generic release flow (spec/project/release-automation) without redefining it. Activate on "make this integration HACS-release-ready", "add a hacs.json", "set up ZIP release for HACS", or equivalent German requests. Do not activate for the generic release publish flow itself (nolte-shared:release-publish-trigger), the CI validation workflow (ha-integration-ci-scaffold), the integration code (ha-integration-scaffold), or deploying to a live HA instance.
ha-helper-scaffold
Scaffolds one Home Assistant stateful helper entity as a spec-conformant YAML block from a described intent — input_boolean, input_button, input_datetime, input_number, input_select, input_text, counter, timer, or schedule — conforming to the matching spec/ha-automation/<topic>. Picks the right helper type, sets every mandatory field (min/max, options, has_date/has_time, duration, weekly windows, restore), redirects measured/derived values to a sensor, names per ha/naming-conventions, and reports the helper's state, trigger events, and mutating services. Activate on "add an input_number/input_select helper for…", "create a timer/counter/schedule for…", "lege einen Helfer für… an". Do not activate for automations/scripts/scenes (ha-automation-author), derived/statistical sensors (ha-derived-sensor-author), real integration sensors, blueprints (ha-blueprint-scaffold), or deploying to a live HA instance.
ha-integration-ci-scaffold
Scaffolds the Home-Assistant-specific CI validation for a Custom Integration repository — a GitHub Actions workflow running hassfest and the HACS validation action on push and pull_request, plus a pytest job using pytest-homeassistant-custom-component across a Python matrix. Complements the portfolio's generic lint/release CI rather than replacing it; adds only the HA-domain validators. Grounded in spec/ha/dev-workflow (hassfest) and spec/ha/hacs-release (HACS validation gate). Activate on "add hassfest and HACS validation to CI", "set up the integration CI workflow", "add a pytest matrix job for the integration", or equivalent German requests. Do not activate for the generic repo scaffold (nolte-shared:project-structure-apply), the release publish flow (spec/project/release-automation and ha-hacs-release), the Python code itself (ha-integration-scaffold), or deploying to a live HA instance.
ha-integration-events-add
Augments an existing Home Assistant Custom Integration with event firing and/or listening on the HA event bus, conforming to spec/ha/integration-events. For firing it generates hass.bus.async_fire("<domain>_event", event_data) with a domain-prefixed event type and a documented JSON-serializable data shape, placed in async_setup_entry (__init__.py) and never in entity logic. For listening it generates hass.bus.async_listen / async_listen_once, holds the returned unsubscribe callable, registers it via entry.async_on_unload (or tears it down in async_unload_entry), and decorates non-blocking listeners with @callback. Decides fire vs. listen vs. both with the user first and runs an event-vs-state check. Activate on "fire a custom event", "listen for an event", "feuere/lausche ein Integration-Event". Do not activate for registered services (ha-service-definition-add), device triggers off events (ha-device-automation-add), greenfield scaffolding (ha-integration-scaffold), or deploying to a live HA instance.
ha-integration-scaffold
Scaffolds a complete Home Assistant Custom Integration skeleton — manifest, lifecycle, config flow, coordinator, entity, platforms, translations, icons, diagnostics, plus pytest harness — in one go, conformant to every MUST pattern in spec/ha/*. Activate on phrasings like "scaffold a new HA Custom Integration", "create a Home Assistant integration", "neue HA-Integration scaffolden", "skeleton einer HA Custom Integration anlegen", "bootstrap a new HACS-compatible integration". Do not activate when the user only edits an existing integration, scaffolds a Lovelace card, scaffolds an ESPHome component, scaffolds a blueprint, or asks for a YAML-to-config-flow migration — those have their own skills.
ha-integration-solution
Plans and orchestrates a complete Home Assistant Python custom-integration backend from a result-oriented device/cloud/API requirement, driven by a chosen quality-scale target tier (Bronze–Platinum), so the user never picks individual skills. Decomposes the requirement into a minimal dependency-ordered plan for the target tier, presents it for approval, then dispatches the owning integration ha-* skills — resolved from the live skill inventory at runtime, never from a frozen list — threading the domain and entity_ids between steps, optionally closing with CI validation and HACS-release readiness. Activate on "build an integration for device/API X", "build a Gold-tier integration for my Acme thermostat cloud API", or equivalent German requests. Do not activate for a single clear augment (the owning skill), a YAML automation solution (ha-automation-solution), a Lovelace frontend (ha-lovelace-solution), or deploying to a live HA instance (ha-integration-deployer agent). Supports resume on re-invocation.
ha-lovelace-card-scaffold
Scaffolds a vanilla-JS Lovelace card under custom_components/<domain>/www/<card-name>.js with every mandatory lifecycle method, shadow DOM, entity-change detection, HA CSS custom properties, and auto-registration in __init__.py. Activate on phrasings like "scaffold a Lovelace card for the integration", "add a custom Lovelace card called `<name>`", "erstelle eine Custom-Card für `<Resource>`". Do not activate for greenfield setup (use ha-integration-scaffold), TypeScript / Lit cards, or card removal.
ha-lovelace-solution
Plans and orchestrates a complete Home Assistant Lovelace/frontend solution from a result-oriented requirement, so the user never picks individual frontend skills. Decomposes the requirement into the minimal combination of artifacts across the Lovelace skill family (cards, editors, features, badges, strategies, panels, WebSocket backends), presents a dependency-ordered artifact plan for approval, then dispatches the owning skills — resolved from the live inventory at runtime — threading the card tag, file path, module resource, and domain between steps, surfacing a WebSocket backend's Python-integration dependency in the plan. Activate on "build a custom card with an editor and a feature", "create a dashboard strategy plus a badge", "set up a custom panel with a WebSocket backend", or equivalent German requests. Do not activate for a single clear frontend artifact (the owning skill), the Python integration backend (ha-integration-solution), or deploying to a live HA instance. Supports resume on re-invocation.
ha-media-source-add
Augments an existing Home Assistant Custom Integration with a media source provider, conforming to spec/ha/media-source. Creates media_source.py with the top-level async_get_media_source factory, a MediaSource subclass bound to the domain, async_browse_media returning a BrowseMediaSource tree (root node on empty identifier, BrowseError on failure), and async_resolve_media returning PlayMedia (Unresolvable on failure); sets MediaClass plus correct can_play/can_expand per node, builds URIs via generate_media_source_id, and wires translatable exceptions. Discovery needs no manifest.json change. Activate on "add a media source", "let users browse my media in the media browser", or equivalent German requests. Do not activate for a media_player entity that consumes media sources (ha/entity-platforms-media), translation mechanics (ha-translation-sync), greenfield scaffolding (ha-integration-scaffold), or deploying to a live HA instance.
ha-oauth2-credentials-augment
Augments an existing Home Assistant Custom Integration with the OAuth2 / Application Credentials flow, conforming to spec/ha/application-credentials. Creates application_credentials.py with the authorization-server wiring, converts the config flow to an AbstractOAuth2FlowHandler subclass that creates the entry and sets unique_id, adds the application_credentials manifest dependency, runs token refresh through OAuth2Session, implements the reauth path, and adds the matching strings.json entries; exact signatures live in the body and spec. Activate on "add OAuth2 to my integration", "wire up application credentials", "set up the OAuth2 config flow", or equivalent German requests. Do not activate for generic user/password or API-key config flows (ha-config-flow-augment), greenfield scaffolding (ha-integration-scaffold), coordinator wiring (ha-coordinator-add), or deploying to a live HA instance.
ha-options-flow-augment
Augments an existing Home Assistant Custom Integration with one generic config option retrofitted into its OptionsFlow — a post-setup setting stored in entry.options (never entry.data), with a typed selector, strings + translations, an entry-reload-on-change wiring, and a test. Non-destructive — existing options stay untouched. Activate on "add an option for X to the integration", "let the user configure the poll behaviour / a threshold / a toggle after setup", "retrofit an options flow", "füge eine Option für X hinzu", "erweitere den Options-Flow". Do not activate for greenfield scaffolding (ha-integration-scaffold, which ships the base options flow), config-flow setup patterns like tenant/reauth/reconfigure/zeroconf/oauth (ha-config-flow-augment), the coordinator poll-interval option specifically (ha-coordinator-add owns it), config-entry data migration (ha-config-entry-migrate), or deploying to a live HA instance.
ha-panel-add
Augments an existing Home Assistant integration or frontend repo with one bare custom-panel scaffold — a full-page custom element registered in the sidebar, no data wiring beyond the scaffold — conforming to spec/ha/lovelace-views-panels (custom-panel part). Creates the panel custom element (Lit or another non-React framework receiving hass/narrow/route/panel), the JS-module wiring, and the panel_custom registration in configuration.yaml. Distinguishes a custom panel from a panel-mode view and a custom view. Activate on "add a custom panel", "register a sidebar panel", or equivalent German requests. Do not activate for a production-grade end-to-end panel (ha-panel-author, the consumer front door owning the delivery-shape decision), a single card (ha-lovelace-card-scaffold), a dashboard strategy (ha/lovelace-strategies), the WebSocket command a panel calls (ha-websocket-command-add), greenfield scaffolding (ha-integration-scaffold), or deploying to a live HA instance.
ha-panel-author
Develops a described full-page or dashboard-surface need end-to-end to production grade, conforming to the full relevant spec set. First decides the delivery shape (custom sidebar panel vs. panel-mode view vs. custom view as layout container) per spec/ha/lovelace-views-panels and spec/ha/lovelace-layout-antipatterns, then builds it — dispatching ha-panel-add for the base scaffold, wiring hass data access (spec/ha/frontend-data-api) and any WebSocket backend (via ha-websocket-command-add), and enforcing responsive layout, performance, shadow-DOM theming, and naming discipline. Activate on "build a proper custom panel for …", "develop a full-page HA panel that shows …", or equivalent German requests. Do not activate for the minimal one-panel scaffold only (ha-panel-add), a single card (ha-lovelace-card-scaffold), a multi-artifact frontend solution (ha-lovelace-solution), a dashboard strategy (ha-strategy-add), the Python backend (ha-integration-scaffold), or deploying to a live HA instance.
ha-panel-config-view-add
Adds or completes the configuration/options view of an existing Home Assistant custom panel, conforming to spec/ha/lovelace-panel-config-view — separating deploy-time panel.config from runtime-editable options, composing the options form from ha-form plus ha-selector selectors, persisting domain/shared state through a custom WebSocket command and per-user UI preferences through the frontend user-data store, and gating admin-only options in the UI while enforcing them server-side. Completes the missing config-view pieces on an existing panel and validates them, producing a CONFORMANT / NEEDS-WORK report. Activate on "add a settings view to my panel", "let users configure my panel", "persist my panel options", or equivalent German requests. Do not activate for scaffolding a new panel (ha-panel-add), defining the WebSocket command itself (ha-websocket-command-add), the card config editor (ha-card-editor-add), the backend integration options flow (ha-options-flow-augment), or deploying to a live HA instance.
ha-panel-ux-audit
Runs a read-only panel-level UX audit of an existing panel artifact (custom sidebar panel, panel-mode view, or custom view) — with mobile-device usability as a mandatory first-class dimension. Audits against spec/ha/lovelace-views-panels, spec/ha/lovelace-layout-antipatterns, spec/ha/lovelace-card-patterns, and spec/ha/frontend-data-api plus UX/accessibility heuristics, and produces a severity-sorted improvement report — mobile usability, responsive/narrow behaviour, touch targets, information hierarchy, readability, accessibility, perceived performance — that ha-panel-author can consume as a prioritized work-list. Never modifies code. Activate on "audit my panel's UX", "is this panel usable on mobile", "review the panel for usability and accessibility", or equivalent German requests. Do not activate for building or fixing a panel (ha-panel-author), scaffolding one (ha-panel-add), a whole-integration review (ha-integration-reviewer), or deploying to a live HA instance.
Showing top 100 of 114 skills by quality score. Browse the full catalog at /browse.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.