yaah

Use when the user wants to drive a raw feature or bug prompt all the way to a reviewed, merge-ready PR/MR in one hands-off, autonomous run with only two human touchpoints (requirements grilling, final merge approval), or invokes /forge. Stack- and tracker-agnostic (GitHub or GitLab); reads per-repo settings from .yaah/config.yml (written by /setup-yaah); each run works in its own git worktree off the latest default branch, so many runs go in parallel without colliding; supports a parallel branch-per-issue build mode. The full phase chain and its mechanics live in the body and PLAYBOOK.md, not here.

One-time interactive setup for the yaah harness / forge pipeline. Detects the repo's stack, default branch, and issue tracker, offers to install the token-efficiency tools (graphify, rtk, caveman), asks the user to confirm or adjust, then writes .yaah/config.yml that forge reads. Use when the user first installs yaah, runs /setup-yaah, or when forge reports a missing config.

Use for forge's review — ONE reviewer that covers everything in a single read-only pass over a branch/PR/MR diff. Returns a spec-compliance verdict (missing/extra/misunderstood vs the requirements, plus correctness and security), a code-quality verdict, and a ⚠️ can't-verify-from-diff verdict. Runs in two depth modes: PER-ROUND (focused, cheap — every review round) and FINAL (adds a deep, ambitious maintainability audit — the once-per-run gate on the most-capable model).

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Use when creating new skills, editing existing skills, or verifying skills work before deployment

Use when encountering any bug, test failure, failing check, or unexpected behavior, BEFORE proposing fixes. A four-phase root-cause discipline (investigate → pattern → hypothesis → implement) that replaces guess-and-retry. Bundles root-cause-tracing, defense-in-depth, condition-based-waiting, and find-polluter.sh.

Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.

Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.

Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.