ab-method

Post-implementation documentation-sync detector. Spins up ONE read-only subagent on a completed task's diff to find everything the change introduced that the architecture docs don't yet know about — new endpoints, patterns, dependencies, domain terms, ADR-worthy decisions — routed to the exact doc each belongs in. Autonomous runs apply only append-only safe additions and defer domain/ADR reshapes; interactive runs present the proposed doc deltas to pick. Use after a task's missions are done (from create-task / start-task / start-roadmap) or standalone on a diff.

Cross-plan coherence critic for a whole roadmap. Reads roadmap.md plus every planned task's progress-tracker.md and pushes back ONLY on genuine discrepancies BETWEEN the finished plans — broken seams, coverage gaps, duplicated work, reversed/missing edges, terminology drift, conflicting assumptions. Read-only; silent when the plans cohere. Run standalone after planning finishes and before /start-roadmap.

Pre-implementation critic. Spins up a read-only domain critic that challenges a drafted plan — a task's missions or a roadmap's task graph — against the ubiquitous language, CONTEXT.md, and ADRs, and pushes back ONLY on genuine conflicts. Silent when the plan is sound. Use before implementing (from create-task / create-roadmap) or standalone to stress-test a plan against the project's domain model.

Post-implementation review. Spins up three read-only critics on a completed task's diff — cleaner-architecture, slop-defender, reusability-inspector — that push back ONLY on real issues. Autonomous runs apply safe fixes (tests-green-gated) and write everything to review.md next to progress-tracker.md; interactive runs present findings to pick. Use after a task's missions are done (from start-task / start-roadmap / create-task) or standalone on a diff.

Execute a roadmap autonomously to completion — the layer above start-task. Use when a roadmap's tasks are planned and you want them run in dependency order, with independent tasks optionally in parallel. Verifies the dependency tree is planned before running; stops if a needed task has no plan. Executor only.

Turn a larger idea into a dependency-ordered roadmap of tasks — the layer above create-task. Use when the work is several distinct tasks with real ordering between them (schema before API before UI), and you want the whole task graph drawn before implementing. Producer only; ab-start-roadmap executes it.

The intelligent entry point to the AB Method. Use when the user isn't sure which workflow they need, asks whether to create a goal or a task, or wants to understand how the AB Method works end to end. Routes intent to the right workflow instead of reimplementing it.

Run an existing task autonomously to completion — each remaining mission in a subagent with tdd, tracker updated per mission, a commit after every green mission. Use when the user wants to hand off a well-defined task and review commits instead of missions.

Resume a handoff (a side-topic spun off mid-grill) and turn it into a test-driven task. Use when the user wants to continue grilling on a deferred topic captured under docs/handoffs/.

Compact the current conversation (or a side-topic that surfaced mid-grill) into a handoff document another agent can pick up. Use when a tangent deserves its own task, or to summarize a session for a fresh agent.

Extend an existing goal — broaden or add to its objective, building on top of what the earlier /goal run already implemented. Use when the user wants to expand a goal after a /goal run.

Analyze and document a project's backend patterns — API design, data access, service structure. Use when the user wants a backend-only architecture analysis.

Analyze and document a project's frontend patterns — component structure, state management, conventions. Use when the user wants a frontend-only architecture analysis.

Analyze a project's architecture end to end — extract domain language, map the tech stack, document frontend and backend patterns. Use when onboarding a new codebase or refreshing the architecture baseline.

Produce a ready-to-run prompt for an autonomous /goal loop. Use when the user wants to hand off one continuous objective with a verifiable stop condition to run autonomously.

Create a focused task and break it into test-driven missions. Use when the user wants to start a new feature, fix a bug, or begin implementation work.

Append new missions to an existing task. Use when requirements changed or scope grew on a task already underway.

Continue an existing task from its progress tracker. Use when the user wants to resume, continue, or pick up earlier task work.

Add retroactive test coverage for code that was not written test-first. Use when the user wants to backfill tests.

Refresh architecture and domain documentation after impactful changes. Use when code has drifted from the documented architecture.

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.