---
name: Increment PR Pipeline
triggers:
  - increment pipeline
  - one increment per pr
  - worktree per increment
  - pr per increment
  - board increment
  - build increment by increment
  - increment workflow
---

## Increment PR Pipeline — one atomic increment, one worktree, one PR, reviewed then merged

### What this is
The EXECUTION workflow for building a decomposed plan **increment by increment**, where every
increment is isolated in its own git worktree + branch and lands as a **real GitHub PR into the
feature branch** (e.g. the board branch), reviewed by a separate agent before the operator merges.
It complements:
- **Atomic Build Spec** — how to DECOMPOSE work into tiny, testable increments.
- **Phased Worker Pipeline** — the fresh-worker-per-step loop (this skill is its PR-based, worktree-
  isolated form).
- **Handoff** — how to spawn a worker and wait for its result.

Use this when the operator wants small PRs, isolated worktrees, and per-increment review — NOT one
big branch with everything hammered in at once.

### The invariants
- **One increment in flight at a time, strictly serial.** The next increment branches off the
  **updated** feature branch (after the previous PR merges). Do not parallelise dependent increments.
- **Own worktree + own branch per increment**, branched off the feature branch (NOT main).
- **Builder ≠ Reviewer.** A worker never reviews its own code; the reviewer is a fresh, separate
  agent — ideally a DIFFERENT agent type than the builder, for independent perspective.
- **A regression is never merged.** Blocking review findings are fixed by the SAME builder in the
  SAME PR before merge; cosmetic/non-blocking items become explicit fast-follows.
- **The operator does the final verify and merges the PR himself.** The orchestrator stays thin.

### The loop (orchestrator-driven), per increment
1. **Create the worktree + branch** off the feature branch:
   `git worktree add -b <feat>/inc<N>-<slug> C:/src/rcm-inc<N>-<slug> <feature-branch>`.
2. **Spawn the BUILDER worker** (agentType per the operator's choice for this run), cwd = the
   worktree. It MUST, as its FIRST action, load the **Clean Code** skill via `get_skill`. Give it:
   the increment goal, the smallest-honest-slice scope, exact file list, invariants, and what is
   explicitly OUT of scope (name later increments so it can't scope-creep).
3. Builder implements ONLY this increment + an automated test, then runs the FULL local gate and
   **STOPS and reports back** — it does not start the next increment.
4. **Spawn a separate REVIEWER worker** (a different agentType than the builder, for independence),
   read-only, adversarial / refute-mode, cwd = the same worktree (deps already installed). It loads
   Clean Code first, reviews
   the PR diff vs the feature branch, confirms the tests are REAL (not rubber-stamps) and the gate is
   green, and returns a clear **GO-to-merge** or **CHANGES-NEEDED** verdict with ranked findings.
5. **Blocking findings** → hand back to the SAME builder to fix in the same PR; then a focused DELTA
   re-review confirms the finding is CLOSED. Non-blockers → note as fast-follows.
6. **Operator verifies** (the builder supplies a ~30s click-checklist) and **merges** the PR.
7. **Cleanup**: `git worktree remove --force <path>` + `git worktree prune` + delete the local
   branch. Advance to the next increment off the updated feature branch.

### The gate — ALL must be green before a PR is "ready" (builder runs these IN the worktree)
- `npm ci` **first** — a fresh worktree has NO `node_modules`; typecheck/tests won't run without it.
  (Install can be slow on Windows; that's expected.)
- `npm run typecheck` — clean.
- `npm run format:check` — clean. **CI fails on format independently of tests**; running only tests
  is not enough. Auto-fix with `npm run format` / `npx prettier --write` and re-check.
- `npm test` — all pass, including the new test for this increment.

### The PR
- **Base = the feature branch (e.g. feature/agent-task-board), NOT main.**
- Title: `<feat>(inc<N>): <what it does>`.
- Body: plain and accurate — what the increment does, files touched, gate status. No filler, no
  AI/tool attribution.
- Commits use **explicit paths** — never `git add -A/./ -u`, never `commit -a`.

### Anti-patterns
- ❌ Skipping `npm ci` in a fresh worktree, then reporting "done" when the gate never actually ran.
- ❌ Running only `npm test` and missing the separate `format:check` → red CI on the PR.
- ❌ PR based on `main` instead of the feature branch.
- ❌ The building worker reviewing its own increment.
- ❌ Merging a PR with an unresolved regression instead of fixing it in the same PR.
- ❌ Leaving the merged increment's worktree/branch around instead of cleaning up before the next.