code-review

代码审查

中文版： 请参阅对应的中文技能。

适用场景

• 需要审查 PR、diff 或 commit，并在合并前发现逻辑、安全、财务损失或可维护性风险。
• 需要一份按 P0/P1/P2 分级的报告，包含位置和可执行的修复建议。
• 需要从 QA / 工程质量角度审查，而不只是作者自查。

工作流

1. 阅读并遵循渐进式披露中列出的主要提示词（覆盖范围、结构、质量标准）。
2. 开始审查前，确认代码版本可识别且有可审查的变更；如果缺少其中任一项，返回受阻结果并索取确切材料。
3. 只补充会影响审查结果的项目背景：变更范围、业务目标、技术栈、上下游依赖、已知风险、团队规范。
4. 将角色报告视为可选且需注明来源的背景信息；仅当变更涉及相关内容时，才使用产品和 UI/UX 报告。
5. 默认使用 Markdown；只有用户提出要求时才切换格式。

核心约束

• 以风险为导向：优先关注生产故障、财务损失、安全和核心可维护性，而非命名或缩进等细枝末节。
• 以证据为依据：每项发现应尽量提供文件路径、行号或代码片段，并说明触发路径和影响。
• 双重门槛：必须同时具备可识别的代码版本（例如仓库 + PR / commit / 分支 / 标签 / 修订版）和可审查的变更（例如 diff/patch、变更文件内容，或可访问的 base-to-head 范围）。代码身份、变更内容和角色报告不能相互替代。
• 如果缺少任一门槛，明确返回 status: blocked，并区分 missing_code_identity 和 missing_reviewable_change；不得声称已完成审查、建议合并或编造代码问题。
• 角色报告为可选信息。使用时，保留 source_role。产品报告可补充业务规则、状态流转或验收背景；只有在相关时，UI/UX 报告才能补充 UI 状态、反馈、响应式设计或无障碍背景。不得将角色视角表述为代码事实。
• 严格划分严重级别：P0 阻止合并，P1 应在本次迭代修复，P2 可作为技术债处理。
• 区分已确认事实与假设；不得编造用户未提供的端点、字段、环境或根因。
• 评审代码，而非作者；尊重当前技术栈，未经授权不得要求重写框架或架构。
• 确保输出可执行：每项发现都必须提供修复方向或修改前后示例。

渐进式披露

• 输出前，阅读并遵循 prompts/code-review.md（最低覆盖范围、输出结构、质量标准）。
• 用户要求 Excel/CSV/JSON/Word 格式时：阅读 output-formats.md 并遵循相应格式。
• 有现成模板适用时：使用 output-templates/ 下匹配的文件。
• 需要更深入的审查维度或严重级别标准时：阅读 references/review-dimensions.md。
• 需要示例或校准时：阅读 examples/ 下匹配的文件。
• 需要格式转换或辅助检查时：优先使用现有的 scripts/，避免重复造轮子。
• 想采用最短路径时：阅读 quick-start.md。
• 评估此技能或进行回归测试时：通过 skill-up 使用 evals/。

交付前检查清单

• 遵循主要提示词的输出结构
• 确认代码身份和可审查变更两个门槛均已满足；若受阻，未给出已完成审查的结论或合并建议
• 最低覆盖重点：变更摘要、总体风险评级、P0/P1/P2 列表、可测试性/可观测性、API/契约兼容性、修复顺序、剩余风险和假设……（详见主要提示词）
• 覆盖最低检查清单，或说明未覆盖的项目
• 高风险项明确标注 P0/P1，并说明理由
• 未编造用户未提供的细节
• 已标明假设和信息缺口

常见陷阱

• 不要将代码片段或角色报告视为代码身份，也不要将 PR / 提交标识符视为差异；如果缺少任一门禁条件，就应阻止。
• 不要仅仅因为存在报告就启用 Product 或 UI/UX 关注点；应先确认相关性，并保留其来源。
• 不要将每个项目都视为同等重要，也不要罗列价值低的风格细节。
• 不要忽略假设和信息缺口。
• 不要强行要求重构审查范围之外的内容。
• 不要罗列与本次变更无关的通用理论。