review-pipeline

name	review-pipeline
description	Use when you want review AND automated fixes in one pass, when /review-dispatch alone would leave findings unaddressed, or before merging a feature branch that needs thorough diagnosis and remediation. Two-phase diagnose-then-fix pipeline.
user-invocable	true

Review Pipeline

Two-phase review team: diagnose issues from multiple perspectives, then systematically fix approved findings.

Simplicity principle (MANDATORY): Every review pass MUST treat complexity reduction as a first-class review dimension, not a nice-to-have. Apply the /reduce-complexity framework: distinguish essential complexity (domain-inherent) from accidental (reducible). Flag accidental complexity introduced by the diff as High severity. Phase 2 fixes must prefer simplification over patching — always look for deletion opportunities before adding code.

When to Use

• Before merging a feature branch
• After completing a significant implementation step
• When you want a thorough review AND fixes in one pass
• When /review-dispatch or /ce:review alone would leave findings unaddressed

Invocation

/review-pipeline [<target>]

• No argument: review unstaged changes in the working tree (git diff)
• File path or glob: review specific files
• --staged: review staged changes (git diff --cached)
• --branch: review all commits on the current branch vs main

Phase 1: Parallel Diagnosis

Launch two diagnostic agents in parallel using the Agent tool. Each agent gets a different review methodology to maximize coverage through perspective diversity.

Agent A — Multi-Specialist Review

Prompt this agent with the review-dispatch methodology: six focused review dimensions applied independently, then merged into a ranked report.

Dimensions to cover:

1. Correctness — Logic errors, edge cases, state management bugs, error propagation failures, intent-vs-implementation mismatches
2. Design — SOLID violations, coupling, unclear abstractions, naming that obscures intent, premature generalization
3. Performance — Allocation in hot paths, missing with_capacity, lock contention, async blocking, cache-hostile patterns
4. Safety — Unsafe soundness, input validation at boundaries, error swallowing, resource leaks
5. Documentation — Missing doc comments on public APIs, misleading comments, stale docs
6. Complexity (apply /reduce-complexity framework) — Apply the /reduce-complexity evidence-based framework:
   • Thresholds: flag functions where LOC > 100, max nesting > 4, or param count >= 6 on changed/new functions.
   • Essential vs. accidental: classify each hotspot. Leave essential alone; flag accidental as High severity.
   • Anti-abstraction brake: new fn/trait/module with 0-1 call sites → High severity (premature abstraction). param_count + return_type_fields >= body_lines / 3 → warn.
   • Deletion check: any code added that could be removed (dead branches, redundant checks, useless wrappers, unused fields) → High.
   • Duplication: logic that mirrors an existing utility in src/utils.rs or sibling modules → High.
   • Reuse-over-create: a new helper whose job a stdlib / existing function already performs → High.
   • Unsafe exclusion: if the function contains unsafe or calls neighboring unsafe, label MANUAL REVIEW REQUIRED and suppress all simplification suggestions except guard clauses.

Agent prompt template:

You are a code reviewer analyzing changes for quality issues. Review the
following code changes across six dimensions: correctness, design, performance,
safety, documentation, and complexity.

For each finding, report:
- Severity: Critical | High | Medium | Low
- Dimension: which of the six
- Location: file:line
- Evidence: what you see in the code
- Impact: what could go wrong
- Recommended fix: actionable remediation

Target: {target_description}

{diff or file contents}

Agent B — Confidence-Gated Review

Prompt this agent with the ce:review methodology: tiered persona agents with confidence scoring, where only findings above a confidence threshold are reported.

Agent prompt template:

You are a senior code reviewer performing a confidence-gated review. For each
potential issue you identify, assign a confidence score (0-100) representing
how certain you are this is a real problem, not a false positive.

Only report findings with confidence >= 60.

For each finding, report:
- Confidence: 0-100
- Severity: Critical | High | Medium | Low
- Location: file:line
- Issue: what is wrong
- Why you are confident: evidence from the code
- Recommended fix: actionable remediation

Target: {target_description}

{diff or file contents}

Synthesis

After both agents complete, merge their findings:

