Worker-Reviewer Pipeline Skill

Defines an iterative Worker→Reviewer pipeline where one agent implements changes and another reviews them. The cycle repeats until quality criteria are met or max iterations reached.

Orchestrator-only — only the main conversation activates this pipeline (R010). Worker and Reviewer are subagents.

When to Activate

Condition	Activate?
Quality-critical code changes (auth, security, payments)	Yes
Complex refactoring touching 5+ files	Yes
User explicitly requests review cycle	Yes
Simple file edits, config changes	No
Documentation-only changes	No

Pipeline Spec Format

pipeline:
  name: feature-review
  description: Implement and review a feature

worker:
  agent: lang-typescript-expert    # or appropriate specialist
  model: sonnet
  prompt: "Implement the feature based on requirements"

reviewer:
  agent: lang-typescript-expert    # can be same or different specialist
  model: opus                      # often higher model for review
  prompt: "Review implementation for correctness, security, performance"

config:
  max_iterations: 3          # Max review cycles (default: 3)
  quality_gate: all_pass     # all_pass | majority_pass | custom
  auto_commit: false         # Auto-commit on quality pass (via mgr-gitnerd)

Execution Flow

1. Orchestrator activates pipeline
2. Worker agent implements changes
3. Reviewer agent reviews Worker's output
4. Reviewer produces verdict:
   - PASS → Pipeline complete, proceed to next step
   - FAIL(issues) → Worker receives feedback, re-implements
5. Repeat 3-4 until PASS or max_iterations reached
6. If max_iterations reached without PASS:
   - Report partial results to user
   - Recommend manual review

Review Verdict Format

Reviewer MUST output a structured verdict:

[Review Verdict]
├── Status: PASS | FAIL
├── Iteration: {n}/{max}
├── Issues Found: {count}
│   ├── [Critical] {description} — {file:line}
│   ├── [Major] {description} — {file:line}
│   └── [Minor] {description} — {file:line}
└── Summary: {one-line}

Quality Gates

Gate	Criteria
all_pass	Zero Critical or Major issues (default)
majority_pass	Zero Critical, ≤2 Minor issues allowed
custom	User-defined in pipeline spec

Integration with Agent Teams (R018)

When Agent Teams is enabled, the pipeline SHOULD use Agent Teams:

TeamCreate("review-pipeline")
  Worker (team member) ←→ Reviewer (team member)
  SendMessage for feedback exchange
  Shared TaskList for tracking issues

When Agent Teams is NOT available, falls back to sequential Agent tool calls:

Agent(worker) → result → Agent(reviewer) → verdict → Agent(worker) → ...

Stopping Criteria Display

Before execution, display:

[Worker-Reviewer Pipeline]
├── Max iterations: {max_iterations} (default: 3, hard cap: 5)
├── Quality gate: {pass_threshold}% approval required
└── Early stop: All reviewers approve → stop immediately

Display Format

[Pipeline] feature-review — Worker: lang-typescript-expert, Reviewer: lang-typescript-expert
[Iteration 1/3] Worker implementing...
[Iteration 1/3] Reviewer reviewing...
[Review] FAIL — 2 issues (1 Major, 1 Minor)
[Iteration 2/3] Worker fixing issues...
[Iteration 2/3] Reviewer re-reviewing...
[Review] PASS — 0 issues
[Pipeline Complete] 2 iterations, quality gate passed

Common Pipeline Templates

Security-Critical Feature

worker: {agent: lang-typescript-expert, model: sonnet}
reviewer: {agent: lang-typescript-expert, model: opus}
config: {max_iterations: 3, quality_gate: all_pass}

Cross-Language Integration

worker: {agent: lang-golang-expert, model: sonnet}
reviewer: {agent: be-go-backend-expert, model: opus}
config: {max_iterations: 2, quality_gate: all_pass}

Quick Review

worker: {agent: lang-python-expert, model: sonnet}
reviewer: {agent: lang-python-expert, model: sonnet}
config: {max_iterations: 1, quality_gate: majority_pass}

Integration

Rule	Integration
R009	Worker and Reviewer can run in parallel with other pipelines
R010	Pipeline orchestration runs only in main conversation
R015	Display pipeline plan and review verdicts transparently
R018	Agent Teams preferred when available for Worker↔Reviewer messaging
pipeline-guards	Max iterations and timeout enforced by pipeline-guards
model-escalation	Worker failures feed into escalation tracking
stuck-recovery	Repeated FAIL verdicts trigger stuck detection advisory

Limitations

• Max 3 iterations by default (configurable, hard cap at 5 via pipeline-guards)
• Worker and Reviewer must be different agent instances (same type allowed)
• Nested pipelines not supported (use dag-orchestration for complex flows)
• Pipeline does not auto-commit; orchestrator decides post-pipeline actions

When spawning agents via the Agent tool during this skill's execution, always pass mode: "bypassPermissions". The Agent tool default (acceptEdits) overrides agent frontmatter permissionMode, causing permission prompts during unattended execution.