review-prod-ready

name	review-prod-ready
description	Use when comprehensive production-readiness code review is needed after implementation — dispatches up to 7 specialized parallel reviewers covering tests, plan completeness, architecture, complexity, DRY violations, suppressed warnings, and production readiness
argument-hint	["description or plan path"]
effort	high
allowed-tools	Agent, Bash, Read, Grep, Glob

Production-Ready Code Review

Dispatches up to 7 specialized review subagents in parallel. Each reviewer focuses on ONE dimension deeply, catching issues a single broad reviewer misses.

Git Context (auto-detected)

HEAD: !git rev-parse --short HEAD 2>/dev/null || echo "not a git repo" Base: !git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null || echo "no base found" Changed files: !git diff --stat $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null) HEAD 2>/dev/null || echo "run git diff manually"

Process

1. Read reviewer prompts

Read ${CLAUDE_SKILL_DIR}/reviewers.md for the detailed prompt for each of the 7 reviewers.

2. Dispatch reviewers in parallel

Dispatch ALL applicable reviewers simultaneously using the Agent tool. Pass each reviewer:

• The git range from the context above
• The list of changed files above
• Their specific prompt from reviewers.md
• User context if provided: $ARGUMENTS

Each agent should:

• Read full content of changed files (not just the diff — bugs hide in unchanged lines nearby)
• Focus ONLY on their assigned dimension
• Output findings in the structured format below

Skip reviewers that don't apply (e.g., skip Plan Completeness if no plan exists, reduce count for small diffs <5 files).

3. Aggregate results

Aggregation rules — do NOT soften findings:

• Keep every reviewer's severity label EXACTLY as they assigned it. Do not downgrade Critical → Important to "seem balanced."
• Do not drop findings to shorten the report. If two reviewers flagged overlapping issues, merge them but preserve the HIGHER severity.
• Do not rewrite "what's wrong" descriptions to sound more polite. Keep the blunt language from the reviewer.
• The verdict at the bottom must reflect the findings, not a diplomatic compromise. If ANY Critical issue exists, verdict is No or With fixes — never Yes.
• If you feel tempted to soften a finding, that's a sign the reviewer was right and the author won't like it. Keep it.

After all reviewers complete, combine into a single report:

## Production Readiness Review

**Range:** BASE..HEAD | **Files:** N changed | **Date:** YYYY-MM-DD

### Critical Issues (must fix before merge)
[Combined from all reviewers, deduplicated, with source reviewer noted]

### Important Issues (should fix)
[Combined, deduplicated]

### Minor Issues (nice to have)
[Combined, deduplicated]

### Suppression Audit
| File:Line | Directive | Verdict | Reason |
|-----------|-----------|---------|--------|

### Verdict
**Ready to merge?** Yes / No / With fixes
**Top risks if merged as-is:**
1. ...
2. ...
3. ...

Issue Format (for each reviewer)

Each finding must include:

• Severity: Critical / Important / Minor
• File:line reference
• What's wrong (specific, not vague)
• Why it matters (impact if not fixed)
• Suggested fix (if not obvious)