ryanzhao1011
ryanzhao1011/workframe
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ryanzhao1011/workframe --skill code-review命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | code-review |
| description | 代码审查，从需求符合度/正确性/安全性/可维护性/性能五维度评审代码变更，输出风险分级的 Finding 列表 |
| when_to_use | 用于代码变更评审、PR review、实现与 spec/PRD 的一致性核对、五维度质量审查时调用。 典型触发："审查代码" / "PR review" / "看一下这段代码" / "代码合规吗" / "评估实现是否符合需求" / "代码和 PRD 对不对得上" / "有没有明显 bug 或缺陷" / "研发交付的代码帮我看下"。 不用于：bug 的根因定位与修复方案（用 systematic-debugging——但**发现** bug 属于本 skill）/ 编码本身（用 technical-design 完整路径段）/ 功能测试（用 test-case-design）。 |
| user-invocable | true |
| allowed-tools | ["Read","Glob","Grep","Bash"] |
审查结论默认只在响应中呈现。用户要求存档时按 skill: document-norms §1 落
projects/modules/<basic>/<sub>/requirements/<req_slug>/<sub_req_slug>/reviews/；
发现的缺陷若需跟踪，走 projects/issues/ + board task 草稿（不直接写 board）。
读取代码变更（diff 或指定文件），识别：
| 维度 | 内容 |
|---|---|
| 改动文件 | 新增/修改/删除的文件清单 |
| 改动范围 | 每个文件的具体改动行数和函数 |
| 影响模块 | 直接调用改动代码的其他模块 |
| 依赖变化 | 新增/移除的依赖关系 |
前提：先拿到规范资产（PRD 正文 / AC / spec / 词表 / 接口约定），逐条比对，不能只看 AC —— AC 是抽样，正文才是全量口径。
| 审查点 | 检查内容 |
|---|---|
| 规则落地 | 规范正文写明的每条规则，代码是否实现且口径一致 |
| 缺漏 | 规范写了、代码没做（含只做了一半、静默降级、开关/埋点等非功能要求） |
| 超纲 | 代码做了、规范没写（自行发挥的逻辑，需回溯确认） |
| 规范空白 | 规范本身没定，代码"忠实实现了不完整的规则" —— 不算实现错误，退回需求侧补口径 |
| 已符合项 | 明确列出实现正确的部分，供修其他问题时防误伤 |
「规范空白」与「缺漏」必须分开报：前者要 PM/需求方先拍板，研发改了也是白改；后者研发直接修。
| 审查点 | 检查内容 |
|---|---|
| 逻辑正确 | 代码实现是否符合需求/AC |
| 边界处理 | 空值、零值、极值、负数等边界条件 |
| 错误处理 | 异常捕获、错误返回、失败恢复 |
| 并发安全 | 竞态条件、死锁、共享状态 |
| 类型安全 | 类型断言、null 检查 |
| 审查点 | 检查内容 |
|---|---|
| 注入风险 | SQL 注入、命令注入、XSS |
| 权限校验 | 未登录访问、越权访问 |
| 敏感信息 | 密码/密钥泄露、日志打印敏感数据 |
| 输入校验 | 未校验的用户输入、文件上传 |
| 依赖安全 | 已知漏洞的依赖库 |
| 审查点 | 检查内容 |
|---|---|
| 命名清晰 | 变量、函数、类名能自解释 |
| 结构清晰 | 单一职责、合理抽象、避免过深嵌套 |
| 注释充分 | 复杂逻辑有解释，公开接口有文档 |
| 代码复用 | 避免重复代码，合理提取公共函数 |
| 测试覆盖 | 关键逻辑有测试 |
| 审查点 | 检查内容 |
|---|---|
| 算法复杂度 | O(n²) 或更差的循环 |
| 数据库查询 | N+1 查询、缺失索引、全表扫描 |
| 网络请求 | 串行请求应并行、缺失缓存 |
| 内存使用 | 大对象加载、内存泄漏 |
| IO 操作 | 同步阻塞 IO、文件句柄泄漏 |
每个 Finding 打两个正交标签：风险级别（多急）+ 依据来源（凭什么）。
风险级别：
| 级别 | 含义 | 处理要求 |
|---|---|---|
| Critical | 必须修复 | 阻塞合并/发布，P0 问题 |
| Warning | 建议修复 | 下次迭代或同一 PR 修复 |
| Info | 建议改进 | 记录待办，不阻塞 |
依据来源（决定谁来处理、能不能拒绝）：
| 来源 | 含义 | 处理方 |
|---|---|---|
| 违反规范 | 规范 / spec / PRD 明文写了，实现没做到 | 实现方直接修，无需再讨论口径 |
| 规范空白 | 规范本身没定，实现只是「忠实实现了不完整的规则」 | 需求方先补口径，实现方此时改了也可能白改 |
| 审查者判断 | 无规范依据，属审查者的经验或偏好（架构选型、分层、工程实践） | 建议性质，实现方可拒绝；单独分区，不与前两类混排 |
审查方通常看不到对方的发版流程、依赖约束、历史包袱，架构决策权在实现方。把「我认为这样更好」和「你违反了确认过的规范」混在一起报，会稀释真缺陷的紧迫感。
## 代码审查报告：{Task-ID / PR-ID}
### 审查范围
- 改动文件：{N} 个
- 改动行数：+{N} / -{N}
- 审查维度：需求符合度 / 正确性 / 安全性 / 可维护性 / 性能
- 比对的规范资产：{PRD / spec / 词表 / 接口约定，列出文件与版本}
### 已确认符合的部分（修其他问题时勿破坏）
- {规范条目} — {实现位置}
### Finding 列表（依据来源 = 违反规范）
#### 🔴 Critical ({N})
- **F-001**: {描述} — `文件:行号`
- 依据：{PRD §X / spec 明文 / 团队规范}
- 问题：{具体问题}
- 建议：{修复建议}
#### 🟡 Warning ({N})
- **F-002**: {描述} — `文件:行号`
- 依据 / 问题 / 建议：{...}
#### 🔵 Info ({N})
- **F-003**: {描述} — `文件:行号`
### 需求方待定（依据来源 = 规范空白，{N}）
- **N-001**: {描述} — 规范未定；当前实现 {现状}；备选 {a} / {b}，需 {需求方} 拍板后再排期
### 审查者建议（依据来源 = 审查者判断，可拒绝，{N}）
- **S-001**: {描述} — 无规范依据，属工程偏好，最终方案由实现方按自身约束判断
### 审查结论
- ✅ **通过** — 无 Critical，Warning ≤2
- ⚠️ **有条件通过** — 无 Critical，但有 Warning 需后续修复
- ❌ **不通过** — 有 Critical，必须修复后重新审查