| name | pre-commit-review |
| description | Summarizes modified files in detail and reviews code to ensure changes do not affect other functionality. Use when the user asks for modification summary, code review, pre-commit review, or to ensure changes pass functional testing without introducing new issues. Trigger terms include: 审查代码、审查修改、review代码、代码审查、代码复审、测试代码、修改总结、提交前审查、 不影响其他功能、审查结果不通过、回归测试、功能测试、修改review、审查变更. If the intent is ambiguous (e.g. 检查一下、看一下代码), ask the user to confirm: "是否需要按提交前审查流程，做修改总结 + 场景矩阵 + 代码审查？" If review fails, state the reason clearly.
|
| metadata | {"author":"liuhean","email":"allsmy.com@gmail.com"} |
提交前修改总结与代码审查
本技能用于在提交前对本次修改做详细总结与代码审查，确保功能测试通过、不引入新问题、不影响需求外的功能。
触发场景
用户表达以下任一含义时应用本技能（含但不限于）：
- 审查类：审查代码、审查修改、review代码、代码审查、代码复审、修改审查、审查变更、修改review
- 总结类：详细总结修改、修改总结、变更总结
- 提交前：提交前审查、提交前检查、commit 前审查、提交前review
- 质量/测试类：测试代码、回归测试、功能测试、确保不影响其他功能、不引入新问题、审查结果不通过则告知原因
若有疑问：若用户意图不明确（例如仅说「检查一下」「看一下代码」「帮我看下」），先询问确认：「是否需要按提交前审查流程，做修改总结 + 场景矩阵 + 代码审查？」确认后再执行。
严重等级标签
在审查意见中使用以下标签区分优先级：
| 标签 | 含义 | 处理要求 |
|---|
| 🔴 [阻塞] | 必须修复才能提交（安全漏洞、数据丢失、功能中断） | 修复后重新审查 |
| 🟡 [重要] | 应当修复，有分歧时讨论 | 原则上修复，或说明原因 |
| 🟢 [建议] | 可选优化，不阻塞提交 | 参考采纳 |
| 💡 [思路] | 备选方案，供讨论 | 无需操作 |
| 📚 [学习] | 知识分享，无需操作 | 参考了解 |
| 🎉 [亮点] | 值得肯定的做法 | 保持 |
执行步骤
第一步：收集修改范围（上下文）
- 使用
git status -s、git diff --cached --stat（或 git diff --stat）确定本次修改的文件与行数。
- 若文件超过 10 个或改动超过 400 行，建议按模块分批审查。
- 若用户未指定范围，以当前暂存区或工作区变更为准。
第二步：详细总结修改
对每个修改文件写出：
- 文件路径：相对项目根的路径。
- 修改类型：新增 / 修改 / 删除。
- 修改要点：用列表说明改了什么（逻辑、条件、顺序、依赖等），可引用关键代码或行号。
- 修改目的：与需求或问题的对应关系（修复什么、优化什么、限制在什么场景）。
格式示例：
### 文件路径
- **类型**：修改
- **要点**：① …；② …
- **目的**：…
第三步：代码审查
3.1 影响面分析
对每个修改点做影响面分析：
| 审查项 | 说明 |
|---|
| 需求内行为 | 本次修改在「目标场景」下是否按预期工作（条件、分支、顺序、依赖是否正确）。 |
| 需求外行为 | 未改动的场景、平台、入口、用户类型是否仍按原逻辑执行（是否有误判、误跳过、误拦截）。 |
| 边界与平台 | 若修改与「平台/环境/登录方式」相关，是否用明确条件（如 isWechat、route.query.xxx）限制，避免其他平台被影响。 |
| 依赖与顺序 | 是否依赖未完成的数据（如 userInfo 未拉取）、执行顺序是否会导致竞态或误报。 |
| 未修改的关联代码 | 路由守卫、请求拦截、401 处理、全局配置等是否未改且与本次逻辑兼容。 |
对关键分支与条件做场景矩阵（推荐）：
- 列出：场景（平台/登录态/URL/配置） → 预期行为 → 修改后是否一致。
- 重点覆盖：非目标平台、未登录、其他登录方式、异常/401、配置未加载等。
3.2 安全专项清单
涉及认证、输入处理、数据存储时必查；纯 UI/样式改动可跳过。
3.3 性能专项清单
涉及循环、数据库查询、API 调用时必查；简单逻辑修改可跳过。
3.4 测试质量清单
涉及核心业务逻辑变更时必查；文档/配置改动可跳过。
3.5 项目技术栈专项（TypeScript / Vue3 / NestJS）
项目涉及对应技术栈时核查。
TypeScript
Vue3 / 前端
NestJS / 后端
第四步：审查结论
使用以下结构化格式输出结论：
## 审查结论
### 亮点
🎉 [描述值得肯定的设计或实现]
### 必须修复（阻塞提交）
🔴 [阻塞] 文件路径:行号 — 问题描述
→ 原因：为什么这是问题
→ 建议：具体的修改方案
### 应当修复
🟡 [重要] 文件路径:行号 — 问题描述
→ 建议：…
### 优化建议（不阻塞）
🟢 [建议] …
💡 [思路] …
### 结论
✅ 通过 / ❌ 不通过（需修复上述 🔴 问题后重新审查）
通过条件：无 🔴 阻塞问题。
不通过时：必须逐条列出原因，不允许只写「审查不通过」。
第五步：输出审查文档
- 必须将本次「修改总结 + 场景矩阵 + 审查结论」写入项目
docs/review/ 下的审查文档。
- 一个分支只需要一个 review 文档：若当前分支已有对应审查文档（如
<需求标识>-review.md），在原有文档基础上更新本次变更的修改总结、场景矩阵与审查结论，不新建重复文档；若无，则新建 <需求或需求标识>-review.md。
- 文件名建议：
<需求或需求标识>-review.md（如 AI-748-review.md），同一分支后续审查只更新该文件，不新增 *-re-review.md、*-code-review.md 等分散文档。
- 文档内容至少包含：修改文件列表与要点、场景矩阵、审查结论（通过/不通过及原因）、专项清单检查结果。
- 若项目根目录下无
docs/review/，先创建该目录再写入；若已有 docs/review/README.md，在 README 中维护审查文档索引（每个需求/分支对应一条）。
审查不通过时的处理
- 明确告知用户：审查不通过，并列出原因（逐条，带文件路径与行号）。
- 给出修改建议：使用「情境 + 具体问题 + 建议方案」格式，避免空洞的「请修改」。
- 不执行提交：在用户根据建议修改并再次审查通过前，不进行 git commit；若用户坚持提交，提醒风险并记录原因。
建设性反馈原则
使用引导式提问代替直接否定，促进思考而非施压：
❌ 「这里有 bug，必须改。」
✅ 「如果 items 是空数组，这里会发生什么？」
❌ 「你需要加错误处理。」
✅ 「如果这个 API 调用失败，应该如何处理？」
❌ 「这样写性能很差。」
✅ 「用户量到 10 万时，这里每次都循环查询会有什么影响？」
更好的做法（推荐）
- 先定范围再改：修改前明确「只动哪些文件、只影响哪些场景」，审查时重点核对是否越界。
- 平台/入口显式限制：凡「仅某平台或某入口」才生效的逻辑，用显式条件（如 isWechat、route.query.xxx、配置开关）包裹，避免其他平台误走。
- 场景矩阵：对登录、平台、URL、配置等做一张「场景 → 预期 → 结论」表，避免漏掉边界。
- 关联代码看一眼：修改了 layout/请求/路由相关逻辑时，顺带确认 permission、request 拦截、401 处理未改且兼容。
- 审查文档沉淀：每个分支只维护一个 review 文档，后续审查在原有文档上更新变更部分，避免同一需求多份重复文档。
输出约定
- 总结与审查结论以中文呈现（除非项目约定英文）。
- 审查不通过时，🔴 阻塞问题单独成段，便于用户一眼看到。
- 不通过时必须包含具体原因 + 修改建议，使用「情境 + 具体问题 + 建议方案」格式。
- 如有值得肯定的实现，用 🎉 [亮点] 说明，保持建设性氛围。
小结
- 目的：确保每次修改在提交前功能测试通过，不引入新问题，不影响需求外的功能。
- 通过：无 🔴 阻塞问题，写明符合预期且不影响其他功能，并点出关键保障。
- 不通过：明确原因（文件/行号/场景）+ 修改建议，不执行提交直至用户修复并再次审查通过（或用户明确坚持提交时提醒风险）。
