القائمة
Use when a feature, bugfix, or refactoring step is completed and needs review, or before merging to main, or when user says "review", "审查", "帮我看看代码"
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when receiving an ambiguous feature request, when scope is unclear, or before writing any plan
Use after verification-before-completion passes and code review is clean, to close out the development branch
Use when executing git commit, creating or naming branches, writing PR titles/descriptions, or asking about commit message format, branch naming, or version numbering in this project
Use when writing or reviewing .ets/.ts files in this project, or when seeing any, unknown, obj['key'] index access, destructuring assignment, var declarations,
Use when user asks to create a version release ticket, says "帮我建个发版任务", "建个 Jira", "创建发版单", or needs to track an SDK release in Jira
Use when user mentions "发布 SDK"、"ohpm 发布"、"打包发布"、"上传 har"、"publish"、"发版"、"release"、"发布" or "上传" in the context of this SDK
| name | sdk-code-review |
| description | Use when a feature, bugfix, or refactoring step is completed and needs review, or before merging to main, or when user says "review", "审查", "帮我看看代码" |
Type: Technique | Discipline: Rigid
dispatch 审查 subagent 对已完成的工作进行独立审查。审查者不继承当前会话历史——你负责构造它需要的全部上下文。
强制：
可选但推荐：
工作完成，需要审查?
│
▼
有 plan 文件对应本次改动?
├─ YES → 模式 A：完整审查（spec-reviewer → code-reviewer）
│
└─ NO → 变更文件 ≤ 5 且不涉及公开 API?
├─ YES → 模式 B：独立审查（仅 code-reviewer）
└─ NO → 回退去补 plan（writing-plans），再走模式 A
审查者返回结果
├─ 通过 → verification-before-completion
├─ 需要修改 → 修复 → 重新 dispatch 同审查者（不可自行判断"已修好"）
└─ 需要讨论 → receiving-code-review skill 处理 push back
dispatch 两个独立审查者，顺序执行：
规格合规审查：dispatch spec-reviewer subagent
代码质量审查：dispatch code-reviewer subagent
满足以下全部条件时，只 dispatch code-reviewer 一次：
根据触发场景选择正确的 BASE_SHA：
场景 A：合并到 master 之前（review 整个功能分支）
# 用 merge-base 找到分支与 master 的分叉点
BASE_SHA=$(git merge-base HEAD master)
HEAD_SHA=$(git rev-parse HEAD)
场景 B：单个任务完成后（subagent-driven-development 中的任务级审查）
# BASE_SHA 在 dispatch 实现者 subagent 前记录，HEAD_SHA 在实现者提交后记录
# 具体做法见 subagent-driven-development skill
场景 C：当前工作区未提交的改动
BASE_SHA=$(git rev-parse HEAD)
# HEAD_SHA 不适用；让审查者用 git diff HEAD 查看未暂存 + 已暂存的改动
# 查看变更文件列表
git diff --name-only $BASE_SHA..$HEAD_SHA
# 查看完整 diff
git diff $BASE_SHA..$HEAD_SHA
dispatch spec-reviewer 时，必须提供：
| 字段 | 说明 | 示例 |
|---|---|---|
| 变更内容 | 本次完成了什么 | "新增 onPageEnd API" |
| 规格/规划 | plan 全文或任务描述全文 | 粘贴 plan 内容 |
| 实现者报告 | 实现者的完成报告（如有） | 粘贴报告 |
| BASE_SHA | 变更起始 commit | a7981ec |
| HEAD_SHA | 变更结束 commit | 3df7661 |
| 变更文件列表 | git diff --name-only 的输出 | 文件列表 |
dispatch code-reviewer 时，必须提供：
| 字段 | 说明 | 示例 |
|---|---|---|
| 变更内容 | 本次完成了什么 | "新增 onPageEnd API" |
| 对应规划 | plan 文件路径（供参考） | docs/plans/2026-04-10-on-page-end.md |
| BASE_SHA | 变更起始 commit | a7981ec |
| HEAD_SHA | 变更结束 commit | 3df7661 |
| 变更文件列表 | git diff --name-only 的输出 | 文件列表 |
Special case：若变更文件列表包含
.agents/或.claude/路径，在 dispatch 时显式注明： "本次变更包含 skill/agent 配置文件，请额外执行维度 7（Skill/Agent 架构一致性）检查。"
按 receiving-code-review skill 的规范处理反馈。核心流程：
审查者返回结果
↓
判断结论
├── "通过" / "合规" → 继续后续工作
├── "需要修改" / "不合规"
│ ├── Critical → 立即修复，修完后重新 dispatch 同审查者
│ ├── Important → 合并前修复
│ └── Suggestion → 记录，可后续处理
└── "需要讨论" → 与用户讨论后决定
处理原则：
receiving-code-review skill）| Excuse | Reality |
|---|---|
| "改动小，跳过审查吧" | 模式 B 已经是最轻量路径，再跳就是裸奔 |
| "我自己看过一遍没问题" | 自审替代不了独立审查，上下文污染 |
| "先做质量审查，规格审查之后补" | 顺序不可颠倒——实现不合规时做质量审查是浪费 |
| "reviewer 说 Important，我觉得是 Suggestion" | 可以 push back，但要有技术理由，不是感觉 |
| "改完了，直接声明通过" | Critical/Important 修复后必须重新 dispatch，不可自判 |
subagent-driven-development 每任务完成后 + 全部完成后的全局审查spec-reviewer agent（.claude/agents/spec-reviewer.md）— 模式 A 第一阶段code-reviewer agent（.claude/agents/code-reviewer.md）— 模式 A 第二阶段 / 模式 B 唯一审查者verification-before-completion → finishing-a-development-branchreceiving-code-review 的 STOP-ASK / YAGNI / push back 规范