1. Match by location: Group findings that reference the same file:line (within 5-line proximity)
2. Score convergence: Findings flagged by both agents get a [CONVERGED] tag — these are highest confidence
3. Deduplicate: If both agents describe the same issue at the same location, keep the more detailed description
4. Rank: Sort by: Critical > High > Medium > Low, then converged > single-source
5. Group by file: Cluster findings by file path for Phase 2 ownership assignment

Human Gate

Present findings to the user in this format:

## Review Pipeline — Phase 1 Complete

Found {N} issues across {M} files.

### Findings (ranked by severity + convergence)

| #  | Sev      | Location              | Issue                          | Source      |
|----|----------|-----------------------|--------------------------------|-------------|
| 1  | Critical | src/engine/core.rs:42 | Unchecked overflow in merge()  | CONVERGED   |
| 2  | High     | src/engine/core.rs:87 | Missing error propagation      | Specialist  |
| 3  | High     | src/shard/split.rs:15 | Clone in hot loop              | Confidence  |
| 4  | Medium   | src/engine/core.rs:55 | Dead code in fallback path     | CONVERGED   |

Approve all? Or enter finding numbers to address (e.g., "1,2,3"):

Wait for user response. Accept:

• "all" or empty → approve all findings
• Comma-separated numbers → approve only those findings
• "none" or "skip" → skip Phase 2 entirely

Phase 2: Targeted Execution

For each approved finding, dispatch execution agents to apply fixes.

File Ownership

Group approved findings by file. Each execution agent owns a non-overlapping set of files. If multiple findings target the same file, they go to the same agent.

Agent Dispatch

For each file group, launch an Agent with this prompt:

You are fixing code review findings. Apply the minimum change needed to
address each finding correctly. Do not refactor beyond what the finding
requires — UNLESS the finding is a complexity finding, in which case:

SIMPLICITY DIRECTIVE (overrides "minimum change"):
For Complexity-dimension findings, your job is to REDUCE complexity, not patch
around it. Apply the /reduce-complexity framework:
  1. Prefer deletion over addition. If a branch, variable, or wrapper can be
     removed, remove it.
  2. Prefer reuse over creation. If a util, stdlib fn, or sibling helper
     already does this, call it — do not re-implement.
  3. Collapse unjustified abstractions. A new trait/fn/module with one call
     site should be inlined.
  4. Apply the techniques catalog (guard clauses, let-else, `?` operator,
     merge match arms, extract-function WHEN the extracted fn has ≥2 call
     sites AND `param_count + return_fields < body_lines / 3`).
  5. Respect the unsafe exclusion zone — do not rewrite unsafe code or
     code adjacent to unsafe invariants.
  6. After your fix, the function should either be shorter, shallower, or
     call fewer distinct APIs. Confirm at least one of these improved.

After fixing, run:
  cargo fmt && cargo check && cargo clippy --all-targets -- -D warnings

Findings to address:

{list of findings with file:line, issue description, and recommended fix}

Files you own (only modify these):
{list of files in this group}

Parallel vs Sequential

• File groups with no overlap → dispatch agents in parallel
• If a finding spans multiple files that overlap with another group → run sequentially

Completion

After all execution agents finish, present a summary:

## Review Pipeline — Complete

### Changes Applied

| Finding | Status  | Files Modified              |
|---------|---------|-----------------------------|
| #1      | Fixed   | src/engine/core.rs          |
| #2      | Fixed   | src/engine/core.rs          |
| #3      | Fixed   | src/shard/split.rs          |

### Verification

Run to confirm:
  cargo fmt && cargo check && cargo clippy --all-targets -- -D warnings
  cargo test --lib

Error Handling

• If a Phase 1 agent fails or times out, proceed with the other agent's findings
• If a Phase 2 agent cannot fix a finding, report it as SKIPPED with reason
• If cargo check fails after Phase 2, report the error and let the user decide

Related Skills

• /reduce-complexity — framework the Complexity dimension applies; invoke directly for a deeper simplification analysis on a specific file
• /review-dispatch — Phase 1 methodology (multi-specialist)
• /ce:review — Phase 1 methodology (confidence-gated)
• /execute-review-findings — Phase 2 methodology
• /perf-pipeline — Performance-focused team pipeline
• /test-pipeline — Testing-focused team pipeline
• /simplify — post-fix pass to catch remaining simplification opportunities