Example Team VERSION 0.3 LIVING
About A vendor-neutral reference for how a small product team delivers changes and where AI is utilized. Copy this folder, rename the team, and fill the open slots.
This document is an example of the format, not a prescription. Nothing in it is
a recommendation for your team: the roles, the artifacts and the three processes
are the ones a small product team usually ends up with, written out so you have
something to disagree with rather than a blank file to stare at.
How to read it
Start with a process, not the catalog. The catalog is a shelf; it means
nothing until you see which activity reaches for what.The ① marks the constraint — the one handoff the team believes everything
else waits behind. Improving anywhere else moves nothing.A dashed activity is an open slot : work the team has decided to hand over
and has not yet. It is a roadmap item, and it says what it wants.An activity with nothing on it is not a gap. It is work the team does
itself and has no intention of changing.
What it is honest about
Four activities are open and five are unclaimed, because a document where every
box is filled is a document nobody believed while writing it. The delegation
level on each fill is the argument, not the tool name — gated-autonomous is
reserved here for the things with no model in the loop at all.
Making it yours
ai-sdlc example --copy <dir> hands you this folder to edit. Rename it — the
folder name is the team id — then cut what your team does not do. Deleting is
the faster half of the work.
Source reference/
One folder is one team: the document plus one file per process. The page has no
write path — the editor is the editor.
Product Lead ROLE lead
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.
Engineer ROLE engineer
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.
Reviewer ROLE reviewer
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 .
Release Operator ROLE operator
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 .
On-Call Engineer ROLE sre
Owns service health while an incident is open.
Holds the service while an incident is open — assessing impact, mitigating
harm, and keeping the record straight so the postmortem has something true
to read.
While the incident is open
Assess — who is affected, how badly, and since when.Mitigate — the smallest change that stops the harm, not the right fix.Record — a timeline written as it happens , never reconstructed after.
Delegation posture
Speed matters most here, which is exactly why the gates stay human. A
mitigation the on-call did not choose is a second incident.
Claude Code HARNESS 28 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 /spec-interview interview skill /wayfinder re-decomposition skill Plan Mode built-in mode Agent Session agentic edit loop Explore Subagent read-only search agent /test-from-criteria test authoring skill /test-from-repro test authoring skill /evidence-block evidence assembly skill /address-verdict rework skill /bisect history search skill /postmortem incident writeup skill /code-review review skill CLAUDE.md memory file Scoped Rule Files scoped instruction files Policy Hook policy hook Completion Hook lifecycle gate hook Completion Condition completion condition Session Reset session hygiene Reasoning Budget reasoning control Permission Rules permission config Sandboxed Session OS isolation Worktree Session parallel isolated checkout Orchestrated Fan-Out subagent orchestration script Agent Team multi-session orchestration Session Rewind checkpoint restore Fan-Out Loop batch script Structured Result machine-readable result GitHub Actions HARNESS 2 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 Mention on the Thread event-triggered agent Automated PR Review review workflow Jira + Rovo HARNESS 2 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 Follow-Up Agent rovo agent 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 Observability Stack HARNESS 3 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 Alert Routing paging rule Signal Correlation query agent Recovery Check signal check /grill-me Claude Code 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.
/spec-interview Claude Code 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.
/wayfinder Claude Code 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 Feature recommended in
Implement ASSISTED
Build Engineer
Task bigger than planned 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 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 Bugfix recommended in
Apply Fix ASSISTED
Fix Engineer
Same failure survives correction Drop out of writing and re-read the ground. A loop is usually a wrong model of the code rather than a wrong edit, and no number of edits fixes that.
Feature recommended in
Implement
Build Engineer
Task bigger than planned Drop out of writing and re-read the ground before re-cutting the work.
Agent Session Claude Code 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.
Explore Subagent Claude Code 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.
/test-from-criteria Claude Code 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.
Refs skills/test-from-criteria /test-from-repro Claude Code test authoring skill
Turns a reproduction into a regression test that fails before the fix.
Turns a reproduction into a test, written before the fix, that fails
on the current code.
The order is the whole point. A test written after the fix proves the fix
compiles. A test that failed first, and passes now, proves the fix
addressed the bug that was reported.
Where the human stands
delegated-review. The check is mechanical and the agent cannot argue
past it: red before, green after, or the work is not done.
/evidence-block Claude Code 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.
/address-verdict Claude Code 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 Feature recommended in
Implement
Build Engineer
Rework requested Work the verdict item by item. Rework is not a loop in the flow — it is a moment here, with a play attached.
/bisect Claude Code history search skill
Searches history for the change that introduced the behaviour.
Searches the history for the commit where the behaviour changed, by
running the reproduction against successive revisions.
It needs a reliable reproduction to be worth anything. Against an
intermittent failure it finds the commit where the failure happened to
show up, which is not the same claim and is more convincing than it should
be.
Where the human stands
assisted. The search is mechanical, but reading the guilty commit and
deciding whether it is the cause or merely the trigger is the diagnosis,
and that is the work.
Reached for Bugfix recommended in
Reproduce
Diagnose Engineer
Cannot reproduce Let history say when the behaviour changed — the first good build is a reproduction recipe when the report is not one.
/postmortem Claude Code incident writeup skill
Drafts the timeline from the incident record while detail is recoverable.
Drafts the timeline from what the incident actually left behind — pages,
messages, deploys, dashboards — while the detail is still recoverable.
Why the timing matters
A timeline assembled a week later is assembled from memory, and memory
arranges events so that the eventual cause looks like it was visible from
the start. The record does not do that.
Where the human stands
assisted. The draft is a timeline. Deciding what the incident means —
which contributing factors are worth a follow-up and which are noise — is
the postmortem, and no draft settles it.
/code-review Claude Code 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.
CLAUDE.md Claude Code 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 Feature recommended in
Review Conformance MANUAL
Verify Reviewer
Verdict is about a class, not a change 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 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 Feature recommended in
Review Conformance MANUAL
Verify Reviewer
Verdict is about a class, not a change 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 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.
Completion Hook Claude Code 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.
Completion Condition Claude Code 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.
Session Reset Claude Code 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 Bugfix recommended in
Apply Fix MANUAL
Fix Engineer
Same failure survives correction After the second failed correction, stop and start over with an opening that includes what the failures taught. A third correction is read against both earlier ones, which is why the third rarely works.
Feature recommended in
Implement MANUAL
Build Engineer
Context is full 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 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.
Permission Rules Claude Code 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 Feature recommended in
Edit + Test Loop MANUAL
Engineer
Approving without reading Pre-approve the commands already being approved without reading, so the prompts that remain are the ones worth stopping for.
Sandboxed Session Claude Code 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 Feature recommended in
Edit + Test Loop ASSISTED
Engineer
Approving without reading 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 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 Feature recommended in
Implement ASSISTED
Build Engineer
Work splits into independent units Separate checkouts so parallel edits cannot collide. Deciding which pieces are genuinely independent stays the engineer's call.
Orchestrated Fan-Out Claude Code 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.
Agent Team Claude Code 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 Feature recommended in
Implement ASSISTED
Build Engineer
Work splits into independent units 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 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 Feature recommended in
Implement ASSISTED
Build Engineer
Context is full 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 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.
Structured Result Claude Code 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.
Mention on the Thread GitHub Actions event-triggered agent
Answers on the issue or pull request where the work is already discussed.
Answers where the conversation is already happening: mentioned on an issue
or a pull request, it replies on that thread and can push changes to it.
The value is placement as much as capability. The answer lands next to the
question, in the record someone will read in a year when they ask why the
change looks like this.
Where the human stands
delegated-review. It can answer a report; deciding the report is work
remains a triage decision.
Automated PR Review GitHub Actions 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.
Backlog Triage Agent Jira + Rovo 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 Feature recommended in
Write Spec
Define Product Lead
Pull what the backlog already knows, so the spec starts from it.
Follow-Up Agent Jira + Rovo rovo agent
Turns agreed actions into tracked work with owners.
Turns the actions a review or a postmortem agreed on into tracked issues,
each with an owner, so the agreement survives the meeting that produced
it.
Where the human stands
delegated-review. Creating the issues is clerical. Assigning them is
not — an owner who did not agree to be one is a ticket that ages, and the
document would rather show an unassigned action than a fictional one.
Release Gate CI Pipeline 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.
Reached for Feature fills the slot in
Ship GATED AUTO
Ship Release Operator
Alert Routing Observability Stack paging rule
Puts a page in front of an owner and starts the clock.
Matches a firing alert to whoever is on call for it, pages them, and
starts the clock the response is measured against.
Where the human stands
gated-autonomous. The rule fires on its own, at three in the morning,
with nobody to approve it — which is the entire reason it exists. The
roster it routes against is reviewed by people, not generated.
Signal Correlation Observability Stack query agent
Reads metrics, logs, and traces together to say who is affected.
Reads metrics, logs and traces together and answers the question the first
minutes of an incident turn on: who is affected, and how many of them.
What it cannot do
It bounds the blast radius from what the signals cover. Traffic that never
reached the failing component, or a dependency nobody instrumented, is
invisible to it — and invisible reads as unaffected. When the dashboards
will not say, reading the code for who calls the failing component gives a
bound the signals cannot.
Where the human stands
delegated-review. The correlation is fast and usually right; the
incident lead owns the impact statement, because that is what gets
communicated.
Recovery Check Observability Stack signal check
Confirms the same signal that paged has gone quiet, and stayed quiet.
Watches the signal that paged, and confirms it has gone quiet and stayed
quiet for long enough that the quiet means something.
Same signal, deliberately. An incident closed on a different metric than
the one that opened it is closed on a change of subject.
Where the human stands
delegated-review. The check is mechanical. Whether the service has
recovered or merely stopped being asked — a quiet caused by traffic that
gave up rather than by a fix — is a judgment the responder makes.
Spec ARTIFACT spec
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.
Work Plan ARTIFACT work-plan
The route from spec to change: the order of the work, what it touches, and
what has to be true before it starts.
Acceptance Criteria ARTIFACT acceptance-criteria
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.
Task List ARTIFACT task-list
The spec cut into pieces small enough that one of them can be finished,
reviewed, and shipped without holding the rest in your head.
Context Notes ARTIFACT context-notes
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.
Draft Change ARTIFACT draft-change
The change while it is still being argued with — compiling, incomplete, and
not yet asking anyone for judgment.
Change Set ARTIFACT change-set
The change offered for review: the diff, its tests, and nothing left in it
that its author would not defend.
Test Suite ARTIFACT test-suite
The executable statement of what must keep working. It is the evidence the
rest of the process quotes.
Evidence Pack ARTIFACT evidence-pack
What proves the change does what it claims: test runs, checks, and the
output a reviewer would otherwise have to reproduce by hand.
Review Verdict ARTIFACT review-verdict
The reviewer's decision on conformance — the change matches the intent, or
it does not and here is where.
Release Candidate ARTIFACT release-candidate
A change set that has passed review and is packaged for production, waiting
only on the decision to go.
Release ARTIFACT release
The change in production, with the record of when it went and what it
contained.
Bug Report ARTIFACT bug-report
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.
Reproduction ARTIFACT reproduction
The steps that make the bug happen on demand. Until this exists, the root
cause is a hypothesis and any fix is a guess.
Root Cause ARTIFACT root-cause
The mechanism that produced the bug, stated deeply enough that the fix is
obvious and the class of bug — not the instance — is closed.
Regression Test ARTIFACT regression-test
The test that fails on the old code and passes on the new one. It is what
turns a fix into a guarantee.
Incident Record ARTIFACT incident-record
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.
Impact Assessment ARTIFACT impact-assessment
Who is affected and how badly. Severity is set from this, and every
communication downstream quotes it.
Status Update ARTIFACT status-update
What people outside the response need to know right now: current state,
what is being done, and when the next update comes.
Mitigation ARTIFACT mitigation
The action that stops the harm. It is not the fix — a mitigation that is
mistaken for one leaves the cause in place.
Postmortem ARTIFACT postmortem
The account written after the incident closes: what happened, why the system
allowed it, and what changes so the next one is smaller.
Follow-Up Work ARTIFACT follow-up-work
The commitments a postmortem makes, handed back to the delivery process as
real work rather than as good intentions.
Task bigger than planned EVENT task-too-big
Mid-task the work turns out larger than its plan — stop and re-decompose before pushing on.
Spec is ambiguous EVENT spec-ambiguous
Two readings of the spec survive contact with the work.
Rework requested EVENT rework-requested
The review verdict comes back with required changes.
Cannot reproduce EVENT cannot-reproduce
The report does not reproduce on demand — the bug is a hypothesis until it does.
Blast radius unknown EVENT impact-unbounded
The signals do not yet say who is affected or how badly — severity cannot be set.
Mitigation does not hold EVENT mitigation-fails
The service recovers and degrades again — the mitigation treated a symptom.
Context is full EVENT context-exhausted
The session has read more than it can hold, and decisions made earlier stop being honoured.
Same failure survives correction EVENT agent-loops
Two corrections in, the same thing is still wrong, and the history is now mostly failed approaches.
No check to run EVENT nothing-can-check-it
The work looks done and nothing in the repository produces a pass or a fail on it.
Question has no edges EVENT investigation-unbounded
A question was asked without a boundary, and the reading it needs has no natural end.
Verdict is about a class, not a change EVENT review-finds-a-pattern
The finding would apply to the next change too — it is a rule, not a defect.
Work splits into independent units EVENT work-is-parallel
The task is many similar pieces that do not depend on each other.
Approving without reading EVENT prompts-pile-up
Enough permission prompts have gone by that clicking has replaced reading.
Open Slots 4 DECLARED
Work this team has decided to hand to a tool and has not yet. Each one names what
it needs, in the team's own words.
Waiting on Bugfix declared in
Reproduce
Diagnose Engineer
Something that turns a report into a runnable case — the environment, the data and the steps, standing up on demand. Today every reproduction is rebuilt by hand from whatever the reporter remembered.
Incident declared in
Communicate Status
Assess Product Lead
A draft status update written off the impact assessment, ready for the lead to correct and send. The cost here is not writing the words, it is that whoever writes them is not working the incident.
Bugfix 1 OPEN ALL PROCESSES
Waiting on Bugfix declared in
Reproduce
Diagnose Engineer
Something that turns a report into a runnable case — the environment, the data and the steps, standing up on demand. Today every reproduction is rebuilt by hand from whatever the reporter remembered.
Feature 2 OPEN ALL PROCESSES
Incident 1 OPEN ALL PROCESSES
Waiting on Incident declared in
Communicate Status
Assess Product Lead
A draft status update written off the impact assessment, ready for the lead to correct and send. The cost here is not writing the words, it is that whoever writes them is not working the incident.