# Reviewer Protocol

Reviewer rejection workflow and strict lockout semantics

- Repository: https://github.com/microsoft/waza (1496 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-10-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add microsoft/waza --skill reviewer-protocol -g -a claude-code -y`
Codex: `npx skills add microsoft/waza --skill reviewer-protocol -g -a codex -y`
Cursor: `npx skills add microsoft/waza --skill reviewer-protocol -g -a cursor -y`
Gemini CLI: `npx skills add microsoft/waza --skill reviewer-protocol -g -a gemini-cli -y`

## Description

Reviewer rejection workflow and strict lockout semantics

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

## 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:
  1. **Reassign:** Require a *different* agent to do the revision (not the original author).
  2. **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 rest: https://github.com/microsoft/waza/blob/HEAD/.github/skills/reviewer-protocol/SKILL.md