GitHub npm  v0.7.0

Multi-agent patterns,
ready to drop in.

Field-proven architectures for AI-agent development — each one a design write-up plus working scaffolding. Humans decide at two gates; the agents do the rest.

Adoption guide Operating manual
npx agent-templates@latest adopt three-agent-architect-builder-reviewer .

Already installed? Update to the latest catalog version: npx agent-templates@latest adopt three-agent-architect-builder-reviewer . --force (commit first — --force overwrites).

Every model/effort claim carries a source label and an expiry date

Role boundaries enforced by hooks, not prose

Nightly sweep triages and fixes issues while you sleep

1

pattern in the catalog

v0.7.0

on npm · MIT

E2E

gated merges — deterministic, zero-token tests

2

human gates: sign-off & smoke test

Patterns

Three-Agent Architect–Builder–Reviewer

trialed · as of 2026-07-22 (Architect model on trial; §7)

One ticket flows through three agents in sequence: Architect plans → Builder implements → Reviewer (fresh context, different model tier) clears or bounces. No agent judges its own work.

Architect·Claude Fable 5 @max Builder·Claude Opus 4.8 @xhigh Reviewer·Claude Fable 5 @xhigh Triage (nightly only)·Claude Sonnet 5 @xhigh
Commands
/breakdown-prd[focus notes, e.g. module-count hint or what to defer]Decompose docs/PRD.md into sub-PRDs + template-compliant tickets (three-agent pattern, pre-Gate-1 planning)
/build-ticket<ticket-id>Run the Builder stage on a planned ticket (three-agent pattern)
/nightly-issues[max-issues]Nightly issue sweep — triage open issues, auto-fix the fixable ones through the three-agent pipeline, post the morning report (designed for headless `claude -p "/nightly-issues"`)
/plan-ticket<ticket-id or path to ticket file>Run the Architect stage on a ticket (three-agent pattern)
/review-ticket<ticket-id> [branch-or-PR-ref]Run the Reviewer stage on a built ticket (three-agent pattern) — requires a fresh context
/start-all[supervised|autonomous] [concurrency]Whole-PRD Gate 1 — compute the module DAG, publish every module's tickets, run all modules through the pipeline in dependency order (three-agent pattern)
/start-milestone<module dir, e.g. docs/prd/01-foo> [supervised|autonomous] [concurrency]Gate 1 start signal — publish the module's tickets as tracker issues, then run the milestone pipeline (three-agent pattern)
/verify-delivery<ticket-id>Post-merge Definition-of-Done check for a ticket (three-agent pattern) — verifies delivery instead of assuming it
Pattern write-up Scaffold

From a bare PRD.md to shipped

1. Adopt

npx agent-templates@latest adopt three-agent-architect-builder-reviewer . — scaffold, templates, docs skeleton, CLAUDE.md, in one idempotent command.

2. Break down

/breakdown-prd — the Architect turns your PRD into sub-PRDs and cold-startable tickets, then stops.

3. Gate 1 — you decide

Review the breakdown, then /start-milestone: tickets become tracker issues and the pipeline starts.

4. Autonomous middle

Plan → build → fresh-context review (bounce-capped in code) → merge on CLEAR → issue closed → delivery verified.

5. Gate 2 — smoke test

Agents own unit/integration/E2E all along; you test once, when the PRD is done. A nightly sweep fixes issues while you sleep.

Parallel delivery — opt in with one number

concurrency — one number decides the shape. 1 (default) is the original sequential runner, one ticket at a time, unchanged. N (autonomous only) runs independent tickets — the ones the dependency DAG says don't block each other — as parallel lanes, scheduled by the deterministic workflow.
/start-milestone docs/prd/01-foundation autonomous 4   /start-all autonomous 4

Isolated worktrees

Each independent ticket runs in its own git worktree — builder and reviewer work there, so concurrent lanes never clash on the working tree.

Serialized merge

Delivery to the default branch never overlaps; a hidden file-scope overlap surfaces as a merge conflict → abort → escalate, so nothing lands broken.

DAG-bounded, opt-in

A failed ticket skips its dependents; real parallelism is bounded by the dependency graph and the runtime's agent cap. >1 multiplies token spend — opt in per run.