القائمة
Use when 用户要求审查代码、评估代码质量、提交 PR 前检查、发现代码有潜在问题时。触发场景：代码审查、code review、审查代码、review、检查代码、代码检查、代码质量、代码评审、这段代码有问题吗、帮我看看代码、合并前检查。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
超压缩通信模式。通过去掉废话、冠词和客套语，在保持完整技术准确性的同时削减约 75% token 用量。 当用户说"caveman 模式"、"简洁模式"、"少废话"、"省 token"、"简短点"或调用 /caveman 时触发。
对用户的计划或设计进行不留情面的深度追问，直到达成共同理解，逐一解决决策树的每个分支。当用户想要压力测试计划、检验设计时触发。触发词：追问我、grill me、逐一问我、挑战我的方案、深度追问、质疑设计、设计评审追问。
将当前对话压缩为交接文档，供下一个 Agent 会话接续工作。触发词：交接、handoff、下一个会话、会话摘要、接续工作、传给下一个 agent。
在代码库中发现架构"深化"机会——将浅模块变成深模块的重构，提升可测试性和 AI 可导航性。与 architecture-advisor 互补：architecture-advisor 设计新架构，本技能改善现有代码库结构。触发词：改进代码库架构、架构深化、找重构机会、模块耦合太紧、难以测试、代码难以理解、架构改进、improve architecture、refactor opportunities。
快速验证设计的一次性原型。区分两条分支——逻辑/状态模型用终端交互 App，UI 布局用多变体路由切换。当用户想原型验证、检验数据模型或状态机、探索多种 UI 方案时触发。触发词：原型、prototype、验证方案、快速试验、让我玩一玩、试几个设计。
Use when 已有书面实施计划、任务相对独立，且在本会话内通过子代理逐任务落实时。触发场景：执行实施计划、子代理开发、按计划实现、Task 派发实现、两阶段代码审查、plan execution。
| name | code-review-expert |
| description | Use when 用户要求审查代码、评估代码质量、提交 PR 前检查、发现代码有潜在问题时。触发场景：代码审查、code review、审查代码、review、检查代码、代码检查、代码质量、代码评审、这段代码有问题吗、帮我看看代码、合并前检查。 |
铁律：默认只输出审查报告，不实现任何修改。未经用户明确确认，不得编写或修改任何代码。
审查报告输出完毕后，必须等待用户从第七步的选项中明确选择后续操作，才能进行任何代码修改。 不得根据"用户肯定想修复"的假设主动修改代码。
git diff；或用户指定 commit/目录）；运行/测试命令（如有）；风险偏好（例如“安全优先/交付优先”）。references/review-report-template.md）。references/quality-gates-checklist.md。writing-plans（实施计划编写）：先写可执行修复计划subagent-driven-development（子代理驱动开发）：按计划逐任务执行| 级别 | 名称 | 说明 | 处置 |
|---|---|---|---|
| P0 | 致命 | 安全漏洞、数据丢失风险、逻辑错误 | 必须阻止合并 |
| P1 | 严重 | 重大 SOLID 违反、性能回退、业务逻辑缺陷 | 合并前应修复 |
| P2 | 中等 | 代码异味、可维护性问题、轻微 SOLID 违反 | 本 PR 修复或创建后续 Issue |
| P3 | 建议 | 风格、命名、优化建议 | 可选改进 |
执行以下命令建立审查范围：
git status -sb
git diff --stat
git diff
边界情况处理：
若需要，用 rg 查找相关模块、用法和接口契约，识别入口点、权限边界和关键路径（认证、数据写入、网络调用）。
加载 references/solid-checklist.md 进行系统检查。
重点关注：
提出重构建议时，必须说明为何能改善内聚性/耦合度，并给出最小化、安全的拆分方案。非简单重构时，提出渐进式计划而非大规模重写。
加载 references/refactor-plan.md。
识别：无用代码、冗余逻辑、功能开关保护的死代码。 分类为：立即安全删除 vs 延后处理（附计划与检查节点）。
加载 references/security-checklist.md。
覆盖：
加载 references/quality-checklist.md。
覆盖：错误处理完备性、性能热点、边界条件、可测试性。
输出格式固定如下：
## 代码审查报告
### 总览
[变更范围概述，受影响的核心模块与影响面评估]
### 发现问题
#### P0 致命问题
- **[文件:行号]** 问题描述
- 原因：[为什么这是问题]
- 修复建议：[具体如何修复，可含代码示例]
#### P1 严重问题
[同上格式]
#### P2 中等问题
[同上格式]
#### P3 建议
[同上格式]
### 可删除/重构计划
[来自 refactor-plan 的识别结果]
### 安全摘要
[安全扫描结论，无问题则明确说明已覆盖的检查项]
### 亮点
[代码中做得好的部分，平衡批评]
内联注释格式：::code-comment{file=路径 line=行号 severity=P0}
无问题时，明确说明已覆盖的检查范围与未覆盖项（如已排除的文件）。
列出选项（等待用户选择，不要自动执行）：
请选择后续操作：
1. 修复全部问题（P0 + P1 + P2）
2. 仅修复阻塞性问题（P0 + P1）
3. 指定修复某个问题（请说明编号）
4. 暂不修改，仅保留报告
在用户选择前，不实现任何修改。
遇到以下想法，立刻停下——先输出报告，再等待用户指令：
| 借口 | 现实 |
|---|---|
| "P0 问题这么严重，我帮用户直接修吧" | 用户可能有不同的修复方案或上下文。先报告，等确认。 |
| "修复很简单，顺手就改了" | "顺手修复"绕过了用户的决策权，可能引入用户不想要的变更。 |
| "用户肯定想让我修" | "肯定"不是确认。等待用户从选项中明确选择。 |
| "我跳过安全检查，这个项目看起来没安全问题" | 安全问题从来不是"看起来"没有就没有。必须按清单逐项检查。 |
| "代码变更太小，不用走完整流程" | 小变更也会引入 SQL 注入、越权等高危漏洞。没有可以跳过的情况。 |
| "这个问题我已经在报告里提了，顺手修了也无妨" | 无妨不等于对。铁律：未经确认，不写代码。 |
references/solid-checklist.md — SOLID 原则详细检查项references/security-checklist.md — 安全漏洞检查清单references/quality-checklist.md — 代码质量检查清单references/refactor-plan.md — 可删除代码与重构计划模板