Nine tracks, and
what each one skips.
Reference for the tracks declared in .claude/workflows.jsonl. A track is a dependency graph of workflow phases: triage picks one at the start of a run, and track_guard then enforces that graph's ordering at the write boundary, so a phase cannot be taken out of turn.
Selectable tracks
9 selectable tracks ship in the pristine template, and you pick one of them at triage. The node count on each card is the size of that track's graph, which you can read as a rough measure of how much process the track will add to a run.
Stripped-down pipeline for changes that need no failing-test-driven code change: documentation edits, configuration tweaks, formatting, dependency bumps with no project code change.
6 nodes · commits, chore
Discovery-once track for a multi-subtask feature (seed.md §18.9).
10 nodes · commits, requires_spec
Fast implementation path for ONE slice of an approved epic (seed.md §18.9).
10 nodes · commits
Ad-hoc batch of edits without intake/scout/research/spec/tdd discipline.
4 nodes · commits
Canonical 11-phase pipeline for genuinely novel surface — new functionality with no spec chapter, roadmap item, or in-repo pattern to derive from (novelty: novel) — that needs full design…
17 nodes · commits, requires_spec
Multi-session org-team workflow (Article X): a flat pod of peer Claude Code sessions claims lane-tagged slices of an approved spec over the MCP broker and implements them concurrently,…
13 nodes · commits, requires_spec, git_only
Batch-sprint track: delivers a sprint of related, spec-committed tickets in ONE cycle.
13 nodes · commits, requires_spec, git_only
Spec-first workflow: a short /intake carries gate A, then /scout, then /spec.
15 nodes · commits, requires_spec
Quickfix workflow that starts directly at /tdd.
11 nodes · commits
Sub-tracks
Two tracks carry selectable: false, which means triage will never offer them to you. They are entered by a selector node sitting inside another track, so you reach them only as a consequence of a choice made further up.
Parallel implementation via swarm-plan + approve-swarm + swarm-dispatch.
3 nodes
Solo TDD path. Fallback alternate for intake-full when swarm preconditions fail or the user picks solo explicitly.
1 nodes
Invariants
Each track lists the invariants it meets, and triage checks a track against Article IV before it builds the graph out. If a track breaks one of them, it is rejected with an error naming the rule it failed, so a malformed track can never become a task list.
The track ends in a commit. It has to carry /grant-commit before its commit node.
The track goes through /spec and the approval gate after it.
The track needs a git repo. Without one, triage drops it before ranking.
The track sends out work in parallel, so it needs the swarm approval gate.
Its verify, simplify, integrate and document nodes only run if the diff touches something that needs them.
Preconditions
A track can declare what has to be true before it is even a candidate. The vocabulary is closed: 7 predicate names, and Article IV invariant I11 rejects a track that uses any other.
Gate C applies to this node. It resolves per branch, so a github-flow feature landing can pass where a protected branch cannot.
A dot-path in `project.json` has to equal a given value. Carries `path` and `equals`, and it is the fence behind `power` and `org`.
The project has to be a git repository. On a tree without one, the track drops out before ranking.
The spec has to carry at least this many independent components. Carries an argument, so `3` is the swarm floor.
A named earlier phase has to be finished already. This is how a node waits on discovery it did not run itself.
A named skill has to be on disk. A track that calls a skill you removed drops out rather than failing mid-run.
You have to ask for this track by name. Triage never reaches for it on its own.
Because preconditions run before ranking, a track that cannot apply never competes at all. An exception is a different thing: it skips a single node inside a track you have already picked, and it is recorded in the workflow state where the audit can find it.
Track selection
/triage first classifies how new the request is, as pattern-copy, spec-derived, novel or ambiguous, and it must cite the evidence behind that call. The default is then the lightest track whose guardrails still cover the risk. Choosing a heavier one requires a named reason, which is recorded in the workflow state.
If the tree is not a git repository, a track marked git_only drops out before ranking; a track sitting behind a config flag drops out for as long as that flag is off. That is how power and org stay out of the picker until you deliberately turn them on.
The chosen track's graph becomes your session task list, and track_guard enforces its node order on every workflow artifact written from then on.
Two things can skip a node. The first is the exceptions array that triage records when it creates the workflow; the second is the right-size gate which runs after tdd. On a small enough diff that gate may drop simplify and document, and it records every skip it makes (it can never drop security, or a core phase).
Project-declared tracks
To declare your own tracks, or to add nodes to the shipped ones, edit .claude/workflows.jsonl directly. The Article IV invariants bind every track whoever wrote it. Miss /grant-commit before a commit node, or leave a cycle in the graph, and triage will reject the track outright.
Because that file is on the never-touch list, install and upgrade both leave it alone. Merging your local edits against tracks added upstream is therefore a manual job, and the upgrade will not attempt it for you.