A router: it picks the size tier and the stage, then you load that stage skill. It holds no stage content itself. It owns three single-home files every stage points to:
references/size-tiers.md— how much pipeline a change gets (T0-T3)references/lanes.md— which model builds and which review (the only place model names live)references/coding-principles.md— how code gets written (think first, simplicity, surgical changes, goal-driven), the T0/T1 plan format, the unreachable-scenario definition, and the builder block every brief carries
The chain diagram lives in references/flow-map.md.
When to use
- User says "build X", "implement X", "add feature X" and doesn't name a phase
- User asks "how should we approach building X?" or "what's next?"
- You need to decide how much process a change deserves
Don't use when the user already named a phase ("write a spec for X", "review this diff") — load that stage skill directly.
Step 0 — pick the tier (always)
Read references/size-tiers.md, pick T0 / T1 / T2 / T3, and tell the user in
one line with the reason. At T0/T1, follow it with an assumptions line and a
step → verify: check plan (references/coding-principles.md § Plan format
for T0/T1). The tier decides which rows of the table below run,
how many reviewers look, and how many review rounds the loop may spend.
Tiers go up when the work turns out bigger or riskier; never silently down.
| Tier | Path (summary — table in size-tiers.md) |
|---|---|
| T0 Trivial | tier + assumptions line + step → verify plan → edit → test if behavior changed → commit. No stages. |
| T1 Small | assumptions line + short step → verify plan with inline acceptance criteria → test-evals → one implementer → review-commit (Step A + R1 + ≤ 1 confirm round, one reviewer) |
| T2 Standard | full chain + Goldfish offered after the approved plan; one reviewer per build task; two reviewer lanes; ≤ 2 confirm rounds; converge cap 2 |
| T3 High-stakes | full chain + grill + Goldfish offered after the approved plan; two-stage review per task; three reviewer lanes; ≤ 3 confirm rounds; converge cap 3 |
Any live deploy needs the three-reviewer gate, whatever the tier.
The stages
| Stage | Produces | Load when |
|---|---|---|
grill |
hardened plan — every decision branch settled with the user | plan is fuzzy (T2/T3; T1 only if the ask is ambiguous) |
spec — spec turn |
user stories, acceptance criteria, [NEEDS CLARIFICATION] markers, seam sketch + seam notes → .hermes/specs/ |
intent not pinned (T2/T3) |
spec — clarify |
markers resolved and folded back | markers remain after the spec turn |
spec — plan turn |
tasks with tracer-bullet slices, blocking edges, file paths, interfaces, the test cases each task must pass → .hermes/plans/ |
spec exists (or clear requirements), need the HOW |
spec — tickets turn (optional) |
tickets with blocking edges → .hermes/tickets/ |
want parallel work units |
test-evals |
the RED tests for the plan's test cases, each citing its seam note, run to failure | after the plan, before build |
build |
working code; per-task review per tier; final integration review; converge loop | plan (or tickets) ready and tests RED |
review-commit |
two-axis pass → R1 → budgeted confirm rounds → commit/deploy gate | after the build, through commit and deploy |
Test ownership: the plan names each test case (behavior, seam, expected
value and its source); test-evals writes those tests and runs them RED;
build implementers make them GREEN and don't rewrite them. An implementer
adds a test only for behavior the plan missed (a bug found mid-build) — under
TDD, and listed in its report.
Two execution paths
Path A — subagent-driven (default, T2/T3): grill → spec (spec → clarify → plan → tickets) → test-evals → build → review-commit.
A fresh implementer subagent per task with per-task review.
Path B — single CLI agent (T1, or T2 greenfield under size-tiers.md rule 7): spec (spec and plan turns) → test-evals → builder lane CLI → review-commit.
The spec feeds one self-contained implementation brief; review-commit's
loop is the quality gate instead of per-task review.
Routing rules
- Tier first. Step 0, always — even when the user says "just build it".
- Plan fuzzy?
grill. Skip if the plan is clear. - No spec, T2/T3?
specspec turn. At T1, put 3-6 acceptance criteria in the plan header instead. - Spec, no plan?
specplan turn (template:spec/references/plan-template.md). - Want parallel units?
spectickets turn (spec/references/ticket-slicing.md). Optional. - Plan, no tests?
test-evals— RED tests for the plan's test cases. - Tests RED, not built?
build. - All tasks done? Converge loop (
build/references/converge-loop.md), within the tier's cap. - Need a review of a diff?
review-commit. - Periodic architecture check?
improve-codebase-architecture(outside skill). - "Just build it" — that's T0 or T1: skip grill and the spec turn, and say so. The review steps still run at the tier's level.
Quick start
- Step 0: pick and state the tier.
- Fuzzy plan →
grill. specspec turn →.hermes/specs/(T2/T3), clarify if markers remain.specplan turn →.hermes/plans/(tickets optional).test-evals→ RED tests for the plan's test cases.build→ tasks with per-task review per tier → final review → converge.review-commit→ Step A → R1 → confirm rounds within budget → gate.
Load one stage skill at a time — each is separate for context economy.
Outside-skill pointers
- Kanban orchestration —
kanban-orchestrator(devops) owns spreading tickets across worker lanes. - Model pins —
references/lanes.mdhere. The outsidemodel-routingskill covers provider and budget choices; it was older thanlanes.mdat v0.2 and should be reconciled with it. - Architecture health —
improve-codebase-architecture(outside skill). - Mid-build doubt —
doubt-driven-development(outside skill). - Lessons from past loops —
review-lessons(this plugin; load one file by case, on demand).