Feature 9 ACTIVITIES 5 STAGES
About The long path: an intent becomes a spec, a plan, a change, proof, and a release.
The path a change takes when nobody has asked for it yet — someone decided it
was worth building. That is what separates this from Bugfix: the intent has to
be written down and agreed before there is anything to build against, and most
of the cost of getting it wrong is paid at review time, weeks later.
What it assumes
Criteria before code. write-acceptance-criteria sits in Plan, not
Verify, so the review has something written before the change to judge
against — not taste applied after it.Evidence is assembled, not scattered. The reviewer reads one pack. This
is the constraint: everything upstream moves faster than a reviewer can
absorb proof, which is why ① sits on evidence-pack.The inner loop is nested, not flattened. implement contains the real
work — break down, write, self-review — because a single box would hide the
three places a session actually goes wrong.
Where it is still open
write-acceptance-criteria and review-conformance are both open, and both
for the same reason: the tooling that exists can draft and can comment, but the
judgement of whether a change did what was asked has to stay with a person who
can be held to it. review-conformance carries four recommendations and is
still open — recommendations never fill a slot.
Source reference/processes/feature.yaml
One file is one process. The page has no write path — the editor is the editor.
Write Spec Define Product Lead
Work without a written intent gets re-litigated at review time.
Consumes Nothing — this is a source activity.
Produces Spec
→ Plan Work , Write Acceptance Criteria Recommended tooling here /grill-me Claude Code Pressure-test the intent before it is written down — a spec that survives interrogation gets re-litigated less at review time.
Backlog Triage Agent Jira + Rovo Pull what the backlog already knows, so the spec starts from it.
Plan Work Plan Product Lead Engineer
A shared plan is the cheapest place to catch a wrong decomposition.
Produces Work Plan
→ Implement , Break Down Task Recommended tooling here /grill-me Claude Code Two readings of the spec survived contact with the plan. Resolve them by interrogation before decomposing against the wrong one.
Reasoning Budget Claude Code · ASSISTED Spend the extra reasoning on the decomposition, not on the edits. A wrong cut is found days later; a wrong edit is found by the tests.
Write Acceptance Criteria Plan Reviewer
Review against criteria written before the change, not after it.
Consumes Spec
← Write Spec · handoff Produces Acceptance Criteria
→ Implement , Write Tests , Review Conformance Tooling OPEN SLOT A pass that reads the spec and proposes the criteria it implies, so the reviewer edits a list instead of transcribing one. The criteria have to stay the reviewer's — the ask is a draft, not a verdict.
Implement Build Engineer
The change itself — scoped by the plan, aimed at the criteria.
Consumes Work Plan
← Plan Work Acceptance Criteria
← Write Acceptance Criteria · handoff Produces Change Set
→ Assemble Evidence , Prepare Release Sub-process Break Down Task Claude Code · Plan Mode Write Change Self-Review Claude Code · /code-review Expand ▸ in the flow view to see it as a swimlane.
Recommended tooling here /wayfinder Claude Code · ASSISTED Stop and re-decompose rather than pushing on. Solves the sunk-cost drift where a half-built oversized task gets finished anyway.
Plan Mode Claude Code Drop out of writing and re-read the ground before re-cutting the work.
/address-verdict Claude Code Work the verdict item by item. Rework is not a loop in the flow — it is a moment here, with a play attached.
Session Reset Claude Code · MANUAL Start again from what is now known, rather than compacting a session that is already mostly noise. Manual on purpose — deciding what mattered out of the last two hours is the entire job.
Session Rewind Claude Code · ASSISTED Return to the point the work turned, keeping the instructions that opened the session. Check the working tree afterwards: shell and subagent edits are not restored with the conversation.
Completion Condition Claude Code · DELEGATED + REVIEW State the end condition and let a separate evaluator judge each turn against it. It reads the transcript rather than the repository, so the condition must be something the transcript can show.
Orchestrated Fan-Out Claude Code · DELEGATED + REVIEW Codify the fan-out as a script when the work needs more agents than one conversation can hold.
Fan-Out Loop Claude Code · DELEGATED + REVIEW One unattended run per unit, permissions scoped up front. Prove the prompt on two or three units first — a queue applies an ambiguous instruction consistently, which is what makes it hard to spot later.
Worktree Session Claude Code · ASSISTED Separate checkouts so parallel edits cannot collide. Deciding which pieces are genuinely independent stays the engineer's call.
Agent Team Claude Code · ASSISTED Experimental, off by default, and roughly seven times the token spend. Start with work that writes no code, where parallel exploration pays and coordination does not bite.
inside Implement
Break Down Task Build Engineer
A task the agent can hold in one context is a task that ships.
inside Implement
Write Change Build Engineer
The inner loop — explore, edit, test, repeat.
Consumes Task List
← Break Down Task Produces Draft Change
→ Self-Review Sub-process Explore Codebase Claude Code · Explore Subagent Edit + Test Loop Claude Code · Agent Session Expand ▸ in the flow view to see it as a swimlane.
Recommended tooling here Explore Subagent Claude Code · DELEGATED + REVIEW Give the open-ended question to a separate context with a stated thoroughness, so reading the whole repository does not cost the session that has to act on the answer.
… → inside Write Change
Explore Codebase Build Engineer
Consumes Nothing — this is a source activity.
Produces Context Notes
→ Edit + Test Loop … → inside Write Change
Edit + Test Loop Build Engineer
Consumes Context Notes
← Explore Codebase Produces Draft Change
→ Self-Review Recommended tooling here Permission Rules Claude Code · MANUAL Pre-approve the commands already being approved without reading, so the prompts that remain are the ones worth stopping for.
Sandboxed Session Claude Code · ASSISTED Bound the filesystem and network instead of approving one command at a time — the same problem answered by limiting consequences rather than enumerating permissions.
inside Implement
Self-Review Build Engineer
The author reads the diff as a reviewer before the reviewer must.
Consumes Draft Change
← Write Change Produces Change Set
→ Assemble Evidence , Prepare Release
Write Tests Build Engineer
Criteria that never became tests are opinions, not gates.
Consumes Acceptance Criteria
← Write Acceptance Criteria · handoff Produces Test Suite
→ Assemble Evidence
Assemble Evidence Verify Engineer
Reviewers approve on vibes when the proof is scattered across tools.
Consumes Change Set
← Implement Test Suite
← Write Tests Produces Evidence Pack
→ Review Conformance ① Recommended tooling here Structured Result Claude Code · DELEGATED + REVIEW When the evidence is prose a reviewer has to read and believe, return it against a schema instead, so the pipeline can gate on it rather than a person re-running the check by hand.
Completion Hook Claude Code · GATED AUTO Make the check a script the session cannot finish without passing. It is the difference between an agent that believes it is done and one that has been shown to be. The runtime stops honouring a hook that blocks repeatedly, so it is a strong default rather than a guarantee.
Review Conformance Verify Reviewer
The review judges evidence against criteria — not the diff against taste.
Consumes Evidence Pack
← Assemble Evidence · handoff ① Acceptance Criteria
← Write Acceptance Criteria Produces Review Verdict
→ Prepare Release Tooling OPEN SLOT Something that lines the evidence pack up against the acceptance criteria and says which ones are actually answered. This sits directly on the constraint, so it is the slot worth filling first.
Recommended tooling here Automated PR Review GitHub Actions · ASSISTED Standing advice, not a fill: an automated comment on every change is a second pair of eyes and never the verdict. It is good at what is mechanical and locally checkable, and silent on whether the change did what was asked — which is the whole question here.
CLAUDE.md Claude Code · MANUAL When the finding would apply to the next change too, write the rule where every future session reads it. A correction made once is a correction you will make again.
Scoped Rule Files Claude Code · MANUAL When the rule holds for one part of the repository and not the rest, file it there rather than taxing every session with it.
Policy Hook Claude Code · GATED AUTO When the rule is mechanical, make it a hook rather than a sentence. Written instructions are advice a long session drifts from; a hook does not negotiate.
Prepare Release Ship Release Operator
A verdict is not a deployable; someone assembles what actually ships.
Consumes Review Verdict
← Review Conformance · handoff Change Set
← Implement · handoff
Ship Ship Release Operator
The pipeline releases on green; a human can always hold the gate.
Consumes Release Candidate
← Prepare Release Produces Release → leaves the process
/grill-me Claude Code Product Lead Engineer
interview skill
Interrogates a document until the unstated assumptions are on the page.
A skill that reads a draft and asks about it, one question at a time,
instead of rewriting it. The output is a better document written by its
author — not a document written by the agent.
Reach for it when
the draft reads as agreed but nobody can say what was ruled out
two readers took different meanings from the same paragraph
the work following the document has already been re-litigated once
Where the human stands
Every answer is the author's. The skill cannot settle a question about
intent, and a session that ends with the agent's guesses on the page has
produced a document nobody is accountable for.
Reached for recommended in Write Spec Pressure-test the intent before it is written down — a spec that survives interrogation gets re-litigated less at review time.
· recommended in Plan Work Two readings of the spec survived contact with the plan. Resolve them by interrogation before decomposing against the wrong one.
/spec-interview Claude Code Product Lead
interview skill
Turns a request into a written spec by asking, one question at a time.
Inverts the usual order: the agent interviews the person who wants the
change, and the answers become the spec. Nobody writes a prompt describing
what they want and hopes the draft resembles it.
Reach for it when
the request arrived as a sentence and the work is a fortnight
two people are describing the same feature and neither has written it down
the last change of this shape was rebuilt after review
Where the human stands
assisted. Intent is the one input that cannot be delegated — every answer
is the requester's, and the skill's contribution is the order of the
questions. Start a fresh session to build from the finished spec: the
interview transcript is how the spec was reached, not what it says.
Reached for fills the slot in Write Spec
/wayfinder Claude Code Engineer
re-decomposition skill
Re-cuts oversized work into tasks an agent can hold in one context.
Takes work that has turned out larger than planned and cuts it again, into
pieces each of which can be finished, reviewed and shipped on its own.
The cut is against context , not against effort. A task is the right
size when the code it touches, the tests it must pass, and the reasoning
behind it all fit in one session — not when it fits in one day.
Reach for it when
the session is mostly re-reading files it already read
the diff has grown past what one reviewer will read carefully
finishing the task requires holding two unrelated subsystems at once
Where the human stands
assisted. Where the seams fall is a judgment about what the team can
hold and ship independently, and that judgment stays with the team.
Reached for · recommended in Implement Stop and re-decompose rather than pushing on. Solves the sunk-cost drift where a half-built oversized task gets finished anyway.
Plan Mode Claude Code Product Lead Engineer
built-in mode
Reads and reasons without writing — the cheap place to be wrong.
Reads the repository and reasons about the change while edits stay
blocked. The session produces a plan, and nothing is written until someone
approves it.
The value is where the mistake lands. A wrong plan costs a conversation; a
wrong change costs a review cycle, and sometimes a revert.
Reach for it when
the change touches code nobody on the call has read recently
there is more than one defensible approach and the choice matters
the work will be handed to an unattended run afterwards
Where the human stands
delegated-review when planning the work: the agent drafts, and the
approval is a real gate — editing stays blocked until it is given.
assisted when the question is how to cut the work up rather than how to
do it, because that answer depends on the team, not on the code.
Reached for fills the slot in Plan Work · recommended in Implement Drop out of writing and re-read the ground before re-cutting the work.
fills the slot in Break Down Task
Agent Session Claude Code Engineer
agentic edit loop
The default working loop — explore, edit, run, repeat, under review.
The ordinary working loop: the agent reads, edits, runs the tests, reads
the failure, and goes again — with an engineer reading every diff.
What holds it
The loop is only as good as the check at the end of it. A session with a
test suite that actually fails on a wrong change can run a long way; a
session whose only oracle is the agent's own reading of its work cannot,
and should be kept short and reviewed closely.
Where the human stands
delegated-review, and this is the ceiling until verification is
mechanical. Running with permissions disabled is not a higher rung — it is
the same loop with nothing holding it.
Reached for fills the slot in Implement fills the slot in Edit + Test Loop
Explore Subagent Claude Code Engineer
read-only search agent
Sweeps the codebase and returns the conclusion, not the file dumps.
Answers a question about the codebase in a separate context , and
returns the answer rather than the files it read. Write and Edit are
denied to it, so the worst outcome of a wrong answer is a wasted read.
Reach for it when
the question spans more directories than one reading will cover
the answer is one paragraph but finding it means opening thirty files
the main session's context is better spent on the change itself
Where the human stands
delegated-review. Read-only by construction, so the delegation is
genuinely cheap — but the conclusion is still a claim, and a claim that
decides the shape of a change deserves one file opened to confirm it.
Reached for · recommended in Write Change Give the open-ended question to a separate context with a stated thoroughness, so reading the whole repository does not cost the session that has to act on the answer.
fills the slot in Explore Codebase
/test-from-criteria Claude Code Engineer
test authoring skill
Writes the suite from acceptance criteria, so criteria become gates.
Reads the acceptance criteria and writes the tests that check them, so a
criterion the team agreed to becomes something that can fail.
Criteria written as observable outcomes translate; criteria written as
instructions do not. "The import rejects a malformed row and reports the
line number" becomes a test. "Validate the input properly" becomes an
argument about what the test should assert.
Where the human stands
delegated-review. Writing the checks from criteria is mechanical enough
to delegate; deciding the criteria was the judgment, and it happened
earlier.
Reached for fills the slot in Write Tests Refs skills/test-from-criteria
/evidence-block Claude Code Engineer
evidence assembly skill
Collects the proof a reviewer needs into one block they can read.
Gathers what a reviewer would otherwise reconstruct — what was run, what it
returned, which criteria it maps to — into one block at the top of the
change.
Reach for it when
the change is larger than a reviewer will re-run themselves
the interesting part of the work is a behaviour, not a diff
the review is asynchronous and the author will not be there to answer
Where the human stands
delegated-review. Assembling the evidence is clerical; judging whether
it is sufficient is the review, and the review stays human here on
purpose.
Reached for fills the slot in Assemble Evidence
/address-verdict Claude Code Engineer
rework skill
Works a review verdict item by item instead of re-reading the diff.
Takes a review verdict and works it one finding at a time, so each item is
answered — changed, or argued with — instead of the whole diff being read
again and quietly re-litigated.
The failure it prevents
Rework that starts from the diff rather than the verdict tends to fix the
findings that were easy to locate and lose the ones phrased as questions.
Ending item by item makes the omission visible.
Where the human stands
delegated-review. Not every finding should be actioned: a reviewer
prompted to find gaps will report some even when the work is sound, and
chasing all of them produces over-engineering. Which findings matter is
the author's call, and it is a call the team makes by hand today.
Reached for · recommended in Implement Work the verdict item by item. Rework is not a loop in the flow — it is a moment here, with a play attached.
/code-review Claude Code Engineer
review skill
Reads the diff in a fresh context that never saw the reasoning behind it.
Reviews the current change in a separate context that has seen the diff
and the criteria, and none of the argument that produced them.
The freshness is the mechanism. An author — human or agent — reads their own
diff already knowing what it was supposed to do, and reads that intention
into code that does not contain it. A reader with no such knowledge cannot.
Prompt it for the gaps that matter
A reviewer asked to find gaps will find some, whether or not any exist.
Left open-ended it reports style, hypotheticals and defensive rewrites, and
chasing all of them produces over-engineering. Ask it for findings that
affect correctness, and treat the rest as optional.
Where the human stands
delegated-review. It reports; it does not decide. Which findings are
worth acting on is a judgment this team still makes entirely by hand — two
teams that scored hundreds of AI review comments ranked them differently
depending on the criterion, and one accepted none.
Reached for fills the slot in Self-Review
CLAUDE.md Claude Code Reviewer
memory file
Standing instructions every session reads — advice, not policy.
The repository's standing instructions to the agent, read at the start of
every session. This is where a correction stops being something a person
repeats and becomes something the next session already knows.
Advisory, not enforced
The file is delivered as guidance, not as a constraint the runtime applies.
A long session drifts from it; a rule that must hold belongs in a hook,
where nothing negotiates with it.
It goes stale, and staleness is expensive
The documented failure is not too few rules but too many: an over-specified
file whose real rules are lost among dead ones, and the agent ignoring all
of them equally. Treat it like code — review it when something goes wrong,
and prune it on purpose.
Where the human stands
manual, and the gauge should say so. Knowing which rule stopped being
true is knowing why it was written, and nothing else in the toolchain
knows that.
Reached for · recommended in Review Conformance When the finding would apply to the next change too, write the rule where every future session reads it. A correction made once is a correction you will make again.
Scoped Rule Files Claude Code Reviewer
scoped instruction files
Conventions that hold in one directory, filed where they hold.
Instructions attached to a part of the repository rather than to all of it,
so a rule that is true of one package does not tax every session that never
opens it.
Where the human stands
manual. The decision is whether a convention is a house rule or a local
one, and getting it wrong in the generous direction is how a standing
instruction file becomes noise.
Reached for · recommended in Review Conformance When the rule holds for one part of the repository and not the rest, file it there rather than taxing every session with it.
Policy Hook Claude Code Reviewer
policy hook
Blocks a forbidden action before it runs, and does not negotiate.
A script that runs before an action and can refuse it. Where a written
instruction is advice the session may drift from, this is a gate that
either passes or does not.
Reach for it when
the same instruction has been ignored more than once
the rule is mechanical enough to express as a check
the cost of the action going through is worse than the cost of a false block
Where the human stands
gated-autonomous. No model is in the loop: a person decided once, when
they wrote the hook, and holds the gate by leaving it in place. That is the
same shape as the release gate, at a smaller scale.
Reached for · recommended in Review Conformance When the rule is mechanical, make it a hook rather than a sentence. Written instructions are advice a long session drifts from; a hook does not negotiate.
Completion Hook Claude Code Engineer
lifecycle gate hook
A script decides whether the turn may end, and nothing talks it round.
Runs when the session tries to finish, and blocks the finish until the
check passes. It is the difference between an agent that believes it is
done and an agent that has been shown to be done.
The caveat worth authoring
The gate is firm, not absolute — after a run of consecutive blocks the
runtime stops honouring it, on the assumption that the check itself is
broken. Treat it as a strong default, not as a guarantee.
Where the human stands
gated-autonomous. The check is a script the team wrote, at a fixed point,
with no model judgment in it. This is what turns a session somebody watches
into one they can walk away from.
Reached for · recommended in Assemble Evidence Make the check a script the session cannot finish without passing. It is the difference between an agent that believes it is done and one that has been shown to be. The runtime stops honouring a hook that blocks repeatedly, so it is a strong default rather than a guarantee.
Completion Condition Claude Code Engineer
completion condition
Keeps working toward a stated end state — judged from the transcript.
States the condition the work must reach, and keeps the session going until
it holds or is judged impossible, with a separate evaluator checking after
each turn.
Read the evaluator honestly
It judges what the session surfaced , not the repository. It does not run
the suite itself or open the files. So the condition has to be something a
transcript can demonstrate — "the suite passes, with the output shown"
rather than "the code is correct".
Where the human stands
delegated-review, not the top rung. The proof is still a claim, and a
claim is what the review exists to check. Pair it with a hook when the
claim needs to be a fact.
Reached for · recommended in Implement State the end condition and let a separate evaluator judge each turn against it. It reads the transcript rather than the repository, so the condition must be something the transcript can show.
Session Reset Claude Code Engineer
session hygiene
Ends a session that has become mostly a record of what did not work.
Ends the session and starts again, carrying forward what was learned rather
than the history of learning it.
Why starting over beats pushing on
A session that has failed twice at the same thing is now mostly failed
approaches, and each new attempt is read against all of them. The rule of
thumb is blunt on purpose: after the second failed correction, stop, and
write a better opening prompt using what the failures taught.
Where the human stands
manual, honestly. Deciding what mattered out of a long session is the
whole job, and it is the part no summary does for you.
Reached for · recommended in Implement Start again from what is now known, rather than compacting a session that is already mostly noise. Manual on purpose — deciding what mattered out of the last two hours is the entire job.
Reasoning Budget Claude Code Product Lead Engineer
reasoning control
Buys more thinking where a wrong answer is expensive to discover.
Raises how much reasoning a run spends before it acts.
Spend it where a mistake is found late — on the decomposition, on the
diagnosis — not on the edit loop, where the tests find the mistake in
seconds. The highest setting is prone to overthinking, and a plan that
argues with itself is not a better plan.
Where the human stands
assisted. Knowing which decisions are expensive to get wrong is the
judgment, and it is the team's.
Reached for · recommended in Plan Work Spend the extra reasoning on the decomposition, not on the edits. A wrong cut is found days later; a wrong edit is found by the tests.
Permission Rules Claude Code Engineer
permission config
Pre-approves what you already approve, so the rest gets read.
Declares in advance which actions run without asking, which always ask, and
which are refused outright.
The failure it addresses
Prompt fatigue is a safety problem, not an ergonomic one. When every
command asks, approval becomes a reflex, and the one prompt that mattered
is approved at the same speed as the fifty that did not.
Where the human stands
manual. Writing the list is the decision — it is where the team says
once, deliberately, what it is willing not to look at.
Reached for · recommended in Edit + Test Loop Pre-approve the commands already being approved without reading, so the prompts that remain are the ones worth stopping for.
Sandboxed Session Claude Code Engineer
OS isolation
Bounds what a session can touch instead of approving it action by action.
Restricts the filesystem and network the session can reach, so most
commands can run without a prompt because the blast radius is bounded by
construction rather than by attention.
Where the human stands
assisted. The bound is set once by a person; inside it the work proceeds.
It answers the same problem as the allowlist from the other end — bounding
consequences rather than enumerating permissions.
Reached for · recommended in Edit + Test Loop Bound the filesystem and network instead of approving one command at a time — the same problem answered by limiting consequences rather than enumerating permissions.
Worktree Session Claude Code Engineer
parallel isolated checkout
A separate checkout per session, so parallel work cannot collide.
Gives each concurrent session its own checkout, so two agents working at
once cannot edit the same file out from under each other.
Where the human stands
assisted. Isolation is mechanical; deciding which pieces of work are
genuinely independent is not, and being wrong about that produces two
changes that merge cleanly and contradict each other.
Reached for · recommended in Implement Separate checkouts so parallel edits cannot collide. Deciding which pieces are genuinely independent stays the engineer's call.
Orchestrated Fan-Out Claude Code Engineer
subagent orchestration script
Runs many subagents in the background when one session cannot hold the work.
A script that runs many agents over a work list — a sweep across the whole
codebase, a migration touching hundreds of files, a question attacked from
several angles at once — and returns the result rather than the transcript.
Where the human stands
delegated-review. The fan-out is mechanical once the work list exists.
Writing the list, and stating what "done" looks like for one item, is the
part that decides whether the run is worth anything.
Reached for · recommended in Implement Codify the fan-out as a script when the work needs more agents than one conversation can hold.
Agent Team Claude Code Engineer
multi-session orchestration
Several agents on one problem — experimental, and expensive.
A lead agent and teammates, each with its own session and context, working
one problem together.
Read the caveats before reaching for it
Experimental and off by default. It is not the way work is done here.Roughly seven times the token spend of a single session.Teammates may stop on an error rather than recovering from it, and an
interrupted team does not resume cleanly.
Where the human stands
assisted, and only as advice bound to a moment — never as how an activity
is performed. Start with work that writes no code, such as a review or a
piece of research, where parallel exploration pays and coordination does
not bite.
Reached for · recommended in Implement Experimental, off by default, and roughly seven times the token spend. Start with work that writes no code, where parallel exploration pays and coordination does not bite.
Session Rewind Claude Code Engineer
checkpoint restore
Returns to the point the work turned, keeping the opening intact.
Restores the session to an earlier point, so a run that went wrong can be
resumed from before it did rather than argued out of.
What it does not restore
Changes made by shell commands are not tracked, and edits made by subagents
usually are not either. So the conversation can rewind while the working
tree does not — check the tree before trusting the restore.
Where the human stands
assisted. Choosing the point to return to is a judgment about where the
reasoning went wrong, which is the same judgment as diagnosing the work.
Reached for · recommended in Implement Return to the point the work turned, keeping the instructions that opened the session. Check the working tree afterwards: shell and subagent edits are not restored with the conversation.
Fan-Out Loop Claude Code Engineer
batch script
One unattended run per unit, with permissions scoped up front.
Generates the work list, then runs the agent once per item with the
permitted actions declared in advance.
Prove the prompt before running the queue
Run two or three items, read the results, and fix the prompt. A queue of
two hundred does not report that the instruction was ambiguous — it applies
the ambiguity two hundred times, consistently, which is what makes it hard
to spot afterwards.
Let a script be the referee
The pattern holds when something mechanical decides whether an item is
done — a compiler, a test suite, a diff. Where the only judge is the
agent's own reading of its work, the loop should be short and watched.
Where the human stands
delegated-review. Each unit is reviewed; the queue is not re-run by hand.
Reached for · recommended in Implement One unattended run per unit, permissions scoped up front. Prove the prompt on two or three units first — a queue applies an ambiguous instruction consistently, which is what makes it hard to spot later.
Structured Result Claude Code Engineer
machine-readable result
Returns a result against a schema, so a pipeline can gate on it.
Returns the answer in a declared shape rather than as prose, so a script
can branch on it instead of a person reading it.
This is what moves a check from something a reviewer performs to something
the pipeline performs — the difference between evidence a human assembles
and a gate that holds on its own.
Where the human stands
delegated-review. The schema is the contract, and a result that satisfies
the schema can still be wrong about the world.
Reached for · recommended in Assemble Evidence When the evidence is prose a reviewer has to read and believe, return it against a schema instead, so the pipeline can gate on it rather than a person re-running the check by hand.
Automated PR Review GitHub Actions Reviewer
review workflow
Comments on every change — a second pair of eyes, never the verdict.
Runs on every pull request and comments, without being asked.
Deliberately not the verdict
Because it runs on everything, it comments on everything, and its findings
arrive without any sense of which ones matter. It is well suited to what is
mechanical and locally checkable — a missing case, an inconsistent
signature — and poorly suited to whether the change does what was asked.
Where the human stands
assisted, and this is the honest ceiling. The verdict on conformance
stays with the reviewer, because conformance is a question about intent and
intent is not in the diff.
Reached for recommended in Review Conformance Standing advice, not a fill: an automated comment on every change is a second pair of eyes and never the verdict. It is good at what is mechanical and locally checkable, and silent on whether the change did what was asked — which is the whole question here.
Backlog Triage Agent Jira + Rovo Product Lead
rovo agent
Reads the backlog for what is already known about this work.
Searches the backlog and the issue history for what has already been said
about this work: the duplicate, the earlier attempt, the decision that
closed it last time.
Reach for it when
the request sounds familiar and nobody can name the ticket
the area has been changed before by someone who has since left
triage is about to estimate work that was already estimated once
Where the human stands
assisted. It surfaces what exists. Whether a prior ticket makes this one
a duplicate, a regression, or a genuinely new request is a triage
decision.
Reached for recommended in Write Spec Pull what the backlog already knows, so the spec starts from it.
Release Gate CI Pipeline Release Operator
pipeline gate
Releases on green; a human can always hold the gate.
The pipeline builds, runs the suite, and proceeds unless someone holds it.
No model is in the loop: the checks are the checks the team wrote.
Where the human stands
gated-autonomous — the top rung, honestly earned. The release happens
without anyone approving it, and a human can stop it at any point. Both
halves have to be true; a gate nobody can hold is not this rung, and a
release that waits for approval is not either.
Spec ARTIFACT
What the change is for and what it must do, written before anyone builds it.
A spec is done when a reader who was not in the conversation can say what
is in scope and what is not.
Produced by Write Spec Define · Product Lead Consumed by Plan Work Plan · Product Lead, Engineer Write Acceptance Criteria Plan · Reviewer
Work Plan ARTIFACT
The route from spec to change: the order of the work, what it touches, and
what has to be true before it starts.
Produced by Plan Work Plan · Product Lead, Engineer Consumed by Implement Build · Engineer Break Down Task Build · Engineer
Acceptance Criteria ARTIFACT
The checks the change is measured against, agreed before the work begins.
Written as observable outcomes, not as instructions — a criterion that
describes how the work is done cannot fail honestly.
Produced by Write Acceptance Criteria Plan · Reviewer Consumed by Implement Build · Engineer Write Tests Build · Engineer Review Conformance Verify · Reviewer
Task List ARTIFACT
The spec cut into pieces small enough that one of them can be finished,
reviewed, and shipped without holding the rest in your head.
Produced by Break Down Task Build · Engineer Consumed by Write Change Build · Engineer
Context Notes ARTIFACT
What the code and the history already say about the area being changed:
constraints, prior decisions, and the traps a reader would otherwise walk into.
Produced by Explore Codebase Build · Engineer Consumed by Edit + Test Loop Build · Engineer
Draft Change ARTIFACT
The change while it is still being argued with — compiling, incomplete, and
not yet asking anyone for judgment.
Produced by Write Change Build · Engineer Edit + Test Loop Build · Engineer Consumed by Self-Review Build · Engineer
Change Set ARTIFACT
The change offered for review: the diff, its tests, and nothing left in it
that its author would not defend.
Produced by Implement Build · Engineer Self-Review Build · Engineer Consumed by Assemble Evidence Verify · Engineer Prepare Release Ship · Release Operator
Test Suite ARTIFACT
The executable statement of what must keep working. It is the evidence the
rest of the process quotes.
Produced by Write Tests Build · Engineer Consumed by Assemble Evidence Verify · Engineer
Evidence Pack ARTIFACT ① THE CONSTRAINT
What proves the change does what it claims: test runs, checks, and the
output a reviewer would otherwise have to reproduce by hand.
The evidence handoff is the system's constraint: everything upstream of it moves faster than the reviewer can absorb proof. Improve here first.
Produced by Assemble Evidence Verify · Engineer Consumed by Review Conformance Verify · Reviewer
Review Verdict ARTIFACT
The reviewer's decision on conformance — the change matches the intent, or
it does not and here is where.
Produced by Review Conformance Verify · Reviewer Consumed by Prepare Release Ship · Release Operator
Release Candidate ARTIFACT
A change set that has passed review and is packaged for production, waiting
only on the decision to go.
Produced by Prepare Release Ship · Release Operator Consumed by Ship Ship · Release Operator
Release ARTIFACT
The change in production, with the record of when it went and what it
contained.
Produced by Ship Ship · Release Operator Consumed by Nobody — it leaves the process here.
Bug Report ARTIFACT
The claim that something is wrong, as it arrived — from a user, an alert, or
a colleague. It is a report, not yet a fact.
Produced by Nothing in this process — it arrives from outside.
Consumed by Nobody — it leaves the process here.
Reproduction ARTIFACT
The steps that make the bug happen on demand. Until this exists, the root
cause is a hypothesis and any fix is a guess.
Produced by Nothing in this process — it arrives from outside.
Consumed by Nobody — it leaves the process here.
Root Cause ARTIFACT
The mechanism that produced the bug, stated deeply enough that the fix is
obvious and the class of bug — not the instance — is closed.
Produced by Nothing in this process — it arrives from outside.
Consumed by Nobody — it leaves the process here.
Regression Test ARTIFACT
The test that fails on the old code and passes on the new one. It is what
turns a fix into a guarantee.
Produced by Nothing in this process — it arrives from outside.
Consumed by Nobody — it leaves the process here.
Incident Record ARTIFACT
The live account of an open incident: what is known, what was tried, and
when. Written while it is happening, because memory rewrites it afterwards.
Produced by Nothing in this process — it arrives from outside.
Consumed by Nobody — it leaves the process here.
Impact Assessment ARTIFACT
Who is affected and how badly. Severity is set from this, and every
communication downstream quotes it.
Produced by Nothing in this process — it arrives from outside.
Consumed by Nobody — it leaves the process here.
Status Update ARTIFACT
What people outside the response need to know right now: current state,
what is being done, and when the next update comes.
Produced by Nothing in this process — it arrives from outside.
Consumed by Nobody — it leaves the process here.
Mitigation ARTIFACT
The action that stops the harm. It is not the fix — a mitigation that is
mistaken for one leaves the cause in place.
Produced by Nothing in this process — it arrives from outside.
Consumed by Nobody — it leaves the process here.
Postmortem ARTIFACT
The account written after the incident closes: what happened, why the system
allowed it, and what changes so the next one is smaller.
Produced by Nothing in this process — it arrives from outside.
Consumed by Nobody — it leaves the process here.
Follow-Up Work ARTIFACT
The commitments a postmortem makes, handed back to the delivery process as
real work rather than as good intentions.
Produced by Nothing in this process — it arrives from outside.
Consumed by Nobody — it leaves the process here.
Product Lead ROLE 2 ACTIVITIES 2 FILLED
Owns intent — what to build and why.
Decides what the team builds next and why it is worth building. Holds the
spec and the acceptance criteria, and is the one who can say a change is
out of scope .
Owns
The spec — what the change must do, in the team's own words.Acceptance criteria — the list a reviewer later reads the change against.Scope — the standing authority to say "not in this change".
Delegation posture
Mostly assisted . Intent is the one thing the team cannot hand to a tool,
so the leverage is in drafting and pressure-testing it — grill-me against
the criteria, not a generated spec.
A spec a tool wrote is a spec nobody decided. The ladder tops out here on
purpose.
Owns Write Spec Define · ASSISTED Plan Work Plan · DELEGATED + REVIEW
Engineer ROLE 9 ACTIVITIES 8 FILLED
Owns the change and its proof.
Turns a spec into a change set and the evidence that it works. Owns the
code, its tests, and the honesty of both.
A change, end to end
Read the spec and the acceptance criteria — one test per criterion.
Decompose before building; re-decompose when the task turns out bigger.
Implement, run the suite, and hand back the change with its evidence.
Delegation posture
Work Level Implementation delegated-reviewTest writing delegated-reviewDecomposition assisted
This is where delegation runs highest — implementation and test writing are
the work most safely handed over, provided the proof comes back with it .
See Layer 3 — Capability fills for
what each rung claims.
Owns Plan Work Plan · DELEGATED + REVIEW Implement Build · DELEGATED + REVIEW Break Down Task Build · ASSISTED Write Change Build Explore Codebase Build · DELEGATED + REVIEW Edit + Test Loop Build · DELEGATED + REVIEW Self-Review Build · DELEGATED + REVIEW Write Tests Build · DELEGATED + REVIEW Assemble Evidence Verify · DELEGATED + REVIEW
Reviewer ROLE 2 ACTIVITIES 0 FILLED
Owns conformance — the change matches the intent.
Judges whether the change does what the spec asked, and says so in a
verdict. Reviews conformance and risk , not taste.
Reads
The acceptance criteria — the only thing the change is measured against.
The change set and its evidence pack.
What the change touches that the spec never mentioned.
Does not read
Style. A formatter has an opinion; a reviewer does not need one.
A tool can find defects here, but the verdict stays human: it is a decision
about intent, and intent is not in the diff .
Owns Write Acceptance Criteria Plan · open slot Review Conformance Verify · open slot
Release Operator ROLE 2 ACTIVITIES 1 FILLED
Owns the path to production.
Owns everything between an approved change and a release: packaging,
promotion, the go decision, and the way back if it goes wrong.
The gate
Release runs gated-autonomous — the pipeline builds, tests, and proceeds
unless someone holds the gate. The operator is the one who can hold it.
Always ready to answer
What is in this release?
What breaks if it is wrong?
How do we get back to the previous state, and how long does that take?
Autonomy at the gate is not the absence of a human. It is a human who has
decided not to intervene yet .
Owns Prepare Release Ship Ship Ship · GATED AUTO
Claude Code HARNESS 25 TOOLS
Agentic CLI — skills, plan mode, subagents.
An agentic CLI that works in the repository: reads the code, runs commands,
and edits files under review. Skills, plan mode, and subagents are how a
team encodes its own practice into it.
Its reach is the reason most of the delivery process can be delegated at
all — and the reason review stays the gate.
What lives on this shelf
Kind Examples Encoded practice skills, CLAUDE.md, scoped rule files Bounded delegation plan mode, read-only subagents Deterministic gates lifecycle hooks, permission rules Unattended runs batch scripts, machine-readable results
The last row runs with nobody there to answer a question, so the judgment
moves out of the session and into what is written before it starts — the
prompt, the permitted actions, the exit condition. Same agent, same shelf;
what changes is when the thinking happens, not where it runs.
The row above it is the one that changes the ladder. Instructions to the agent
are advisory and a long session forgets them; a hook is a script at a fixed
point that does not negotiate. Where this team runs gated-autonomous
inside a session, it is a hook doing the holding.
Tools /grill-me interview skill · 2 uses /spec-interview interview skill · 1 uses /wayfinder re-decomposition skill · 1 uses Plan Mode built-in mode · 3 uses Agent Session agentic edit loop · 2 uses Explore Subagent read-only search agent · 2 uses /test-from-criteria test authoring skill · 1 uses /evidence-block evidence assembly skill · 1 uses /address-verdict rework skill · 1 uses /code-review review skill · 1 uses CLAUDE.md memory file · 1 uses Scoped Rule Files scoped instruction files · 1 uses Policy Hook policy hook · 1 uses Completion Hook lifecycle gate hook · 1 uses Completion Condition completion condition · 1 uses Session Reset session hygiene · 1 uses Reasoning Budget reasoning control · 1 uses Permission Rules permission config · 1 uses Sandboxed Session OS isolation · 1 uses Worktree Session parallel isolated checkout · 1 uses Orchestrated Fan-Out subagent orchestration script · 1 uses Agent Team multi-session orchestration · 1 uses Session Rewind checkpoint restore · 1 uses Fan-Out Loop batch script · 1 uses Structured Result machine-readable result · 1 uses
GitHub Actions HARNESS 1 TOOLS
Agent work triggered by what happens on the repository.
Runs the agent in response to repository events — an issue opened, a pull
request raised, a mention in a comment — inside a runner, under the app's
own permissions. Nobody's laptop is involved and no one has to remember to
start it.
What it changes
Work arrives where the conversation already is. A question asked on an
issue gets answered on that issue, and the answer is visible to everyone
who will later ask why the change looks like this.
Where the human stands
Deliberately low on the ladder here. An automated comment on every pull
request is a second pair of eyes, never a verdict — this team keeps the
verdict human, and an agent that posts on every change is not the thing
that should be allowed to approve one.
Tools Automated PR Review review workflow · 1 uses
Jira + Rovo HARNESS 1 TOOLS
Work tracking with Rovo agents.
Where work is tracked and where the team's written history lives. Rovo
agents act inside that record rather than beside it, which is what makes
planning and decomposition delegable.
Tools Backlog Triage Agent rovo agent · 1 uses
CI Pipeline HARNESS 1 TOOLS
Build, test, and release automation.
The automation that builds, tests, and ships. It is the only harness that
routinely runs gated-autonomous : it proceeds on its own and a human
holds the stop.
Tools Release Gate pipeline gate · 1 uses
Observability Stack HARNESS 0 TOOLS
Metrics, logs, traces, and alert routing.
Metrics, logs, traces, and the alert routing on top of them. It is what
turns "something is wrong" into an impact assessment, and what the incident
process reads from throughout.
Tools Nothing on the shelf runs in it yet.
Task bigger than planned EVENT 3 RECOMMENDATIONS
Mid-task the work turns out larger than its plan — stop and re-decompose before pushing on.
Reached for when it happens Reasoning Budget in Plan Work /wayfinder in Implement Plan Mode in Implement
Spec is ambiguous EVENT 1 RECOMMENDATIONS
Two readings of the spec survive contact with the work.
Reached for when it happens
Rework requested EVENT 1 RECOMMENDATIONS
The review verdict comes back with required changes.
Reached for when it happens /address-verdict in Implement
Cannot reproduce EVENT 0 RECOMMENDATIONS
The report does not reproduce on demand — the bug is a hypothesis until it does.
Reached for when it happens Defined, but nothing is bound to it yet.
Blast radius unknown EVENT 0 RECOMMENDATIONS
The signals do not yet say who is affected or how badly — severity cannot be set.
Reached for when it happens Defined, but nothing is bound to it yet.
Mitigation does not hold EVENT 0 RECOMMENDATIONS
The service recovers and degrades again — the mitigation treated a symptom.
Reached for when it happens Defined, but nothing is bound to it yet.
Context is full EVENT 2 RECOMMENDATIONS
The session has read more than it can hold, and decisions made earlier stop being honoured.
Reached for when it happens Session Reset in Implement Session Rewind in Implement
Same failure survives correction EVENT 0 RECOMMENDATIONS
Two corrections in, the same thing is still wrong, and the history is now mostly failed approaches.
Reached for when it happens Defined, but nothing is bound to it yet.
No check to run EVENT 3 RECOMMENDATIONS
The work looks done and nothing in the repository produces a pass or a fail on it.
Reached for when it happens Completion Condition in Implement Structured Result in Assemble Evidence Completion Hook in Assemble Evidence
Question has no edges EVENT 1 RECOMMENDATIONS
A question was asked without a boundary, and the reading it needs has no natural end.
Reached for when it happens Explore Subagent in Write Change
Verdict is about a class, not a change EVENT 3 RECOMMENDATIONS
The finding would apply to the next change too — it is a rule, not a defect.
Reached for when it happens CLAUDE.md in Review Conformance Scoped Rule Files in Review Conformance Policy Hook in Review Conformance
Work splits into independent units EVENT 4 RECOMMENDATIONS
The task is many similar pieces that do not depend on each other.
Reached for when it happens Orchestrated Fan-Out in Implement Fan-Out Loop in Implement Worktree Session in Implement Agent Team in Implement
Approving without reading EVENT 2 RECOMMENDATIONS
Enough permission prompts have gone by that clicking has replaced reading.
Reached for when it happens Permission Rules in Edit + Test Loop Sandboxed Session in Edit + Test Loop