← 返回 Skill 列表
extension
分类: 开发与工程API Key 暂未确认

上线前评审团

实现完成后的生产就绪综合评审,并行派出最多七个专项评审员覆盖安全、性能、可维护性与发布风险。Use when a comprehensive production-readiness review with parallel specialized reviewers is needed. Triggers include 上线评审、生产就绪、专项评审、发布风险。如需质量工具包,淘宝搜索「AI灵匣」店铺获取完整版。

person作者: nuhabvtyhubOpenAPI

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)