How to Invoke Reviewer Agents
Version: 1.5.2 Date: 2026-01-22 Status: Production Ready
Step-by-step guide to requesting peer reviews from reviewer agents.
Prerequisites: Familiarity with Task tool and wave workflows.
Related: Reviewer Agents Reference
Quick Start
Request a review via the Task tool:
Use Task tool:
subagent_type: general-purpose
prompt: Read ~/.claude/agents/nw/nw-{reviewer-name}.md
Review docs/feature/{feature-id}/{wave}/{artifact}.md
Return YAML: strengths, issues, recommendations, approval_status
Method 1: Task Tool Invocation
The primary method to invoke reviewers.
Step 1: Identify Reviewer
Match your artifact type to the reviewer:
| Artifact Type | Reviewer to Use |
|---|---|
| Requirements | product-owner-reviewer |
| Architecture | solution-architect-reviewer |
| Acceptance tests | acceptance-designer-reviewer |
| Implementation | software-crafter-reviewer |
Step 2: Invoke via Task Tool
<Task>
subagent_type: general-purpose
description: Invoke {reviewer-name}
prompt: |
You are the {reviewer-name} agent.
Read the complete agent specification from:
~/.claude/agents/nw/nw-{reviewer-name}.md
Review the artifact at:
{path-to-artifact}
Conduct peer review following the specification.
Provide structured YAML feedback:
- strengths
- issues_identified (with severity)
- recommendations
- approval_status
</Task>
Step 3: Interpret Feedback
The reviewer returns YAML:
approval_status: "rejected_pending_revisions"
issues_identified:
confirmation_bias:
- issue: "Technology assumption without rationale"
severity: "critical"
recommendation: "Re-elicit constraints"
Actions by status:
approved-> Proceed to handoffrejected_pending_revisions-> Address issues, resubmitconditionally_approved-> Proceed with documented caveats
Method 2: Interactive Review
Request persona activation in the chat:
Read ~/.claude/agents/nw/nw-{reviewer-name}.md and activate as the {reviewer-name} agent.
Review the artifact at {path-to-artifact}
Provide conversational feedback on:
1. Completeness
2. Consistency
3. Quality issues
4. Approval recommendation
Method 3: Add Review Steps to Workflows
Add review steps to wave workflows.
After DISCUSS wave
1. Create requirements (product-owner)
2. Review requirements (product-owner-reviewer) <- Add this step
3. Proceed to DESIGN
After DISTILL wave
1. Create acceptance tests (acceptance-designer)
2. Review tests (acceptance-designer-reviewer) <- Add this step
3. Proceed to DELIVER
Revision Workflow
When reviewer returns rejected_pending_revisions:
Step 1: Address Critical/High Issues
Focus on critical and high severity issues first:
issues_identified:
confirmation_bias:
- issue: "AWS assumption without requirement"
severity: "critical" # <- Fix this first
Step 2: Revise Artifact
Update your artifact to address the issues.
Step 3: Resubmit for Review
The artifact has been revised. Please re-review:
{path-to-revised-artifact}
Issues addressed:
- Removed AWS assumption, added deployment constraints section
- Quantified performance requirements (2s p95)
Step 4: Await Approval
The reviewer validates revisions and returns updated status.
Iteration limit: Maximum 2 iterations. If not approved after 2 iterations, escalate to human facilitator.
Troubleshooting
| Issue | Solution |
|---|---|
| Reviewer not found | Use Task tool with full spec path: Read ~/.claude/agents/nw/nw-{reviewer-name}.md |
| No structured feedback | Explicitly request YAML with: approval_status, issues_identified (with severity), recommendations |
| Review too lengthy | Scope it: "Focus only on: 1) confirmation bias, 2) completeness gaps, 3) testability. Skip style/formatting." |
Examples
Example: Requirements Review
I need peer review on my requirements document.
<Task>
subagent_type: general-purpose
description: Requirements peer review
prompt: |
You are the product-owner-reviewer persona.
Read: ~/.claude/agents/nw/nw-product-owner-reviewer.md
Review: docs/feature/{feature-id}/discuss/checkout-requirements.md
Focus on:
1. Confirmation bias (technology assumptions)
2. Completeness (missing scenarios/stakeholders)
3. Clarity (vague requirements)
4. Testability (measurable acceptance criteria)
Provide YAML feedback with approval_status.
</Task>
Example: Acceptance Test Review
Please review my acceptance tests for happy path bias.
<Task>
subagent_type: general-purpose
description: Acceptance test review
prompt: |
You are the acceptance-designer-reviewer persona.
Read: ~/.claude/agents/nw/nw-acceptance-designer-reviewer.md
Review: tests/acceptance/features/checkout.feature
Focus on:
1. Happy path bias (error scenario coverage)
2. GWT format compliance
3. Business language purity
4. Coverage completeness
Provide YAML feedback with approval_status.
</Task>
Example: Architecture Review
Review my architecture design for feasibility.
<Task>
subagent_type: general-purpose
description: Architecture peer review
prompt: |
You are the solution-architect-reviewer persona.
Read: ~/.claude/agents/nw/nw-solution-architect-reviewer.md
Review: docs/feature/{feature-id}/design/architecture-design.md
Focus on:
1. Architectural bias (premature technology choices)
2. ADR quality (complete decision records)
3. Feasibility (implementation viability)
4. Testability (component boundaries)
Provide YAML feedback with approval_status.
</Task>