[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KSSXTZSZXDZECRJ6324R5F":3,"skill-same:01M6KSSXTZSZXDZECRJ6324R5F":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M6KSSXTZSZXDZECRJ6324R5F","pr-review",null,"对指定 PR 跑自动分级六维度 review（默认）；或 --check 模式验证上一轮 findings 是否修复 + 抓回归。按 diff 净增删行数自动分配 2\u002F3\u002F6 reviewer agent 并行（\u003C 200 行不派发，主 agent 自审）；主 agent 做根因聚类 + Cx 分级 + 修复分流建议，不自动 fix。","ghbvf\u002Fgocell","ghbvf","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F104540935?v=4","01M6KSS2CVFY1XK013726EE7ZP","01M6KSS2GJ30TNAVPNFATW578Q",4,"MIT","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Fpr-review\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32],"review","pr review","pr","Bash","grep","reviewer","check","read","fix","diff","2026-11-10 10:12:30",false,"---\nname: pr-review\ndescription: \"对指定 PR 跑自动分级六维度 review（默认）；或 --check 模式验证上一轮 findings 是否修复 + 抓回归。按 diff 净增删行数自动分配 2\u002F3\u002F6 reviewer agent 并行（\u003C 200 行不派发，主 agent 自审）；主 agent 做根因聚类 + Cx 分级 + 修复分流建议，不自动 fix。\"\nargument-hint: \"\u003CPR 编号> [--check]\"\nallowed-tools: [Read, Glob, Grep, Bash, Agent]\n---\n\n# GoCell PR Review — 自动分级六维度审查\n\n按 PR diff 净增删行数自动分配 2\u002F3\u002F6 个 `reviewer` agent 并行做六维度审查（\u003C 200 行不派发，主 agent 自审），主 agent 做根因聚类与修复分流建议。**只 review，不自动 fix**。\n\n---\n\n## 阶段 1：输入解析\n\n参数：`\u003CPR 编号> [--check]`。剥离 `--check` flag 后，剩余必须是 PR 编号（纯数字或 `#NNN`）。\n\n- 缺参 → 输出 `错误：缺少 PR 编号；用法：\u002Fpr-review \u003CPR 编号> [--check]`，不执行后续\n- 非法格式 → 输出 `错误：参数 \"\u003C原值>\" 不是合法 PR 编号`，不执行后续\n- **带 `--check`** → 走下方 **模式 B：--check 验证**（不跑全新六维 review），跑完即返回\n- **不带** → 走默认全新六维 review（阶段 2-6）\n\n---\n\n## 阶段 2：取 diff 行数\n\n```bash\ngh pr view \u003CN> --json additions,deletions --jq '.additions + .deletions'\n```\n\n取不到 PR → 报错退出。\n\n---\n\n## 阶段 2.5：定位或自动创建 review worktree\n\n```bash\nBRANCH=$(gh pr view \u003CN> --json headRefName --jq .headRefName)\ngit worktree list   # 从输出中找 [\u003CBRANCH>] 所在行，其首列路径即该分支 worktree，记为 WORKTREE；无匹配行 → 情况 B\n```\n\n**情况 A：找到既有 worktree** → 直接用 `$WORKTREE`，不动其状态。\n\n**情况 B：无既有 worktree** → 自动创建 review-only worktree：\n\n```bash\ngit fetch origin \u003CBRANCH>\ngit worktree add --detach worktrees\u002Freview-pr\u003CN> origin\u002F\u003CBRANCH>   # 已存在则改用 git -C ... reset --hard origin\u002F\u003CBRANCH> 刷新\nWORKTREE=\"$(git rev-parse --show-toplevel)\u002Fworktrees\u002Freview-pr\u003CN>\"\n```\n\n创建失败 → 报错退出，不静默回退。情况 B 在阶段 5 末尾追加：`? 清理：git worktree remove worktrees\u002Freview-pr\u003CN>`。\n\n---\n\n## 阶段 3：PR 元数据与规则上下文\n\n主 agent 必须先取一次 PR 元数据，供所有档位共用：\n\n```bash\ngh pr view \u003CN> --json title,body,files,headRefOid\n```\n\n以下读取全部以 `$WORKTREE` 为根；`gh pr view.files` 只提供 repo-relative path\n输入，不作为文件内容来源。\n\n必读：CLAUDE.md + `docs\u002Fguides\u002Fagent-instruction-surfaces.md` +\n`.github\u002Fproject-template\u002FPROJECT.md` §3（P\u002FCx 评级单源）+\n`.claude\u002Frules\u002Fgocell\u002F*.md`。rules 已瘦身，pr-review 阶段全量读取，避免本审查流程因条件过滤漏加载规则。\n\n---\n\n## 阶段 3.5：分级表\n\n**派发档位（reviewer 数 + 维度切分）单源 = `.claude\u002Fagents\u002Freviewer.md` §派发分档**，按阶段 2 的 diff 行数定档（区间左闭右开，边界归更高档）。\n\npr-review 的 `diff \u003C 200` 约定：不派发 sub-agent，主 agent 在阶段 3 的共享上下文内按 reviewer.md（六维度 \u002F Finding 格式 \u002F 评级）+ PROJECT.md §3 评级 rubric，在 `$WORKTREE` 上 Read\u002FGrep 自审，直接进入阶段 5。`diff ≥ 200` 按 §派发分档 派 2\u002F3\u002F6 个 reviewer。\n\n---\n\n## 阶段 4：并行派发 reviewer agent\n\n> `diff \u003C 200` 跳过本阶段，直接执行阶段 5。\n\n单消息内多 `Agent` tool call 并行启动 `subagent_type: reviewer`。\n\n每个 sub-agent prompt 必须自包含：\n\n- PR 编号 + 取 diff 命令 `gh pr diff \u003CN>` \u002F `gh pr view \u003CN> --json title,body,files,headRefOid`\n- 工作目录 `$WORKTREE` 绝对路径，所有 Read\u002FGrep 路径前缀 `$WORKTREE\u002F`\n- Finding 输出的 `文件:行号` 必须是 **repo-relative**（去掉 `$WORKTREE\u002F` 与 `worktrees\u002F\u003Cname>\u002F` 前缀），便于主 agent 汇总后排版\n- 分配的维度子集（见 reviewer.md §派发分档）\n- 必读：阶段 3 的共享上下文和全部 `.claude\u002Frules\u002Fgocell\u002F*.md`。\n- Finding 格式、Cx 分级、输出契约 → 沿用 `.claude\u002Fagents\u002Freviewer.md`\n\n---\n\n## 阶段 5：主 agent 分析与汇总\n\n收齐 Finding 后（`diff ≥ 200` 来自 sub-agent；`diff \u003C 200` 来自主 agent 自审），主 agent **必须自己读关键文件、做根因分析**，不允许原样转发。\n\n### 5.1 去重 \u002F 冲突裁决\n\n- 同 `文件:行号` + 同描述 → 重复，保留更详细一条\n- 同 `文件:行号` 不同 P 级 → 保留更高 P 级，Read 代码裁定是否降级\n- 同 `文件:行号` 不同 Cx → 按 5.2 整簇重评，不简单取大\n- 冲突结论（P0 vs LGTM）→ Read 代码亲自裁决\n\n### 5.2 根因归类（不允许跳过）\n\n按**共同根因**聚类（不按文件 \u002F 不按维度）。例：`errcode 未走 funnel` → 架构 + 安全 + DX 三维度同时被命中。\n\n`Grep` 验证系统性：≥ 3 处 = 架构缺陷，1-2 处 = 局部 bug。\n\n每簇标注：涉及维度 \u002F Finding 数（按 P 级拆分）\u002F 系统性（Grep 数）\u002F 整簇 Cx（按整簇改动量重评）。\n\n### 5.3 输出 5 块（**先打印到对话窗口给用户**，顺序固定）\n\n**输出语言**：中文。**这 5 块是主交付物——必须先在对话\u002F窗口完整打印给用户看**，阶段 6 再贴成 PR 评论留痕（窗口=主输出、评论=留痕，两者都做；输出纪律单源见 `PROJECT.md` §5）。\n\n1. **根因簇视图**（主输出）— 每簇：根因一句 \u002F 维度 \u002F Finding 数 \u002F 系统性 \u002F 整簇 Cx \u002F 子 Finding ID \u002F 修复顺序建议\n2. **Finding 详表** — list 形式（不用表格，避免 CJK 竖排）。按 P0→P2、同级 Cx1→Cx4 排序，每条两行：\n   - `**F{n}** [P·Cx·维度] repo-relative-path:line → 簇 C{m}`\n   - 缩进 2 空格的摘要 ≤ 60 字，纯文本，禁反引号包裹中文短语；详细建议放根因簇视图\n3. **复杂度汇总** — 按根因簇 + 按 Finding 两套：`Cx1: N \u002F Cx2: N \u002F Cx3: N \u002F Cx4: N`\n4. **修复分流** — Cx1\u002FCx2 簇 → `\u002Ffix`；Cx3\u002FCx4 簇 → \"需人工决策\" + 三级方案种子（最小\u002F彻底\u002F重构）。若 PR body（阶段 3 已取）含 GitHub closing keyword（`close[sd]?` \u002F `fix(e[sd])?` \u002F `resolve[sd]?` \u002F `refs`，大小写不敏感）后跟 `#\u003CN>`，分流条目附 `← issue #\u003CN>`\n5. **总体结论** — `通过 \u002F 需修复 \u002F 需讨论` + 一句话理由\n\n输出前自检：① 每个根因簇都 Read 过代表文件？② 根因到了根本层（不停在症状）？③ 系统性判定有 Grep 证据？— 任一不通过 → 补做。\n\n---\n\n## 阶段 6：贴 PR 评论（留痕，**不替代阶段 5 的窗口打印**）\n\n阶段 5 的五块**已打印到窗口后**，把**同一份内容**写进 `.github\u002Fproject-template\u002Fpr-comment.md` 的 `\u003C!-- pm:pr-review -->` 模板，**额外**贴成 PR 评论留痕（输出纪律 + 无损约定单源见 `PROJECT.md` §5 与 `pr-comment.md`：窗口=主输出、评论=留痕两者都做，每条 Finding 带 `file:line` + 详表入 `\u003Cdetails>` 供 `\u002Ffix` 无损提取），贴到 PR：\n\n贴评论命令 + **回显 comment URL\u002Fid** 的单源见 `issues` B4：\n\n```bash\nURL=$(gh pr comment \u003CN> --body-file \u003C填好的 pm:pr-review 模板>)   # stdout = https:\u002F\u002F...\u002Fpull\u002F\u003CN>#issuecomment-\u003Cid>\necho \"✅ 已贴评论：$URL\"                                           # 回显给用户（含 comment id）\n```\n\n贴失败（非 0 退出）则报错退出，不静默跳过。footer 格式见 `.github\u002Fproject-template\u002Fpr-comment.md`（PR#\u002F工具\u002F分支\u002Fworktree\u002Fsession，AI 自填）。\n\n**追加机器块**（贴评论前，接口见 `pr-comment.md` §机器块）：verdict 按结论取 `approved`（无 finding）\u002F `changes-requested`（有 finding）；`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=pr-review --pr=\u003CN> --phase=review --verdict=\u003C上> --findings='\u003C计数 json>'`（round carry \u002F refs \u002F 熔断全由 emit-block 派生），输出单行追加到填好的 `pm:pr-review` body 末尾再贴。`changes-requested` 且已达 3 轮上限时 emit-block 置 `next.agent=human`（熔断），窗口提示「review↔fix 已达 3 轮上限，转人工」。\n\n贴完按结论切 label（命令见 `issues` B3）：有 finding → `pr-review\u002Fchanges-requested` + `pr-status\u002Fneeds-fix`（5-state：review 出 changes-requested 始终切 needs-fix，清对侧 `pr-review\u002Fapproved` + `pr-status\u002Fneeds-review-again`）；无 finding → `pr-review\u002Fapproved` + `pr-status\u002Fready`（清 `pr-review\u002Fchanges-requested` + `pr-status\u002Fneeds-review-again`）。\n\n---\n\n## 模式 B：--check 验证（确认上一轮 findings 是否修复 + 抓回归）\n\n> `\u002Fpr-review \u003CPR#> --check` 走本模式：**不做全新六维 review**，只验证上一轮发现的问题是否真修复，并在这些站点抓 `\u002Ffix` 引入的回归。配 `pr-status\u002Fneeds-check-fix`（PROJECT.md §5：fix 不能自证完成，必过本验证才能 ready）。\n\n### B1 读上一轮 findings（无损源）\n\n**优先当前会话窗口**：同 session 内刚跑过 `\u002Fpr-review` 或 `\u002Ffix`、findings 已在上下文 → 直接用，不重复拉取。窗口没有 → `gh pr view \u003CN> --json comments,reviews`，按 createdAt 倒序锁定**最近一次 review findings**（codex review\u002Fcomment 或 `pm:pr-review` 的 `\u003Cdetails>` 无损详表，每条带 `file:line` + 证据 + 建议）+ 其后 `pm:fix`（fix 声称修了什么）。两者都无 → 报错退出（无可验证项）。\n\n**额外解析 OSS 集合**：经 `pm:fix` 的 `? OUT_OF_SCOPE（详见本 PR pm:oos 评论）` 指针入口，从**本 PR `pm:oos` 评论**取每条 OSS 记录（`file:line` + 已建 issue #N \u002F `deferred:\u003C原因>`）——pm:oos 是 OSS 的无损数据源，pm:fix 只是一行指针。据此认出上一轮被**声明为 OUT_OF_SCOPE** 的 finding，把上一轮 findings 拆成两组：**IN_SCOPE**（B3 验代码）与**被声明 OSS**（B3 评估分类是否合理，不验代码）。\n\n### B2 定位 worktree\n\n同 阶段 2.5（复用既有 worktree 或自动建 review-only worktree，读当前 head 代码）。\n\n### B3 逐条验证（Read 当前代码，只信代码）\n\n**IN_SCOPE finding**：在 `$WORKTREE` Read 其 `file:line` 现状判定：\n\n| 状态 | 判据 |\n|------|------|\n| ✅ 已修复 | 原问题代码已按建议改掉，证据充分 |\n| ❌ 未修复 | 原问题代码仍在（pm:fix 声称修了但实际没改） |\n| ⚠️ 回归 | 修了原问题，但在该站点 \u002F 调用链引入新问题（`Grep` 调用方确认） |\n| ? 部分 | 只修一部分 \u002F 留了 TODO |\n\n**每条必须 Read 实证，不凭 pm:fix 的\"已修\"自述**（review 只信代码，对齐 reviewer.md §Reasoning Blindness）。\n\n**被声明 OUT_OF_SCOPE 的 finding（两步，不盲信 OSS 标签）**：\n\n1. **评估分类是否合理**：Read finding 站点 + 本 PR diff（`gh pr diff \u003CN>`），判断它是否确为「与本 PR 改动无关的不同包 \u002F 模块」。\n   - **不合理**（实为 in-scope、本该随本 PR 一起修）→ 判 `❌ 误判OSS（应在本 PR 修）`，**计入 needs-fix**（不能用 OSS 标签把本该修的问题甩出去）。\n   - **合理** → 进第 2 步。\n2. **核 pm:oos 留痕**：已建 issue #N \u002F 显式 `deferred:\u003C原因>` → 标 `? OUT_OF_SCOPE(合理)`，**不计入 needs-fix**；合理但无留痕（应有却缺）→ 仍标 `?`、**不阻断 verdict**（backlog 跟踪缺口非代码缺陷），但在 B4 出**显式 action「OSS 合理但 pm:oos 未留痕，需补建 backlog issue（走 `issues` B1，由人工或下轮 `\u002Ffix` 的 OOS 流程补）」**——pr-review 只读不自建 issue，故只 flag 不创建。\n\n### B4 输出（窗口=主输出）\n\n1. **验证表**（主输出，逐条）：`F{n} [原 P·Cx·维度] repo-relative-path:line → ✅\u002F❌\u002F⚠️\u002F?\u002F? + 一句证据`\n2. **汇总**：已修复 N \u002F 未修复 M \u002F 回归 K \u002F 部分 J \u002F 范围外合理 R（?）\u002F 误判OSS S\n3. **结论 + 流转建议**（判定规则收敛）：`verdict=changes-requested ⟺ ∃（IN_SCOPE 为 ❌\u002F⚠️\u002F?）或（被声明 OSS 经评估不合理）`；合理 OSS（?）一律不触发。\n   - 无触发项 → 切 `pr-status\u002Fready` + `pr-review\u002Fapproved`\n   - 有触发项 → 切 `pr-review\u002Fchanges-requested` + `pr-status\u002Fneeds-fix`（5-state；清 `pr-review\u002Fapproved` + `pr-status\u002Fneeds-check-fix`），未修\u002F回归\u002F误判OSS 项带 `file:line` 回 `\u002Ffix`\n\n### B5 贴 pm:pr-review（--check 留痕）+ 切 label\n\n窗口打印 B4 后，贴 `pm:pr-review` 评论（--check 变体：每条 finding 带 ✅\u002F❌\u002F⚠️\u002F?\u002F? 状态替代簇归属，summary 用 已修复N\u002F未修复M\u002F回归K\u002F范围外合理R\u002F误判OSS S）——窗口=主输出、评论=留痕，两者都做（见 `PROJECT.md` §5）。**追加机器块**（贴评论前，接口见 `pr-comment.md` §机器块）：verdict 取 `ready`（无触发项，? 合理 OSS 不算）\u002F `changes-requested`（有 IN_SCOPE ❌\u002F⚠️\u002F? 或 误判OSS）；`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=pr-review --pr=\u003CN> --phase=check --verdict=\u003C上> --findings='\u003C标准计数 json：total\u002Ffixed\u002Funresolved\u002Fblocking\u002FbyP\u002FbyCx——合理 OSS(?) 归 unresolved「deferred\u002FOOS」、误判 OSS 归 blocking；范围外\u002F误判细分仅入上面人读 summary，不进 --findings（schema additionalProperties:false，加字段会被 emit-block 拒）>'`（round carry \u002F refs 全派生）追加到 body 末尾。命令 + 回显见 `issues` B4；再按 B4 结论切 label（命令见 `issues` B3）：无触发项 → `pr-status\u002Fready` + `pr-review\u002Fapproved`；有触发项 → `pr-review\u002Fchanges-requested` + `pr-status\u002Fneeds-fix`（5-state；清 `pr-review\u002Fapproved` + `pr-status\u002Fneeds-check-fix`）。\n\n---\n\n## 约束\n\n- 默认模式不调用 `\u002Ffix`，不写代码，不评 CI（贴 pm:pr-review 评论=留痕，不算改代码）\n- `--check` 模式同样不写代码 \u002F 不调 `\u002Ffix`；只读代码验证 + 贴评论 + 切 label（编排）\n\n---\n\n## 验证清单\n\n1. 缺参 \u002F 非法参数 → 立即输出错误，不执行后续\n2. 分级处理：`diff \u003C 200` 主 agent 自审不派发；`diff ≥ 200` 按行数派 2\u002F3\u002F6 个 reviewer agent（覆盖三档）\n3. 无 worktree 自动创建 `worktrees\u002Freview-pr\u003CN>`；既有 worktree 复用，不重建\n4. 主 agent 输出含 Read\u002FGrep 证据 + 根因簇视图先于 Finding 详表；维度名内部一致\n5. 阶段 6 贴 `\u003C!-- pm:pr-review -->` 评论（含 footer + 每条 finding 的 file:line）+ 回显 comment URL\u002Fid\n6. `--check` 模式：读上一轮 findings（拆 IN_SCOPE \u002F 被声明 OSS）→ IN_SCOPE 逐条 Read 验证 ✅\u002F❌\u002F⚠️\u002F?（含抓回归），被声明 OSS 评估分类合理性（合理 + 留痕 → ? 不计入；合理无留痕 → ? 不触发但出补建 action；误判 OSS → 计入 needs-fix）→ 窗口主输出验证表 + 贴 pm:pr-review（--check）→ 按 `changes-requested ⟺ IN_SCOPE 未修 或 误判OSS`（合理 ? 不触发）切 label（无触发 → ready+approved \u002F 有触发 → changes-requested+needs-fix，清 approved+needs-check-fix）\n","# GoCell PR Review — 自动分级六维度审查\n\n按 PR diff 净增删行数自动分配 2\u002F3\u002F6 个 `reviewer` agent 并行做六维度审查（\u003C 200 行不派发，主 agent 自审），主 agent 做根因聚类与修复分流建议。**只 review，不自动 fix**。\n\n---\n\n## 阶段 1：输入解析\n\n参数：`\u003CPR 编号> [--check]`。剥离 `--check` flag 后，剩余必须是 PR 编号（纯数字或 `#NNN`）。\n\n- 缺参 → 输出 `错误：缺少 PR 编号；用法：\u002Fpr-review \u003CPR 编号> [--check]`，不执行后续\n- 非法格式 → 输出 `错误：参数 \"\u003C原值>\" 不是合法 PR 编号`，不执行后续\n- **带 `--check`** → 走下方 **模式 B：--check 验证**（不跑全新六维 review），跑完即返回\n- **不带** → 走默认全新六维 review（阶段 2-6）\n\n---\n\n## 阶段 2：取 diff 行数\n\n```bash\ngh pr view \u003CN> --json additions,deletions --jq '.additions + .deletions'\n```\n\n取不到 PR → 报错退出。\n\n---\n\n## 阶段 2.5：定位或自动创建 review worktree\n\n```bash\nBRANCH=$(gh pr view \u003CN> --json headRefName --jq .headRefName)\ngit worktree list   # 从输出中找 [\u003CBRANCH>] 所在行，其首列路径即该分支 worktree，记为 WORKTREE；无匹配行 → 情况 B\n```\n\n**情况 A：找到既有 worktree** → 直接用 `$WORKTREE`，不动其状态。\n\n**情况 B：无既有 worktree** → 自动创建 review-only worktree：\n\n```bash\ngit fetch origin \u003CBRANCH>\ngit worktree add --detach worktrees\u002Freview-pr\u003CN> origin\u002F\u003CBRANCH>   # 已存在则改用 git -C ... reset --hard origin\u002F\u003CBRANCH> 刷新\nWORKTREE=\"$(git rev-parse --show-toplevel)\u002Fworktrees\u002Freview-pr\u003CN>\"\n```\n\n创建失败 → 报错退出，不静默回退。情况 B 在阶段 5 末尾追加：`? 清理：git worktree remove worktrees\u002Freview-pr\u003CN>`。\n\n---\n\n## 阶段 3：PR 元数据与规则上下文\n\n主 agent 必须先取一次 PR 元数据，供所有档位共用：\n\n```bash\ngh pr view \u003CN> --json title,body,files,headRefOid\n```\n\n以下读取全部以 `$WORKTREE` 为根；`gh pr view.files` 只提供 repo-relative path\n输入，不作为文件内容来源。\n\n必读：CLAUDE.md + `docs\u002Fguides\u002Fagent-instruction-surfaces.md` +\n`.github\u002Fproject-template\u002FPROJECT.md` §3（P\u002FCx 评级单源）+\n`.claude\u002Frules\u002Fgocell\u002F*.md`。rules 已瘦身，pr-review 阶段全量读取，避免本审查流程因条件过滤漏加载规则。\n\n---\n\n## 阶段 3.5：分级表\n\n**派发档位（reviewer 数 + 维度切分）单源 = `.claude\u002Fagents\u002Freviewer.md` §派发分档**，按阶段 2 的 diff 行数定档（区间左闭右开，边界归更高档）。\n\npr-review 的 `diff \u003C 200` 约定：不派发 sub-agent，主 agent 在阶段 3 的共享上下文内按 reviewer.md（六维度 \u002F Finding 格式 \u002F 评级）+ PROJECT.md §3 评级 rubric，在 `$WORKTREE` 上 Read\u002FGrep 自审，直接进入阶段 5。`diff ≥ 200` 按 §派发分档 派 2\u002F3\u002F6 个 reviewer。\n\n---\n\n## 阶段 4：并行派发 reviewer agent\n\n> `diff \u003C 200` 跳过本阶段，直接执行阶段 5。\n\n单消息内多 `Agent` tool call 并行启动 `subagent_type: reviewer`。\n\n每个 sub-agent prompt 必须自包含：\n\n- PR 编号 + 取 diff 命令 `gh pr diff \u003CN>` \u002F `gh pr view \u003CN> --json title,body,files,headRefOid`\n- 工作目录 `$WORKTREE` 绝对路径，所有 Read\u002FGrep 路径前缀 `$WORKTREE\u002F`\n- Finding 输出的 `文件:行号` 必须是 **repo-relative**（去掉 `$WORKTREE\u002F` 与 `worktrees\u002F\u003Cname>\u002F` 前缀），便于主 agent 汇总后排版\n- 分配的维度子集（见 reviewer.md §派发分档）\n- 必读：阶段 3 的共享上下文和全部 `.claude\u002Frules\u002Fgocell\u002F*.md`。\n- Finding 格式、Cx 分级、输出契约 → 沿用 `.claude\u002Fagents\u002Freviewer.md`\n\n---\n\n## 阶段 5：主 agent 分析与汇总\n\n收齐 Finding 后（`diff ≥ 200` 来自 sub-agent；`diff \u003C 200` 来自主 agent 自审），主 agent **必须自己读关键文件、做根因分析**，不允许原样转发。\n\n### 5.1 去重 \u002F 冲突裁决\n\n- 同 `文件:行号` + 同描述 → 重复，保留更详细一条\n- 同 `文件:行号` 不同 P 级 → 保留更高 P 级，Read 代码裁定是否降级\n- 同 `文件:行号` 不同 Cx → 按 5.2 整簇重评，不简单取大\n- 冲突结论（P0 vs LGTM）→ Read 代码亲自裁决\n\n### 5.2 根因归类（不允许跳过）\n\n按**共同根因**聚类（不按文件 \u002F 不按维度）。例：`errcode 未走 funnel` → 架构 + 安全 + DX 三维度同时被命中。\n\n`Grep` 验证系统性：≥ 3 处 = 架构缺陷，1-2 处 = 局部 bug。\n\n每簇标注：涉及维度 \u002F Finding 数（按 P 级拆分）\u002F 系统性（Grep 数）\u002F 整簇 Cx（按整簇改动量重评）。\n\n### 5.3 输出 5 块（**先打印到对话窗口给用户**，顺序固定）\n\n**输出语言**：中文。**这 5 块是主交付物——必须先在对话\u002F窗口完整打印给用户看**，阶段 6 再贴成 PR 评论留痕（窗口=主输出、评论=留痕，两者都做；输出纪律单源见 `PROJECT.md` §5）。\n\n1. **根因簇视图**（主输出）— 每簇：根因一句 \u002F 维度 \u002F Finding 数 \u002F 系统性 \u002F 整簇 Cx \u002F 子 Finding ID \u002F 修复顺序建议\n2. **Finding 详表** — list 形式（不用表格，避免 CJK 竖排）。按 P0→P2、同级 Cx1→Cx4 排序，每条两行：\n   - `**F{n}** [P·Cx·维度] repo-relative-path:line → 簇 C{m}`\n   - 缩进 2 空格的摘要 ≤ 60 字，纯文本，禁反引号包裹中文短语；详细建议放根因簇视图\n3. **复杂度汇总** — 按根因簇 + 按 Finding 两套：`Cx1: N \u002F Cx2: N \u002F Cx3: N \u002F Cx4: N`\n4. **修复分流** — Cx1\u002FCx2 簇 → `\u002Ffix`；Cx3\u002FCx4 簇 → \"需人工决策\" + 三级方案种子（最小\u002F彻底\u002F重构）。若 PR body（阶段 3 已取）含 GitHub closing keyword（`close[sd]?` \u002F `fix(e[sd])?` \u002F `resolve[sd]?` \u002F `refs`，大小写不敏感）后跟 `#\u003CN>`，分流条目附 `← issue #\u003CN>`\n5. **总体结论** — `通过 \u002F 需修复 \u002F 需讨论` + 一句话理由\n\n输出前自检：① 每个根因簇都 Read 过代表文件？② 根因到了根本层（不停在症状）？③ 系统性判定有 Grep 证据？— 任一不通过 → 补做。\n\n---\n\n## 阶段 6：贴 PR 评论（留痕，**不替代阶段 5 的窗口打印**）\n\n阶段 5 的五块**已打印到窗口后**，把**同一份内容**写进 `.github\u002Fproject-template\u002Fpr-comment.md` 的 `\u003C!-- pm:pr-review -->` 模板，**额外**贴成 PR 评论留痕（输出纪律 + 无损约定单源见 `PROJECT.md` §5 与 `pr-comment.md`：窗口=主输出、评论=留痕两者都做，每条 Finding 带 `file:line` + 详表入 `\u003Cdetails>` 供 `\u002Ffix` 无损提取），贴到 PR：\n\n贴评论命令 + **回显 comment URL\u002Fid** 的单源见 `issues` B4：\n\n```bash\nURL=$(gh pr comment \u003CN> --body-file \u003C填好的 pm:pr-review 模板>)   # stdout = https:\u002F\u002F...\u002Fpull\u002F\u003CN>#issuecomment-\u003Cid>\necho \"✅ 已贴评论：$URL\"                                           # 回显给用户（含 comment id）\n```\n\n贴失败（非 0 退出）则报错退出，不静默跳过。footer 格式见 `.github\u002Fproject-template\u002Fpr-comment.md`（PR#\u002F工具\u002F分支\u002Fworktree\u002Fsession，AI 自填）。\n\n**追加机器块**（贴评论前，接口见 `pr-comment.md` §机器块）：verdict 按结论取 `approved`（无 finding）\u002F `changes-requested`（有 finding）；`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=pr-review --pr=\u003CN> --phase=review --verdict=\u003C上> --findings='\u003C计数 json>'`（round carry \u002F refs \u002F 熔断全由 emit-block 派生），输出单行追加到填好的 `pm:pr-review` body 末尾再贴。`changes-requested` 且已达 3 轮上限时 emit-block 置 `next.agent=human`（熔断），窗口提示「review↔fix 已达 3 轮上限，转人工」。\n\n贴完按结论切 label（命令见 `issues` B3）：有 finding → `pr-review\u002Fchanges-requested` + `pr-status\u002Fneeds-fix`（5-state：review 出 changes-requested 始终切 needs-fix，清对侧 `pr-review\u002Fapproved` + `pr-status\u002Fneeds-review-again`）；无 finding → `pr-review\u002Fapproved` + `pr-status\u002Fready`（清 `pr-review\u002Fchanges-requested` + `pr-status\u002Fneeds-review-again`）。\n\n---\n\n## 模式 B：--check 验证（确认上一轮 findings 是否修复 + 抓回归）\n\n> `\u002Fpr-review \u003CPR#> --check` 走本模式：**不做全新六维 review**，只验证上一轮发现的问题是否真修复，并在这些站点抓 `\u002Ffix` 引入的回归。配 `pr-status\u002Fneeds-check-fix`（PROJECT.md §5：fix 不能自证完成，必过本验证才能 ready）。\n\n### B1 读上一轮 findings（无损源）\n\n**优先当前会话窗口**：同 session 内刚跑过 `\u002Fpr-review` 或 `\u002Ffix`、findings 已在上下文 → 直接用，不重复拉取。窗口没有 → `gh pr view \u003CN> --json comments,reviews`，按 createdAt 倒序锁定**最近一次 review findings**（codex review\u002Fcomment 或 `pm:pr-review` 的 `\u003Cdetails>` 无损详表，每条带 `file:line` + 证据 + 建议）+ 其后 `pm:fix`（fix 声称修了什么）。两者都无 → 报错退出（无可验证项）。\n\n**额外解析 OSS 集合**：经 `pm:fix` 的 `? OUT_OF_SCOPE（详见本 PR pm:oos 评论）` 指针入口，从**本 PR `pm:oos` 评论**取每条 OSS 记录（`file:line` + 已建 issue #N \u002F `deferred:\u003C原因>`）——pm:oos 是 OSS 的无损数据源，pm:fix 只是一行指针。据此认出上一轮被**声明为 OUT_OF_SCOPE** 的 finding，把上一轮 findings 拆成两组：**IN_SCOPE**（B3 验代码）与**被声明 OSS**（B3 评估分类是否合理，不验代码）。\n\n### B2 定位 worktree\n\n同 阶段 2.5（复用既有 worktree 或自动建 review-only worktree，读当前 head 代码）。\n\n### B3 逐条验证（Read 当前代码，只信代码）\n\n**IN_SCOPE finding**：在 `$WORKTREE` Read 其 `file:line` 现状判定：\n\n| 状态 | 判据 |\n|------|------|\n| ✅ 已修复 | 原问题代码已按建议改掉，证据充分 |\n| ❌ 未修复 | 原问题代码仍在（pm:fix 声称修了但实际没改） |\n| ⚠️ 回归 | 修了原问题，但在该站点 \u002F 调用链引入新问题（`Grep` 调用方确认） |\n| ? 部分 | 只修一部分 \u002F 留了 TODO |\n\n**每条必须 Read 实证，不凭 pm:fix 的\"已修\"自述**（review 只信代码，对齐 reviewer.md §Reasoning Blindness）。\n\n**被声明 OUT_OF_SCOPE 的 finding（两步，不盲信 OSS 标签）**：\n\n1. **评估分类是否合理**：Read finding 站点 + 本 PR diff（`gh pr diff \u003CN>`），判断它是否确为「与本 PR 改动无关的不同包 \u002F 模块」。\n   - **不合理**（实为 in-scope、本该随本 PR 一起修）→ 判 `❌ 误判OSS（应在本 PR 修）`，**计入 needs-fix**（不能用 OSS 标签把本该修的问题甩出去）。\n   - **合理** → 进第 2 步。\n2. **核 pm:oos 留痕**：已建 issue #N \u002F 显式 `deferred:\u003C原因>` → 标 `? OUT_OF_SCOPE(合理)`，**不计入 needs-fix**；合理但无留痕（应有却缺）→ 仍标 `?`、**不阻断 verdict**（backlog 跟踪缺口非代码缺陷），但在 B4 出**显式 action「OSS 合理但 pm:oos 未留痕，需补建 backlog issue（走 `issues` B1，由人工或下轮 `\u002Ffix` 的 OOS 流程补）」**——pr-review 只读不自建 issue，故只 flag 不创建。\n\n### B4 输出（窗口=主输出）\n\n1. **验证表**（主输出，逐条）：`F{n} [原 P·Cx·维度] repo-relative-path:line → ✅\u002F❌\u002F⚠️\u002F?\u002F? + 一句证据`\n2. **汇总**：已修复 N \u002F 未修复 M \u002F 回归 K \u002F 部分 J \u002F 范围外合理 R（?）\u002F 误判OSS S\n3. **结论 + 流转建议**（判定规则收敛）：`verdict=changes-requested ⟺ ∃（IN_SCOPE 为 ❌\u002F⚠️\u002F?）或（被声明 OSS 经评估不合理）`；合理 OSS（?）一律不触发。\n   - 无触发项 → 切 `pr-status\u002Fready` + `pr-review\u002Fapproved`\n   - 有触发项 → 切 `pr-review\u002Fchanges-requested` + `pr-status\u002Fneeds-fix`（5-state；清 `pr-review\u002Fapproved` + `pr-status\u002Fneeds-check-fix`），未修\u002F回归\u002F误判OSS 项带 `file:line` 回 `\u002Ffix`\n\n### B5 贴 pm:pr-review（--check 留痕）+ 切 label\n\n窗口打印 B4 后，贴 `pm:pr-review` 评论（--check 变体：每条 finding 带 ✅\u002F❌\u002F⚠️\u002F?\u002F? 状态替代簇归属，summary 用 已修复N\u002F未修复M\u002F回归K\u002F范围外合理R\u002F误判OSS S）——窗口=主输出、评论=留痕，两者都做（见 `PROJECT.md` §5）。**追加机器块**（贴评论前，接口见 `pr-comment.md` §机器块）：verdict 取 `ready`（无触发项，? 合理 OSS 不算）\u002F `changes-requested`（有 IN_SCOPE ❌\u002F⚠️\u002F? 或 误判OSS）；`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=pr-review --pr=\u003CN> --phase=check --verdict=\u003C上> --findings='\u003C标准计数 json：total\u002Ffixed\u002Funresolved\u002Fblocking\u002FbyP\u002FbyCx——合理 OSS(?) 归 unresolved「deferred\u002FOOS」、误判 OSS 归 blocking；范围外\u002F误判细分仅入上面人读 summary，不进 --findings（schema additionalProperties:false，加字段会被 emit-block 拒）>'`（round carry \u002F refs 全派生）追加到 body 末尾。命令 + 回显见 `issues` B4；再按 B4 结论切 label（命令见 `issues` B3）：无触发项 → `pr-status\u002Fready` + `pr-review\u002Fapproved`；有触发项 → `pr-review\u002Fchanges-requested` + `pr-status\u002Fneeds-fix`（5-state；清 `pr-review\u002Fapproved` + `pr-status\u002Fneeds-check-fix`）。\n\n---\n\n## 约束\n\n- 默认模式不调用 `\u002Ffix`，不写代码，不评 CI（贴 pm:pr-review 评论=留痕，不算改代码）\n- `--check` 模式同样不写代码 \u002F 不调 `\u002Ffix`；只读代码验证 + 贴评论 + 切 label（编排）\n\n---\n\n## 验证清单\n\n1. 缺参 \u002F 非法参数 → 立即输出错误，不执行后续\n2. 分级处理：`diff \u003C 200` 主 agent 自审不派发；`diff ≥ 200` 按行数派 2\u002F3\u002F6 个 reviewer agent（覆盖三档）\n3. 无 worktree 自动创建 `worktrees\u002Freview-pr\u003CN>`；既有 worktree 复用，不重建\n4. 主 agent 输出含 Read\u002FGrep 证据 + 根因簇视图先于 Finding 详表；维度名内部一致\n5. 阶段 6 贴 `\u003C!-- pm:pr-review -->` 评论（含 footer + 每条 finding 的 file:line）+ 回显 comment URL\u002Fid\n6. `--check` 模式：读上一轮 findings（拆 IN_SCOPE \u002F 被声明 OSS）→ IN_SCOPE 逐条 Read 验证 ✅\u002F❌\u002F⚠️\u002F?（含抓回归），被声明 OSS 评估分类合理性（合理 + 留痕 → ? 不计入；合理无留痕 → ? 不触发但出补建 action；误判 OSS → 计入 needs-fix）→ 窗口主输出验证表 + 贴 pm:pr-review（--check）→ 按 `changes-requested ⟺ IN_SCOPE 未修 或 误判OSS`（合理 ? 不触发）切 label（无触发 → ready+approved \u002F 有触发 → changes-requested+needs-fix，清 approved+needs-check-fix）\n",{"name":5,"description":7,"allowed-tools":38,"argument-hint":43},[39,40,41,26,42],"Read","Glob","Grep","Agent","\u003CPR 编号> [--check]","develop","043add59bbe840e4a90a4253feec21f074b590dd",".claude\u002Fskills\u002Fpr-review",0,"https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell","https:\u002F\u002Fgithub.com\u002Fghbvf","2026-06-20 14:38:06",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add ghbvf\u002Fgocell --skill pr-review",{"tool":57,"command":58},"bunx","bunx skills add ghbvf\u002Fgocell --skill pr-review",{"tool":60,"command":61},"pnpm","pnpm dlx skills add ghbvf\u002Fgocell --skill pr-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Fpr-review\u002FSKILL.md",true,[],[66,80,86,107,117,124],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":33},"01M6KSVEVMZN9HK0ZRVY3MEJEJ","ship","全流程实施：探索→计划→worktree→TDD→实施→PR→review→\u002Ffix Cx1\u002FCx2→人工确认。L1(跳过探索,1 reviewer)\u002FL2(单agent探索,1 reviewer)\u002FL3(默认,三agent探索,按diff行数1\u002F2\u002F3\u002F6 reviewer自动)","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Fship\u002FSKILL.md",[],[68,26,73,74,75,31,76,77,30,28,27,78,25,79,23],"l2","id","backlog","edit","write","worktree","tdd",{"skillNo":81,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":85,"publishedAt":33},"01M6KSVCP8NB3095MY8M2BR235","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Fpr-review\u002FSKILL.md",[84],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[25,24,23,27,26,29,28,32,31,30],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":33},"01M6KSV8P4AYPNHCDR1T7B9YN5","issues","GitHub Issues + Project v2 #3 项目管理单源技能。Part A：epic 拆解 + wave 实施顺序评论（找子任务 → blocked-by DAG → wave 1-4 容量装箱排序：每 wave ≤4、pri 优先、wave 内切并行组\u002F串行链、OPEN 重排、已完成与超窗单列 → 只追加 epic 评论；不写 Project 字段、不改 epic body）。Part B：issue\u002FPR 原子操作（建\u002F改 backlog issue、area\u002Ftype\u002Fpri label、PR 双轴状态 label 流转、统一 PR 评论格式 + 冲突预检\u002FCI watch 跟进，ship\u002Ffix 共用）。非 epic issue 号 → 查代码判状态（只判不修，建议 \u002Fship 或 close）。当用户要整理 epic 排 wave、建\u002F改 backlog issue、贴 label、切 PR 状态、给 PR 留评论、核一个 issue 是否还成立时使用。","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Fissues\u002FSKILL.md",[],[88,93,94,95,96,97,98,99,100,101,26,102,31,30,103,104,105,25,106,75],"项目管理","create-issue","labels","整理","EPIC","close","ci watch","type","project","github","open","ci","create","dag",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":33},"01M6KSV7CX440Q82S9VXQJH02G","git-worktree","Git Worktree 项目约定（编号、基准分支、权限兼容、删除安全）。","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Fgit-worktree\u002FSKILL.md",[],[114,78,115,116],"git","git worktree","安全",{"skillNo":118,"name":31,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":33},"01M6KSV5JB0AR3EJ9V2H4F2MN2","问题诊断与修复: 验证+根因+复杂度分级+修复方案+backlog登记。当用户说'这个问题存在吗''帮我分析这个bug''诊断一下这个模块''修复这个问题'时触发。支持单条问题和多方审查报告批量输入。","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Ffix\u002FSKILL.md",[],[31,123,76,77,30,27,26],"文件",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":33},"01M6KSV2S9ZK6BM2K1P2V3E4HK","speckit-taskstoissues","Convert existing tasks into actionable, dependency-ordered GitHub issues for the feature based on available design artifacts.","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Fspeckit-taskstoissues\u002FSKILL.md",[],[131,132,133,134,135,136,137,138,139,140,101,141,142,143,88,144,145,146,102,147],"speckit taskstoissues","speckit","structure","for","true","kit","with","spec-kit","actionable","feature","Existing","convert","specify","artifacts","tasks","project structure","design"]