用途
code-review 是一个以风险优先级为核心的代码审查技能，适用于用户要求审查代码变更、评估合并就绪度等场景。其核心原则是“铁律”：每条发现都必须引用文件、行范围和代码证据，没有证据就不构成发现。
主要能力
该技能通过五个步骤完成审查：
-
预检（必需）：并行收集分支状态（git status --short --branch）、相对基线的提交记录（git log --oneline --decorate --no-merges <base>..HEAD）、变更范围（git diff --stat 与 git diff --name-only），默认基线为 main。对于 PR URL，使用平台 API 获取 diff 与元数据（描述、评论、CI 状态）。同时探索相关模块、用法、契约、入口点、所有权边界和关键路径。
-
风险优先级审计（必需）：审查分支上的所有提交，按顺序执行六个检查通道：
- Pass A — 行为回归与兼容性：检查分支逻辑、默认值、功能开关、输入输出契约是否变化；API 参数、默认值和遗留数据处理是否向后兼容；命名与返回值语义是否与现有代码库一致。
- Pass B — SOLID 与架构：检查单一职责、开闭原则、里氏替换、接口隔离、依赖倒置，以及过于宽松的类型是否掩盖领域约束。
- Pass C — 安全与可靠性：检查未授权访问、租户数据泄露、并发竞态、部分失败的数据一致性、依赖固定与已知 CVE、TLS 验证是否被禁用等。
- Pass D — 性能与稳定性：检查 10 倍/100 倍数据量下的表现、资源边界与释放、N+1 查询、热路径 CPU 密集工作、失败时的调试上下文、日志或错误输出中的密钥泄露、空值/零值/空输入处理。
- Pass E — 可移除代码：识别未使用、冗余或功能开关关闭的代码，区分可安全立即删除与需延后处理。
- Pass F — 测试覆盖与语言特定检查：判断变更的可观察契约是否有足够区分性验证；缺失测试仅在变更逻辑实质未验证且风险无法由更小的现有、静态或手动检查覆盖时计为回归风险。语言特定检查涵盖 Python 的 naive/aware datetime 混用、ORM 分离实例懒加载、ORM 方言可移植性，TS/React 的 useEffect/useMemo/useCallback 依赖问题，JS/Node 的无保护全局补丁/垫片。
-
呈现发现（必需）：先报告发现，再进行任何更改。报告后，若用户原始请求明确包含修复（如“review and fix”“fix everything”），则自动进入修复循环；否则询问用户如何处理（全部修复/仅修复高优先级/修复特定项/不做更改），在用户确认前不实施更改。
-
修复循环（条件性）：仅在步骤 3 确定修复范围后进入。每轮迭代运行最小相关验证建立修复前基线、应用最小修复、重新运行相同验证确认修复、对整个 diff 进行对抗性复审。对抗性复审默认立场是修复引入了新问题，必须主动尝试反驳修复的正确性。每轮复审必须从相同基线上下文开始，不得携带先前复审发现、修复理由或迭代历史。优先每轮生成全新子代理；若子代理不可用，则重置上下文后从头重读完整 diff。最多 3 轮迭代，若仍不稳定或范围内发现未解决则停止并报告用户。
-
发布前自检（必需）：在最终确定前运行 output-template.md 中的自检。
使用方式
该技能通过 skills.sh 平台以 slug code-review 提供，来源为 whhe/ai-workshop。使用时用户提出代码审查请求，技能按上述工作流执行。修复循环仅在用户明确要求修复或确认修复范围后进入。
适用场景
适用于审查代码变更、评估合并就绪度、检查分支提交、审查 PR 等场景。
限制
- 禁止在呈现发现前进行修复。
- 禁止未经用户明确请求提交或推送代码。
- 禁止将未验证项标记为“通过”。
- 禁止为让测试通过而绕过关键检查（移除认证、吞掉异常、降低安全等级）。
- 禁止在安全与正确性问题之前列出风格/命名问题。
- 禁止在没有列出检查内容的情况下报告“未发现问题”。
- 禁止猜测行为而非阅读实际代码和 diff。
- 修复循环最多 3 轮迭代。
- 缺失前置条件（命令未找到、依赖缺失）时须声明“未验证”并说明影响范围，提供可复现命令，绝不伪造结果。
资源文件
按需加载：solid-checklist.md（Pass B 需要异味提示或重构启发式时）、security-checklist.md（Pass C 需要威胁模型细节时）、code-quality-checklist.md（Pass D 需要稳定性/性能子检查时）、removal-plan.md（Pass E 发现可移除候选时）、output-template.md（步骤 3 和 5 的文档结构、证据规则、自检）。