用途
sdd-review 是 SDD（规格驱动开发）工作流的第 5 步，定位为一次彻底的代码审查。它要求以首席工程师的身份执行审查，强调审查必须诚实、具体、可执行，而非泛泛而谈；每一条发现都必须引用确切的文件与行号范围。
主要能力
审查按以下维度依次进行：
- 验收标准验证：若存在 feature.md，逐条核对每个 AC 是否有直接覆盖的测试、实现是否真正满足该 AC；无测试覆盖的 AC 标记为 🔴 严重；已完全覆盖并满足的 AC 在 feature.md 中把
- [ ]改为- [x]。 - 语言与框架最佳实践：对照 docs/project.md 声明的技术栈与惯例，检查语言惯用法、反模式、错误处理约定、生产代码中的调试输出、不可变性；框架层面检查分层职责、配置集中化、依赖注入、HTTP 状态码语义、集中式异常处理、测试范围选择；数据访问层面检查无界查询、N+1 风险、安全参数化、记录缺失的显式处理。
- 安全：注入（仅参数化查询）、认证与授权、输入验证、敏感数据暴露、批量赋值、依赖风险、CORS/CSRF、错误信息泄露。
- 代码重复：扫描改动文件中与既有工具/服务/辅助方法重复的逻辑、测试类或服务方法间的复制粘贴、应改为多态或策略模式的重复分支、多处出现的硬编码值。
- 设计与架构：是否遵守 docs/project.md 的分层、单一职责、静态方法状态、接口与抽象的使用、包结构一致性。
- 性能：响应式/异步管道中的同步阻塞调用、循环内重复数据库调用、热路径上的昂贵操作、查询模式隐含的索引问题。
- 测试质量：Arrange-Act-Assert 结构、测试命名、测试中无逻辑、仅在架构边界使用 mock、无任意 sleep、测试数据精简、边界情况覆盖。
- 可观测性：日志级别是否恰当、日志中无敏感数据、是否对重要操作做了指标埋点。
使用方式
输入参数 review_path 为可选，用于指定要审查的文件、包或模块路径，默认覆盖完整 git diff 范围。
执行步骤：
- Step 0：验证输入（始终先做）。若提供了 review_path，则仅审查该路径；若缺失，则运行
git diff main...HEAD --name-only找出本分支改动的文件；若不在功能分支上，则要求用户指定路径或确认是否进行全代码库审查。 - 前置条件：开始前阅读 docs/project.md（技术栈、架构、惯例）、feature.md（验收标准与功能需求，若存在）、plan.md（预期实现方式，若存在）。
- 审查范围：聚焦改动/新增文件；对无关的既有代码只做记录，不深入审查。
输出格式
审查结果写入项目根目录的 review.md，结构包括：标题（Code Review: <功能名或路径>）、Summary（2-3 句总体评估，直接说明是否可合并、需小修还是需大改）、Findings（按 🔴 Critical / 🟠 Major / 🟡 Minor / 🔵 Info 分表，每行含 Done 复选框、Location、Category、Problem、Suggestion）、Acceptance Criteria Coverage 表（AC、Test、Status）、Verdict（✅ 可合并 / 🟡 小修后合并无需复审 / 🟠 需修复并复审 / 🔴 不可合并）。
严重级别定义：🔴 CRITICAL 合并前必须修复（安全漏洞、数据丢失风险、AC 未满足）；🟠 MAJOR 合并前应修复（重大缺陷、严重设计问题）；🟡 MINOR 尽快修复但不阻塞（代码异味、轻微低效）；🔵 INFO 建议或最佳实践（风格、可选改进）。
表格中 Problem 与 Suggestion 各限一句话，单元格内不放代码块。
写入文件后打印一行确认：review.md written。随后在对话中内联展示 Summary 与 Verdict 部分，便于用户立即了解上下文。
审查之后
询问用户：“Would you like me to fix any of these findings now? You can say 'fix all critical and major' or call out specific items.”若用户要求修复，则处理并重新运行相关测试确认修复有效；若所有发现均已解决，提示用户运行 /sdd-archive（若尚未执行）。
适用场景
适用于 SDD 流程中功能实现完成后的代码审查环节，尤其适合需要对照验收标准、技术栈惯例与安全要求进行结构化审查的团队。
限制
该技能依赖 docs/project.md、feature.md、plan.md 等前置文档的存在才能发挥完整效果；未提供 review_path 且不在功能分支时需用户介入确认范围。具体收费、价格、平台支持等信息暂未提供。