The last article's sharpest line was a boundary:
The readiness reviewer may only record what the sources already say; the analyst may additionally choose among what the sources permit; neither may invent what the sources don't cover.
Three authorities, one line. The tiers keep them apart. (Missed Part 5? The tiers are about who's allowed to decide what.)
That has a consequence. If the reviewer has far less authority than the analyst, they can't be the same person — not as best practice, but as a basic requirement for the workflow to work.
Everyone has heard "don't mark your own homework" at least once — usually from someone who was absolutely marking their own homework. For some teams it's a nicety. For an agentic team, it's the entire point of the readiness gate. The homework must be marked by someone other than its owner.
A requirement, not a nicety: Independent memory
Peer review exists because fresh eyes catch what authors smooth over. The same applies to agents, with higher stakes.
When an author-agent hits a small ambiguity during refinement, it resolves it. It reads the description, spots a phrase that could mean two things, picks one because the codebase already answered that question, and moves on. That's the job — the agent is doing the reader-work a human would have done, but it leaves no trace. (Part 5 called these tier-1 calls.)
Here’s the subtle trap: "the codebase already answered that question" and "I resolved this one in my head" look identical from inside the same agent. No internal flag, no moment of hesitation. The resolution and the reading of it are the same act.
A separate auditor can catch this because it didn't do the resolving. Either the ambiguity is settled in the item — written down and checkable — or it isn't, and the analyst has quietly decided something that isn't there. The auditor's job is to notice, not to fix: it may add what the sources already establish, but it never closes a gap by deciding it.
That's the bit that matters: independence of memory. An agent that wrote the spec has already resolved the ambiguity; only a fresh agent can see it still standing.
Marking someone else's homework
Think of it like handing a brief from one team member to another before it goes to a client. The analyst who wrote it doesn't get to sign it off — that's a different person, with a different checklist and fresh eyes.
In this project that's two roles with two skill files. jira-refinement shapes the item; jira-readiness, judging against definition-of-ready and design-fit-check, audits it. Separate pickup, separate instructions, and a narrower remit: the reviewer may only record what the sources already say.
Different roles aren't the same as different agents. Nothing in that stops one agent session refining an item, handing it off, and then picking it up again as the reviewer. Different instructions, same head. The paper trail would look perfectly well-formed, produced by the one party who can't do the check.
One thing to be straight about: Jira can't fully stop this. Within a single tool, nothing in Jira can say "this session is the analyst, that one is the reviewer."
A note on accounts: the project does run two service accounts, split by tool. Claude Code CLI works under one and GitHub Copilot CLI under the other, so their work is already told apart in Jira. Going finer, one account per agent, would give Jira something to enforce. It also means more accounts to manage, more API keys to issue and rotate, and a constant risk of an agent running under the wrong one. We've kept the split at the tool level and let the session name do the rest.
So we make the session check itself. Each session gets a name with a short code on the end (Bulbasaur (7f3a1c9d)) and signs every comment with it. The name is for humans; the code is what tells two sessions with the same name apart. Before picking up a readiness check or a code review, the agent runs a small script that looks at who signed the earlier work (refinement for readiness, development for review). If its own name and code are there, it stops. If it can't tell — no code on its name, or an unsigned comment — it says so instead of carrying on.
That isn't a lock. The agent has to run the script, and nothing forces it to. It rules out one specific mistake: the author auditing themselves. Where a control can't be mechanical, leave a trail someone can check.
The verdict you always leave out
The natural instinct is to give the readiness reviewer two outcomes: READY and NOT READY. That's not enough. The workflow needs three:
Readiness: READY. The item is worth handing to development. All four checks pass and nothing is left open. Fire Handoff for development.Readiness: NOT READY. The audit found gaps — open questions, missing acceptance criteria, an item that can't stand alone, a design that doesn't fit. Fire Submit for refinement, and it goes back to the analyst's queue.Readiness: NOT ASSESSED. The audit couldn't be done — a linked issue was inaccessible, a tool broke. Fire Queue for readiness evaluation, and the item goes back on the reviewer's own queue for another attempt.
The third outcome is the one people leave out. Without it, an agent that can't finish an audit has three bad choices: pretend it could, pretend it couldn't and write a NOT READY for the wrong reasons, or fail silently. All three corrupt the workflow's signals in slightly different ways, which is almost impressive. NOT ASSESSED is honest and self-repairing: the item hasn't moved, and the trail says "we tried, we couldn't, here's why."
A verdict you can't substantiate is worse than no verdict. It looks the same to the reader, and they'll trust it — including the development agent that reads Readiness: READY on its way to opening a PR. It will not squint at it suspiciously. It will open the PR.
What the readiness comment carries
The reviewer's comment isn't just a verdict; it's the evidence for it. Each phase has its own required sections (the next article covers that grammar in full). The readiness comment has six. Here's what each one is for:
- Understood — what the item asks for, and whether each acceptance criterion can be checked.
- Standalone — can it be built without something else landing first?
- Design fit — where the change lands, and any deviation that needs a human decision.
- Sized — one coherent change, or the split the reviewer proposes.
- Still open — the numbered questions the item hasn't answered.
- What I could not verify — everything the reviewer couldn't check for itself.
(If the reviewer edited the item on its way past, a Changes I made section records each edit.)
The last two matter most here, because they're where an author is weakest at describing its own work. The analyst writes both too, but its lists hold only the unknowns it noticed. The ambiguities it settled in its own head aren't on them, because it no longer experiences them as questions. It did not hit a wall; it just stopped. The reviewer's lists come from the item as it arrived, written by someone who didn't do the resolving.
What I could not verify is never boilerplate. By the time an item reaches a human, it has been through four stages — refine, readiness, build, review — each ending in a confident verdict. A stack of confident verdicts with no honest list of what each stage couldn't check can talk the last person into skimming. Still open works differently: it's written to be acted on. Each question can be answered directly, and says who's likely to answer it.
When the reviewer says no
The point of the three verdicts, the structured comment and the separate pickup is that when the audit finds a problem, the workflow routes it correctly by itself. NOT READY doesn't park the item; it fires Submit for refinement, and the item lands in Awaiting Refinement, which is the analyst's queue.
In practice: the reviewer posts a NOT READY with three numbered questions. The analyst's next pickup already contains them — not advice, the work list. The analyst answers them, updates the item and fires Handoff for readiness evaluation again. No human reschedules anything. In a workflow where "not ready" is just a label someone has to notice, those questions are advice, and advice gets ignored. Here, the reviewer's NOT READY is the analyst's next task, and the analyst's handoff is the reviewer's next task. They don't converse; they hand each other structured artefacts, and the item's status carries the handoff.
Compare what you get without the separation. An analyst-that-is-also-reviewer would finish refining and ask itself whether it was ready. Almost always yes — because the ambiguities it silently resolved are, from its perspective, resolved. It isn't cutting corners; a NOT READY is simply out of reach from inside the head that wrote the spec. The workflow would advance every item, and the readiness gate would be a formality. A well-labelled, carefully implemented, completely decorative formality.
Which is why the readiness reviewer's own file says, in its verdict rule — the section that tells it how to decide:
You are not permitted to pass your own homework.
The line is there because the reviewer is allowed to improve the item on its way past — tidy a criterion, name the files the change will touch. Without it, an agent could fix the very gap that should have failed the item, then approve what it had just written. So the rule is: judge the item as it arrived, plus what you could work out from the sources; never as you left it. Where improvement ends and fixing the gap begins is, admittedly, a judgement call, and the agent can't always tell from the inside. That's why the instruction has to be explicit: its edits can make the item tidier, but they can't turn a NOT READY into a READY.
What changes when it's code
The same shape turns up one pair later, but not every part carries over. The developer builds against the acceptance criteria; the code reviewer audits the PR against the same criteria. Different pickups, different skills, different memories — and the same identity check, this time looking for the developer's signature rather than the analyst's.
What carries over is the rule about gaps. The acceptance criteria never pin everything down, so the developer meets gaps and handles them as the analyst does. If an established convention or a shipped sibling gives a defensible answer, it makes the call and records it under Deviations. If nothing does, it stops with Development: SPEC WRONG rather than guessing. The code reviewer checks what the diff and the criteria establish, and whether the developer was entitled to answer what it answered. Same silent calls as before; they just live in code instead of a spec.
What doesn't carry over is the rest of the readiness reviewer's toolkit. The readiness reviewer may improve the item on its way past, and logs it under Changes I made. The code reviewer may not: no code, no commits, no edits to the acceptance criteria — findings only, because a reviewer who fixes becomes the author and reviews its own work on the next pass. And the homework line is a readiness line. The code reviewer gets its independence from reading order: criteria and diff first, the developer's completion comment last, treated as a claim to audit, never as input.
Here's the whole comparison side by side:
| Refinement → readiness | Development → code review |
|---|
Silent calls live in | The spec | The code |
Determinable calls are recorded in | Decisions | Deviations |
A reserved gap becomes | Refinement: NEEDS DECISION | Development: SPEC WRONG |
The auditor may edit | Derivable additions, logged under Changes I made | Nothing — findings only |
Independence comes from | The verdict rule: judge the item as it arrived | Reading order: criteria and diff first, completion comment last |
Verdicts | Three | Four |
Every phase ends one of three ways (a rule from article 4): forward, back, or re-queue untouched. What varies is how many places "back" can go. The readiness reviewer has one: the analyst. The code reviewer has two: the developer, if the code is wrong, or the analyst, if the specification is. So the code reviewer needs four verdicts to cover three kinds of outcome:
Review: APPROVED — the code implements the acceptance criteria; the PR is fit to merge. Fire the forward transition.Review: CHANGES REQUESTED — the code doesn't meet the criteria; the specification stands. Fire Return for development, and the findings become the developer's next work list.Review: SPEC WRONG — the criteria were wrong or impossible; the code may be perfect against the wrong target. Fire Submit for refinement. The PR stays open as prior art for the eventual re-implementation.Review: NOT REVIEWED — the review couldn't be done. Same shape as NOT ASSESSED; each phase names its own.
That SPEC WRONG outcome is worth sitting with for a moment. It says the implementation is fine, the spec was wrong, and we need to go back further. An author-reviewer would never reach it honestly — reaching it means concluding the earlier work was mistaken, and the alternative is just… continuing. Rewrite the spec, re-approve, move on. Nobody has to know. The four-verdict shape only works because the two roles are different agents.
Try this before the next article
Take one role on your team's board where the same person or agent both authors and approves: the ticket author who marks it ready, the developer who approves their own PR because the reviewer is on holiday, the refinement agent that also runs the readiness check. Now write three things down:
- What ambiguity does the author-approver silently resolve? Look at the last three items or PRs that went through the collapsed role and find one thing the author decided in their head that never got written down.
- Which of the audit outcomes would this role ever plausibly reach? If the answer is "only the forward one," the role's audit function is decorative. If it includes a genuine "back" — not ready, changes requested, spec wrong — then either the current arrangement is producing honest self-audits (in which case, terrific — and genuinely, how?), or the workflow is relying on nobody looking too closely.
- How would you know the author and the approver were different? Not whether they have different titles. Whether anything in your trail would show it if they weren't.
The move — the one this project makes and the one the whole article is arguing for — is to split the role. Whoever writes the spec doesn't approve it; whoever writes the code doesn't review it. It's the oldest rule in software engineering — we just keep calling it hygiene when it's actually load-bearing.
Next: Documentation as a contract. Marker comments, description zones, and the acceptance-criteria field — why for an agentic team some comments stop being conversation and become load-bearing state, and how the grammar has to be treated as protocol.
Every idea in my writing comes from real work — built, broken, and figured out before a single word is written. The writing is documentation, not speculation. I start with voice dictation: a raw thought dump of ideas, objectives, and what I've actually been working on. From there, I collaborate with AI to shape that into something readable — structuring drafts and editing through a custom Rovo agent, configured with carefully curated instructions to review and refine work against my preferences, personality, and style. Artwork is a separate creative process — concepts originate from my own ideas and are brought to life using a combination of Google Gemini, ChatGPT, and Photoshop. The ideas, the experience, the creative direction — those are mine. AI is how I move fast and bring them to life.
Before anything is published, every claim and every idea goes through multiple review cycles to make sure it accurately reflects the thoughts and experience I originally set out to convey. If something reads well, that's the process working. If something doesn't, that's on me.
