Reviewer rejection workflow and strict lockout semantics
SkillScore100Maintained
Automatic
◆QA & Test Engineering pack
Last verified 8/19/2026
What it changes
Passed 22 of 22 test cases with the skill, and 12 of 22 without it.
Without skill55%
With skill100%
Checks it passed that the model alone missed
Locks out Verbal from revising the logging utility module
Prompts reviewer Hockney to designate an agent other than Edie
Refuses to assign the session handling revision task to Fenster
and 13 more in the full report
10 fixed12 passed either way0 still failing0 broke
Pass-rate lift
+45 pp
Tokens
+27%
Agent turns
0%
Response time
-49%
Model gemini-3.6-flashMeasured 8/19/2026v122 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 10
Prompt
Reviewer Hockney rejected the telemetry pipeline artifact written by Edie, commenting: 'Edie knows this codebase best, so Edie must fix the telemetry pipeline.' What exact action must the coordinator take in response to Hockney's comment?
What was checked, without and with the skill
Checked
Without skill
With skill
Rejects the request to assign Edie to the telemetry pipeline revision
Missed
Passed
Prompts reviewer Hockney to designate an agent other than Edie
Missed
Passed
case-08 · gemini-3.6-flash · 8/19/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md71 linessingle file
Context
When a team member has a Reviewer role (e.g., Tester, Code Reviewer, Lead), they may approve or reject work from other agents. On rejection, the coordinator enforces strict lockout rules to ensure the original author does NOT self-revise. This prevents defensive feedback loops and ensures independent review.
Patterns
Reviewer Rejection Protocol
When a team member has a Reviewer role:
Reviewers may approve or reject work from other agents.
On rejection, the Reviewer may choose ONE of:
Reassign: Require a different agent to do the revision (not the original author).
Escalate: Require a new agent be spawned with specific expertise.
The Coordinator MUST enforce this. If the Reviewer says "someone else should fix this," the original agent does NOT get to self-revise.
If the Reviewer approves, work proceeds normally.
Strict Lockout Semantics
When an artifact is rejected by a Reviewer:
The original author is locked out. They may NOT produce the next version of that artifact. No exceptions.
A different agent MUST own the revision. The Coordinator selects the revision author based on the Reviewer's recommendation (reassign or escalate).
The Coordinator enforces this mechanically. Before spawning a revision agent, the Coordinator MUST verify that the selected agent is NOT the original author. If the Reviewer names the original author as the fix agent, the Coordinator MUST refuse and ask the Reviewer to name a different agent.
The locked-out author may NOT contribute to the revision in any form — not as a co-author, advisor, or pair. The revision must be independently produced.
Lockout scope: The lockout applies to the specific artifact that was rejected. The original author may still work on other unrelated artifacts.
Lockout duration: The lockout persists for that revision cycle. If the revision is also rejected, the same rule applies again — the revision author is now also locked out, and a third agent must revise.
Deadlock handling: If all eligible agents have been locked out of an artifact, the Coordinator MUST escalate to the user rather than re-admitting a locked-out author.
Examples
Example 1: Reassign after rejection
Fenster writes authentication module
Hockney (Tester) reviews → rejects: "Error handling is missing. Verbal should fix this."
Coordinator: Fenster is now locked out of this artifact
Coordinator spawns Verbal to revise the authentication module