Reviewer Protocol
Reviewer rejection workflow and strict lockout semantics
Install
npx skills add microsoft/waza --skill reviewer-protocol -g -a claude-code -y- Repository
- microsoft/waza1.5k
- Category
- Engineering
- Updated
- 4d ago
- License
- MIT
- Context cost
- Lightabout 1,356 tokens
- Runs scripts
- No, instructions only
What it does
Reviewer rejection workflow and strict lockout semantics
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
Quality and test reviewers may block a PR or merge on quality, coverage, or regression grounds. Treat that block as a rejection that enters the protocol below.
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:
