rpiv-loop-code-review

对最近更改的文件执行技术代码审查。 > **skill 产物引导**：若本次 `git diff` 的主体是 `SKILL.md`、`references/**.md` 等技能定义文件（而非可执行代码），或本次特性 PRD 的 frontmatter `product_types` 含 `skill`，则本技能下方的审查维度（SQL 注入 / N+1 查询 / 类型提示等）对其基本不适用——**改用 `/rpiv-loop:code-audit <skill 目标>`**，它支持 skill 作为审计对象，且对 skill 目标会自动追加 portability（可迁移性）维度。混合产物（diff 同时含 `.py` 等代码文件）时，代码部分仍按本技能正常审查。 ## 核心原则 审查理念： - 简单是终极的复杂 - 每一行都应该证明其存在的价值 - 代码被阅读的次数远多于编写 - 优化可读性 - 最好的代码往往是你没有写的代码 - 优雅源于意图的清晰和表达的简洁 ## 审查内容 首先收集代码库上下文以了解代码库标准和模式。 首先检查： - CLAUDE.md - README.md - /core 模块中的关键文件 - /docs 目录中记录的标准 在充分理解后 运行这些命令： ```bash git status git diff HEAD git diff --stat HEAD ``` 然后检查新文件列表： ```bash git ls-files --others --exclude-standard ``` 完整阅读每个新文件。完整阅读每个更改的文件（不仅仅是 diff）以理解完整上下文。 对于每个更改的文件或新文件，分析： 1. **逻辑错误** - 差一错误 - 不正确的条件判断 - 缺少错误处理 - 竞争条件 2. **安全问题** - SQL 注入漏洞 - XSS 漏洞 - 不安全的数据处理 - 暴露的密钥或 API 密钥 3. **性能问题** - N+1 查询 - 低效的算法 - 内存泄漏 - 不必要的计算 4. **代码质量** - 违反 DRY 原则 - 过于复杂的函数 - 命名不当 - 缺少类型提示/注解 5. **遵守代码库标准和现有模式** - 遵守 /docs 目录中记录的标准 - 代码检查、类型和格式标准 - 日志记录标准 - 测试标准 6. **删测试资产覆盖核对**（当 diff 含测试文件/测试资产删除时强制） - 对每个被删测试，**逐条**列出其断言维度（文本内容 / 几何 / fill / 字号 / 边界 等），不能只看测试名或参数化的 `visual_type` 名 - 对每个断言维度，核对是否真有替代测试覆盖——**参数化覆盖同名 type ≠ 覆盖该测试所有断言维度** - 任一断言维度无替代覆盖 → 标记为问题，要求"先补再删"，缺口补齐前不得删除 ## 验证问题是否真实 - 为发现的问题运行特定测试 - 确认类型错误是合法的 - 结合上下文验证安全问题 ## 输出格式 将新文件保存到 `rpiv/validation/code-review-{kebab-case-feature-name}.md` - 如果 `rpiv/validation/` 目录不存在则创建 ### 文件格式 文件必须包含 YAML frontmatter 和内容： ```markdown --- description: "代码审查报告: {feature-name}" status: pending created_at: {YYYY-MM-DDTHH:MM:SS} updated_at: {YYYY-MM-DDTHH:MM:SS} archived_at: null --- # 代码审查报告 {审查内容} ``` **Frontmatter 字段说明：** - `description`: 文件描述 - `status`: 文件状态，新创建时固定为 `pending` - `created_at`: 创建时间戳，ISO 8601 格式 - `updated_at`: 更新时间戳，创建时与 created_at 相同 - `archived_at`: 归档时间戳，创建时固定为 `null` **统计：** - 修改的文件：0 - 添加的文件：0 - 删除的文件：0 - 新增行：0 - 删除行：0 **对于每个发现的问题：** ``` severity: critical|high|medium|low status: open file: path/to/file.py line: 42 issue: [一行描述] detail: [解释为什么这是问题] suggestion: [如何修复] ``` > `status` 字段取值：`open`（新建时固定）、`fixed`（已修复）、`wont_fix`（评估后决定不修复，下方附 `wont_fix_reason`）、`deferred`（延后跟踪，下方附 `deferred_reason`，并在 `rpiv/todo/` 创建对应待办文件）。由 code-review-fix 流程在修复完成后回写，禁止使用无归属的 `skipped` 状态（见 code-review-fix SKILL step 2）。 如果未发现问题："代码审查通过。未检测到技术问题。" ## 完成后续 审查产出后，按结论闭合**本审查文件**的 frontmatter `status`（填补干净审查的状态闭合路径——干净审查不会触发 `code-review-fix`，必须由本技能自闭合，否则文件永久卡在 `pending`）： - **干净通过**（输出"代码审查通过。未检测到技术问题。"，或仅余 low / by-design 等**无需 `code-review-fix` 介入**的观察）：不会有后续修复流程被触发，**由本技能直接闭合**——将审查文件 `status` 改为 `completed`，同步 `updated_at`。 - **发现需修复的问题**（存在 `status: open` 的 critical / high / medium）：保持 `status: pending`，提示用户运行 `/rpiv-loop:code-review-fix <审查文件路径>`，由该流程修复后翻 `completed`（见 code-review-fix SKILL step 4 闭环校验）。 > 单一职责说明：两条路径**互斥**（一次审查要么干净、要么有问题），不会双写 status，与 `references/frontmatter-spec.md` 职责表 code-review 行一致。 ## 重要提示 - 要具体（行号，不要模糊的抱怨） - 报告**所有**发现的问题，包括不确定的和低严重度的——用 severity 分级供下游 code-review-fix 过滤；宁可上报后被降级，不可自行压下不报。纯风格 / 命名偏好类 nit 不属于问题范围 - 建议修复方法，不要只是抱怨 - 将安全问题标记为 CRITICAL