code-qa

Review a change for over-engineering and bloat — speculative generality, gold-plating, dead code, needless indirection, premature optimization, wrong abstractions — and propose the simplest version that still meets the spec and passes the tests. Use before opening a PR, and when auditing an AI-generated diff that feels larger than the problem. The mirror of meaningful-test-coverage: that fights too little verification, this fights too much code.

Apply disciplined commit and pull-request hygiene before pushing — format with the repo's own tooling (and defeat stale formatter caches), write timeless code comments (no dev-path narration), keep commit messages conventional and trailer- clean, and draft any outward PR comment/review for human approval before posting. Use before every commit and before opening or commenting on a PR.

Manage a change that spans a primary code repo and a companion config/distro/data repo as paired pull requests — keeping them backward-compatible, cross-linked, and safe to merge independently. Use when a feature needs both a code change (new field/loader/behavior) AND a configuration/catalog/deployment change that lives in a separate repo, so neither PR is broken or confusing on its own.

Turn a Playwright (or similar) E2E run into a structured, shareable proof — screenshots + MP4 videos + a narrated report — and draft the PR-comment and Slack message to surface it. Use after recording a demo/E2E run (e.g. a `core-demo-video` Playwright project) when you need to show a reviewer or stakeholder what a feature does and that it works, without polluting the repo with binaries. Pairs the deterministic bundler script with an LLM-written narrative. Drafts only — the human posts.

Author thorough, no-theater tests across every layer a change touches — via a multi-agent workflow that designs the RIGHT-level test per layer, adversarially verifies each for test theater / over-mocking, then implements and runs the survivors. Use after a substantive multi-layer change (data/schema + query + service + frontend) when you want coverage that actually catches the bug, not green-theater. Enforces the inversion test and level-correctness (data/query → integration, pure logic → unit, rendering → component, story → E2E).

Verify that spec/design artifacts match the shipped code, catalog the drift, and remediate the lagging side — grounding every claim in the canonical source, not in what the spec says it should be. Use in spec-driven repos (SpecKit or similar) after implementation, before a PR or a review, when code and specs may have diverged. Read-only analysis first; remediate only the drift, only with approval.