squid

Monitors CI/CD after `git push`. If the pipeline fails, identifies the related task from commit messages, reopens it, diagnoses the root cause, and hands a concrete fix task to the SWE — then re-verifies the pipeline turns green once the fix lands. Owns pipeline health; does not change application code itself. Use after any push performed by the SWE or by the orchestrator.

Reads the git diff after a feature is pushed. Tags every finding as Blocker or Nit. Produces ONE rollup task containing all findings. Does NOT read CI, does NOT comment on the PR, does NOT merge. Use after the SWE has pushed the feature branch and before the orchestrator hands the PR back to the human for squash-merge.

Grooms raw tasks into agent-ready specs (acceptance criteria + BDD scenarios) AND does final user-perspective acceptance review after the Tester passes. Use whenever a task needs to be turned into something the SWE can build, or whenever a task needs the final "is this actually right for users?" review before commit.

Implements a single groomed task assigned by the orchestrator. Writes code and tests locally. Does NOT commit until the Tester has reviewed and approved. Use when a task is groomed and ready for implementation, or when the Tester has returned feedback that needs to be addressed.

Reviews the software-engineer's uncommitted work against the spec and acceptance criteria. Runs the full test suite, verifies every acceptance criterion with evidence, and gives PASS or FAIL. Use after the SWE reports an implementation is done, or after the SWE applies fixes for previously-flagged issues.

Periodic architectural sweep of a codebase — reads existing ADRs to avoid re-litigating settled decisions, maps the current module/dependency graph and layering, surfaces 5–10 architectural smells with severity, and emits each finding as a refactor proposal that `/refactor` can consume directly. Trigger when the user says "/architecture-review", "audit the architecture", "what's wrong with this codebase", asks before a major version bump, or when long-horizon tech debt feels untracked.

Interview the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.

Run the full agent-team pipeline end-to-end for one feature whose Tasks Plan is already approved (by /plan). A thin orchestrator — runs INSIDE the feature worktree and invokes /implement-task (build + commit every task), then /review (push + PA acceptance + PR-Reviewer), then /review-ci (CI), then a human-gated self-improve, and hands the validated PR to the human to squash-merge. Trigger after /plan, or say "/implement-night".

Implement one task — or work through a whole list of tasks / an approved Tasks Plan — via the inner SWE↔Tester loop, committing each task once it passes. Autonomous: SWE implements, Tester runs the suite + e2e adversarial pass, retry up to 5×, commit on PASS, move to the next task. Use when you have one or more GROOMED tasks ready to build, or say "/implement-task". To plan a feature first use /plan; for the full end-to-end pipeline use /implement-night.

Turn a raw feature spec into an approved Tasks Plan — one markdown file per atomic task under `tasks/` (or one GitHub Issue per task) — plus an optional ADR, glossary additions, branch, and worktree. Grills the human to sharpen the spec, has the Product Architect groom it into draft tasks (reading docs/glossary, proposing an ADR, using context7), offers another grilling round and shows the final plan before any task is created, then runs ONE human gate that decides everything touching the repo — approve the tasks and where to store them (local files vs GitHub Issues), create the ADR, apply the glossary additions, new worktree vs current tree, and which build to run (/implement-night, an /implement-task loop, or stop). Trigger when the user wants to plan a feature before building, or says "/plan".