Ceremony you can
prove you don't need.
An eleven-phase workflow is right for a risky feature and absurd for a typo. The velocity levers close that gap, and each one is a config flag. Most of them remove work a machine can prove is unnecessary. One runs the other way and offers you more to batch in when the phases would cost more than the work they carry. None of them decides anything that belongs to you.
The cost of a fixed pipeline
A pipeline that treats every change the same has two failure modes, and only one of them is obvious.
The obvious one is waste. Fixing a typo in a comment does not need a simplify pass, a documentation pass and a security review; run them anyway and you will spend ten minutes on a two-line change.
The quieter one does the real damage. When ceremony feels absurd people route around it, and they stop running the workflow for small changes first, then for medium ones. The guardrails end up covering only the work somebody remembered to be careful about, which is the opposite of what guardrails are for.
So the pipeline gives ground deliberately, in the places where a machine can measure that the ground was empty to begin with.
The thirteen levers
Every lever is a flag under project.json → velocity. 7 ship on, 6 ship off, and you can flip any of them.
Checks each acceptance criterion against the test that claims to cover it.
ships off
Runs the spec checkers side by side instead of one after another.
ships on
Reviews the diff along several lines at once: security, simplicity, structure.
ships on
Scores design options against each other before one is picked.
ships off
Skips re-checking a memory entry that was already verified this session.
ships on
Keeps the plan on disk, so a workflow survives losing its session.
ships on
Mutates your source to find out whether the tests would have caught it.
ships off
Tells you when a run stops and needs you.
ships on
Opens the pod of peer sessions behind the org track.
ships off
Runs a batch of already-specified tickets through the mechanical phases once.
ships off
After the tests pass, measures the real diff and drops ceremony a tiny change never needed.
ships on
Lets the coordination channel hand tasks to helper sessions.
ships off
Weighs the work a workflow carries against what the workflow itself costs, and offers you more to batch in when the balance is poor.
ships on
The split between on and off is a judgement about blast radius. A lever ships on when its worst case is a slower run, and it ships off when the worst case is a surprise, which is why power_mode, org_mode and sprint_mode all wait for you to ask.
The right-size gate
The gate runs once, right after your tests go green, and it is the clearest example of the whole idea: it measures the working tree and then decides whether a couple of phases can safely be dropped.
If a diff touches fewer than 8 files and changes 200 lines or fewer, it counts as micro. Both numbers come from project.json (so you can move them if your changes typically run larger).
micro diff → skip simplify micro + no docs touched → skip document too anything else → run the full set security → always runs, at every size
Two kinds of line are taken out of the measure before it decides. Test files come out, because test lines say nothing about how risky a change is, and files that were already dirty when the workflow started come out too, since this workflow did not produce them. What remains is the change the workflow actually made.
The gate is arithmetic all the way down: file counts, line counts, and whether a path matches a glob. No judgement call enters it anywhere, which is what makes it safe to run without asking you first.
It also speaks up when it stays quiet. If security is being skipped for other reasons and the diff touched a path you marked sensitive, the gate raises an advisory, names those paths, and tells you to run /security yourself.
Payload against envelope
The right-size gate asks whether a change is small enough to drop a phase. This lever asks the opposite. It wants to know whether the change is large enough to justify a workflow at all.
Every run spends its tokens twice. Some go on the payload, which is the phase where code actually gets written. The rest go on everything wrapped around it: discovery, review, the consent gates, the archive. That second number is the envelope. It barely moves with the size of the change, so a two-line fix and a fortnight of work pay nearly identical ceremony.
Dividing payload by envelope gives the ratio. Below 3x the verdict reads under-floor. From 3x it reads acceptable, and at 4x or better it reads optimal. Two further states cover the runs where no honest number exists: not-applicable, when the track has no payload phase, and unfitted, when nothing has been measured yet.
The envelope is measured, not assumed. It is fitted from your own archived runs once a track has five of them. Until then a shipped default stands in, and the verdict is marked unfitted, so a borrowed number is never mistaken for a measurement. This repository has 29 archived tdd-quickfix runs the fitter can read. They put the envelope for that track at 39,105 tokens.
You can ask for the ratio at any point in a run. The command reads the archived timing table once a workflow has landed, and the live timing log while it is still going. No flag withholds it. Asking for a measurement is a read.
payload 109,427 tokens (live) envelope 39,105 tokens (fitted, 29 samples) ratio 2.80 under-floor shortfall 46,993 tokens to the 4x target
Two checkpoints run without being asked. The first fires at triage, before any work starts, from the shape of the request alone: how many acceptance criteria it carries, how many paths it says it will touch. That one is a projection, and it will be wrong early. Being wrong early is tolerable, because its job is to let you fold related work in while folding is still cheap. The second fires once your tests go green. It measures what the run actually spent.
An under-floor verdict blocks nothing. The shortfall is reported, and the run continues if you override it. Both the override and your reason are written into workflow.json, so they ride into the archived bundle rather than evaporating with the session. Where the gap is small, the lever may also name open backlog entries sized to close it. It adds none of them without your approval.
What a lever may never do
Three limits keep a speed-up from quietly becoming a bypass. They hold for every lever, present and future.
A lever may only skip from a fixed allowlist. For the right-size gate that list is simplify and document and nothing else, so core phases stay put and security stays put at every diff size. Whether a change needs a security review is a human call, and the gate has no standing to make it.
A lever adds skips and never removes them. If /triage has already excepted a phase, the gate will leave that alone, because two mechanisms writing the same field in opposite directions is how state goes wrong in a way nobody can reproduce afterwards.
Where a consent gate is involved, no lever reaches it. The three gates are commands you type, checked by a hook which runs before Claude is invoked, and no configuration flag touches that path at all. Turning every lever on therefore leaves the approvals exactly where they were.
The fail-open default
Every lever fails toward the full pipeline. Disable one and you get the whole workflow; break one and you still get the whole workflow, because an error inside the gate returns an empty skip set (fail-open, by design).
That direction is chosen. This machinery can fail in two ways: by running phases you did not need, or by skipping phases you did. The first costs minutes, while the second costs a review that never happened on a change nobody flagged, so every ambiguous case resolves toward doing the work.
The levers read like a performance feature, which undersells them. What they really buy is a workflow that stays usable at small sizes, since a guardrail people route around protects nothing, and the fastest way to get routed around is to be tedious about work that carries no risk.