What problem does it solve?
The Reviewer Rejection Protocol establishes clear rules to prevent the original author from re-editing work after a rejection, ensuring that revisions are produced by a different agent or a newly escalated expert.
Core Features & Use Cases
- Reviewer Rejection Protocol: Reviewers can approve or reject work; on rejection, they can require a different agent to revise or escalate to bring in fresh expertise. The Coordinator enforces that the original author does not revise the artifact.
- Strict Lockout Semantics: After a rejection, the original author is prevented from contributing to the revision; a non-original author must own the next iteration, and there are safeguards to avoid naming the original author as the fix agent.
- Use Cases: Reassign after rejection to a different engineer, escalate to a new expert for critical gaps, and handle deadlocks by escalation when all eligible agents are locked out.
Quick Start
Upon reviewing, if you reject, require a different agent to revise (not the original author) or escalate and ensure the original author is locked out for the upcoming revision.