用途
Review 用于对现有代码、diff、分支或 Pull Request 进行独立审查，判断变更是否安全可发布。它是“验证之后”的关卡：构建者先证明变更在真实环境可用，随后由 Review 决定变更是否足够好。它专注于审查已存在的代码，而不是作者自查刚完成的变更。
主要能力
- 使用按关注点划分的审查者角色（reviewer personas）进行独立审查。
- 当关注点相互独立时，优先并行运行多个审查者角色（可借助并行 subagent）。
- 加载目标仓库的指导文件，例如 AGENTS.md、CLAUDE.md 或仓库规则。
- 收集静态证据与最小运行时检查，避免仅凭审查者直觉下结论。
- 按严重程度排列发现，输出明确裁决。
核心原则
- 关注点独立时优先并行审查者角色。
- 证据优先于主观品味。
- 从目标仓库的指导文件（AGENTS.md、CLAUDE.md 或仓库规则）加载共享准则。
- 最终裁决与具体证据绑定，而非仅凭审查者直觉。
- 发现聚焦风险，不让用户被低价值琐碎问题淹没。
- 在内部追踪审查者角色，仅在用户要求或运行环境有紧凑元数据时可见地列出。
- 若目标是为自己刚完成的变更获取运行时证明，应转交 verify。
使用方式
开始前需：
- 界定范围：文件、diff、分支、提交范围或 PR。
- 若存在，加载目标仓库的指导文件（AGENTS.md、CLAUDE.md 或仓库规则）。
- 从 references/reviewer-selection.md 选择审查者角色。
- 决定哪些角色可以独立并行运行。
默认角色：
- reviewers/general.md
- reviewers/tests.md
- reviewers/silent-failures.md
条件性角色（仅在有价值时启用）：
- reviewers/types.md
- reviewers/cleanup.md
- reviewers/comments.md
角色快捷规则：
- 仅文档或注释类 diff：使用 general 加 comments；除非 diff 确有必要，跳过 tests、types、silent-failures 和 cleanup。
- 类型形状或 schema 变更：增加 types。
- 存在死文件、废弃路径或明显未使用的辅助函数：增加 cleanup，必要时明确建议删除。
- 围绕高风险行为的重 mock 或浅层测试：将其作为发现，而不是把测试存在当作证明。
工作流：
- 界定邻近风险：审查请求的代码，但当风险越过指定 diff 时检查相邻行为。
- 运行审查者角色：可用时使用并行 subagent，保持每个角色聚焦且独立。具体起点包括
git diff --stat <base>...HEAD评估变更规模、git diff <base>...HEAD -- <path>检查风险文件、以及pnpm test path/to/spec等定向测试为行为主张提供证明。 - 收集证据：静态发现引用精确文件位置；仓库支持时运行能改变裁决的最小运行时检查；未验证的内容明确说明，不虚报；若遗留或死代码仍存在，说明应删除还是必须保留；若测试 mock 了主要集成或边界，说明行为在真实环境仍未验证。
- 综合裁决：按严重程度排列发现；若未发现问题，明确说明并提及残余风险或测试缺口；选择恰好一个裁决：ship it、needs review 或 blocked。
输出格式
审查后报告一个精简的 verdict footer，包含：
- verdict
- evidence summary：精确命令名或运行时表面，而非完整日志
- unverified areas 或 readiness gaps
- next：implementation、verify、agent-readiness 或 docs
需显式使用上述标签，不要用“safe to merge”或“do not ship today”等柔和措辞替代。优先使用当前运行环境的最佳原生审查表示，而非大段文字。最终答案保持简短：详细问题文本、文件引用和行号放入原生 findings 或 fallback findings 列表；不要在 verdict 块中重复原生 finding 细节；verdict footer 保持在 4 行带标签内容以内；每个标签一句话；用逗号分隔命令名而非日志摘录；除非用户要求或范围会歧义，否则在 footer 中省略 scope 和 personas。若无发现，写 findings: none，其余同样紧凑。
针对不同运行环境的展示规则：优先使用可用的最强结构化 finding 格式，例如 Codex/OpenAI 的原生 P0/P1/P2/P3 卡片，或 Claude/Anthropic 环境中的紧凑表格；若无更丰富原语，使用按严重程度排序的简短 findings 列表，包含文件/行号、问题、影响和证据；绝不把可操作的 finding 隐藏在 footer 或冗长文字总结中。
示例：
verdict: needs review finding: high — src/auth/session.ts:42 fallback returns an anonymous session when token parsing fails evidence: pnpm test src/auth/session.test.ts unverified areas: runtime behavior for malformed OAuth callbacks next: implementation
转交场景
- 对自己刚编写的变更进行自查，然后才转交审查 → 使用 verify。
- 因仓库无法可靠启动或运行而导致 Review 受阻 → 使用 agent-readiness。
- 主要问题是 AGENTS.md、README、规格或仓库文档过时 → 使用 docs。
参考资料
- references/reviewing.md — 审查者角色工作流、证据期望与裁决综合。
- references/reviewer-selection.md — 不同变更形状应运行哪些审查者角色。
- reviewers/ — 专业化审查视角。
限制
资料未提供该技能的收费、价格或具体平台支持信息。