[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KSSCA440EY2WKHGRRKNESY":3,"skill-same:01M6KSSCA440EY2WKHGRRKNESY":71},{"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":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6KSSCA440EY2WKHGRRKNESY","fix",null,"问题诊断与修复: 验证+根因+复杂度分级+修复方案+backlog登记。当用户说'这个问题存在吗''帮我分析这个bug''诊断一下这个模块''修复这个问题'时触发。输入优先 PR 号（自动读 PR 评论），也支持 文件:行号 \u002F 自然语言；多 findings 自动批量。issue 号不再受理——issue triage 走 `issues` 技能（建议 \u002Fship 或 close）。","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\u002Ffix\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[5,23,24,25,26,27,28,29,30,31,32,33,34,35],"triage","pr","issue triage","issues","ship","Bash","grep","read","write","edit","issue","close","文件","2026-11-10 10:12:30",false,"---\nname: fix\ndescription: \"问题诊断与修复: 验证+根因+复杂度分级+修复方案+backlog登记。当用户说'这个问题存在吗''帮我分析这个bug''诊断一下这个模块''修复这个问题'时触发。输入优先 PR 号（自动读 PR 评论），也支持 文件:行号 \u002F 自然语言；多 findings 自动批量。issue 号不再受理——issue triage 走 `issues` 技能（建议 \u002Fship 或 close）。\"\nargument-hint: \"\u003C#PR | 文件:行号 | 问题描述>\"\nallowed-tools: [Read, Write, Edit, Glob, Grep, Bash, Agent, AskUserQuestion]\n---\n\n# 问题诊断与修复\n\n> 真源 = GitHub Issues + Project v2 #3；label \u002F 评级 rubric（P + Cx）见 `.github\u002Fproject-template\u002FPROJECT.md`；issue\u002FPR\u002Flabel\u002F评论原子操作规范见 `issues`（Part B）。\n\n---\n\n## 输入解析\n优先级：**PR 号**（裸数字先按 PR 试 → `gh pr view \u003CN> --json reviews,comments` 读对话评论 + review 摘要（每条带 body\u002Fid\u002Furl\u002FcreatedAt）；再 `gh api repos\u002Fghbvf\u002Fgocell\u002Fpulls\u002F\u003CN>\u002Fcomments --jq length` 探 inline review comments，>0 则 `gh api ...\u002Fpulls\u002F\u003CN>\u002Fcomments` 一并读入（codex\u002F人的 inline finding 不静默漏），=0（本仓常态）跳过；**只取最新一轮**——findings 源 = **最后一条 `\u003C!-- pm:pr-review -->` 评论**（按 createdAt 倒序取首个带该 marker 的评论：`gh pr view \u003CN> --json comments --jq '[.comments[]|select(.body|startswith(\"\u003C!-- pm:pr-review -->\"))]|sort_by(.createdAt)|last|.body'`），其 `\u003Cdetails>` 无损详表即本轮 findings；无 `pm:pr-review` 时回退取最新一条 codex review\u002Fcomment。**跳过**自己上一轮的 `pm:ship`\u002F`pm:fix`\u002F`pm:ci`\u002F`pm:oos` 留痕（已处理）与早于该最新 review 的旧 `pm:pr-review`，**不回头处理上一轮已 triage 的 findings**）> **文件:行号** > **自然语言**（Grep\u002FGlob）。**issue 号不再受理**——裸数字一律先按 PR 解析；issue 状态核查 + triage 收敛到 `issues` 技能（判定后建议 `\u002Fship #\u003CN>` 或 file:line）。\n\n---\n\n## 阶段 1: 问题定位\n\n### 1.1 找到问题代码\n\n按精度递进：明确路径 → Read；模糊描述 → Grep 类型\u002F方法签名 → Grep 错误码\u002F注释 → Agent(Explore) 调用图。三层均无果 → AskUserQuestion。\n\n### 1.2 追踪调用链 + 数据流\n\n从问题代码向上（调用方）和向下（被调用方）追踪。跨 3+ 包用 Agent(Explore)。\n同时追踪数据流：数据源 → 变换 → 消费者。\n\n### 1.3 确认问题是否存在\n\n| 状态 | 含义 | 下一步 |\n|------|------|--------|\n| **CONFIRMED** | 问题真实存在，可以复现 | → 进入阶段 2 |\n| **RESOLVED** | 问题已被修复（给出证据：哪行代码、哪个 PR） | → 向用户报告，结束 |\n| **CHANGED** | 代码重构过，问题形态变化 | → 向用户描述新形态，确认是否继续 |\n| **CANNOT_VERIFY** | 无法确认（缺少上下文、需要运行时验证） | → AskUserQuestion 请求更多信息 |\n\n输出含：状态 \u002F 位置 \u002F 调用链 \u002F 数据流 \u002F 问题描述（自己总结，不照搬 backlog）。\n\n### 1.4 复现测试（Reproduction Test First）\n\nCONFIRMED 后、修复前，先构造一个能**复现问题**的测试用例：\n\n1. 基于调用链和数据流分析，编写最小测试用例触发问题\n2. 运行测试确认 FAIL（证明问题可复现）\n3. 将此测试作为修复验收标准\n\n| 场景 | 操作 |\n|------|------|\n| 已有测试可稍加修改复现 | 修改已有测试 + 确认 FAIL |\n| 需新写测试 | 在 `_test.go` 新增 `TestXxx_Bug描述` |\n| 并发问题 | 写 `go test -race` 可触发的竞态测试 |\n| 无法在单测中复现（需运行时状态） | 标注 `RUNTIME_ONLY`，跳过此步 |\n\n---\n\n## 阶段 2: 根因分析 + 复杂度分级（CONFIRMED 后执行）\n\n### 2.1 根因三维度\n\n- **代码层面**: 哪行代码、哪个设计决策导致的\n- **架构层面**: 是否系统性（Grep 同模式，1 处=局部，3+=架构缺陷）。架构缺陷 → AskUserQuestion 确认局部修还是系统性重构\n- **历史层面**: git log 搜索同类已有修复，发现团队惯例，避免退化\n\n### 2.2 影响范围\n\n直接影响 \u002F 间接影响（列出受影响文件）\u002F 同类问题（Grep 相同模式数量）\n\n### 2.3 复杂度分级\n\n**必须对问题做复杂度判定**，决定后续方案形态（方案数见 3.1）。**Cx1-4 定义单源在 `.github\u002Fproject-template\u002FPROJECT.md` §3.2**（= 改动量\u002F实现风险，本技能不复制）。\n\n> Cx1 表示\"容易修\"，不代表\"不重要\"。IN_SCOPE\u002FOUT_OF_SCOPE 由文件归属（阶段 2.4）决定，与 Cx 等级无关——Cx1 也可以是 IN_SCOPE 且必须修。\n\n判定依据（按顺序检查）：\n1. 修复涉及多少个文件？（`Grep` 搜索所有受影响的调用点）\n2. 是否需要修改 `kernel\u002F` 层的接口或类型？\n3. 是否需要修改数据库 schema（migration）？\n4. 是否影响 wire\u002Fbootstrap 层的组装逻辑？\n5. 同类问题在其他模块是否重复出现？（1 处=局部，3+=系统性）\n\n### 2.4 当前分支归属判定\n\n判断问题是否属于**当前分支\u002FPR 的修复范围**。默认在当前分支处理。\n\n**判定方法：**\n1. `git diff --name-only origin\u002Fdevelop...HEAD` — 获取当前分支改动的文件列表\n2. 对比 finding 涉及的文件是否在这个列表中\n3. 如果当前分支有关联 PR（`gh pr view --json title,body`），检查 PR 描述是否包含该 finding 的 ID 或关键词\n\n**判定结果：**\n\n| 结果 | 判定条件（按文件归属快速判） | 下一步 |\n|------|---------|--------|\n| **IN_SCOPE** | finding 文件在当前分支 diff 中，或 PR 描述含该 finding ID | 在当前分支修复 |\n| **RELATED** | 不在 diff 中但同包 \u002F 同子系统遗留 | 建议搭车修，标注\"搭车\" |\n| **OUT_OF_SCOPE** | 完全不同的包 \u002F 模块 | 不在当前分支修；自动建 backlog issue（4.6 step 3；pri-p0\u002F标签判不定除外） |\n\n输出含：代码\u002F架构\u002F历史三维度根因、复杂度、当前分支归属（含理由）、影响范围（直接\u002F间接\u002F同类）、历史修复。\n\n---\n\n## 阶段 3: 修复方案设计\n\n### 方案设计原则（贯穿 3.0-3.4；进入阶段 4 \u002F 输出 Cx3+ 方案 \u002F 提交批量汇总前强制自检）\n\n- **彻底**：根因级修复，不留 TODO\u002FFIXME\u002Ffollow-up；阶段 2.2 列出的\"同类\"问题一并纳入。自检\"是否还藏 TODO、兼容代码、未列入的同类？\"\n- **不向后兼容**：直接改签名\u002F删字段\u002F换实现，不留 deprecation 别名、shim、双路径。自检\"是否留了别名、旧字段、双路径？\"\n- **优雅简洁**：最少代码、最少抽象、最少新文件，不预设未来需求。自检\"能否用更少代码、抽象、新文件达成？\"\n\n不通过 → 修订；必须保留的违反项 → 显式列入\"遗留 \u002F 取舍说明\"，不得默默放行。默认走彻底方案；Cx2 最小修复仅在 3.2 明确\"不能现在做\"时启用，必须给升级窗口 + 按 §沟通规则闸门输出 issue 建议命令。批量时\"搭车修\"同样适用。\n\n### 3.0 对标参考查询（Cx2+ 必须执行）\n\nCx2 及以上问题，**先查参考实现再动手**。三层按权威性递减：\n\n1. **Go 标准库** → 有做法必须遵循，不自创。查 `docs\u002Freferences\u002Fframework-comparison.md` \"Go 标准库参考\" 表\n2. **组件官方库** → 遵循推荐模式 + 检查 Issues 已知陷阱。查同文件 \"组件官方库参考\" 表\n3. **对标框架** → 参考，可偏离但须注明理由。查同文件 \"按 GoCell 模块的参考映射\"\n\n**决策优先级**: 层 1 > 层 2 > 层 3 > `WebSearch \"golang best practice\"`\n\n**何时跳过**: Cx1 全跳过；纯业务 bug 全跳过\n**不可跳过**（即使 Cx2）: 并发\u002F锁、连接池\u002F生命周期、重连\u002F重试\u002F超时、密码学\u002F认证、事件发布\u002F消费\n\n---\n\n### 3.1 方案分级\n\n| 等级 | 方案数 | 形态 |\n|------|--------|------|\n| Cx1 | 1 | 直接修，跳过比较 |\n| Cx2 | 2 | A 最小修复 + B 彻底方案 |\n| Cx3 | 3 | A 最小 + B 彻底 + C 重构 |\n| Cx4 | 设计文档 | 只输出方案，不执行 |\n\n每个方案须含：改动范围、原理、优缺点、遗留（仅最小修复）、预估改动量、参考来源（Cx2+ 必填）。\n\n### 3.2 时机判断：现在做还是后面做\n\n**必须给出明确的时机建议**，回答三个问题：\n\n**Q0: 是否属于当前分支？** 取 2.4 归属结果：**OUT_OF_SCOPE** → 自动建 backlog issue（4.6 step 3；pri-p0\u002F标签判不定除外），跳过 Q1-Q3；**IN_SCOPE \u002F RELATED** → 进 Q1（RELATED 改动量大可 defer）。\n\n**Q1: 推荐现在做还是后面做？**（仅 IN_SCOPE \u002F RELATED 继续）\n\n| 推荐 | 判定条件 |\n|------|---------|\n| **现在做** | 安全漏洞 \u002F 运行时崩溃 \u002F 阻塞其他工作 \u002F 改动量 ≤ 50 行 |\n| **本迭代做** | 有明确影响但不紧急 \u002F 改动量 50-200 行 \u002F 不阻塞他人 |\n| **下迭代做** | 设计级问题 \u002F 改动量 200+ 行 \u002F 需要先完成其他前置工作 |\n| **记录不做** | 理论风险但实际不触发 \u002F 修复代价远大于收益 |\n\n**Q2: 能不能现在做？** 检查：已有 issue 依赖、活跃分支冲突、kernel 接口消费方。\n\n**Q3: 最小修复的有效期？** 给出彻底方案的建议时间窗口。\n\n### 3.3 详细修复计划\n\n文件级改动清单 + 验证命令（`go build` \u002F `go test` \u002F `go test -race`）。\n\n### 3.4 执行决策（自动，不逐条问用户）\n\n| 复杂度                                                      | 条件 | 决策 |\n|----------------------------------------------------------|------|-----|\n| Cx1\u002FCx2 + IN_SCOPE + ≤2文件 + 不改 kernel 接口\u002Fmigration\u002Fbootstrap\u002F并发语义 | 全满足 | **[AUTO-FIX]** 直接修 |\n| Cx2 + IN_SCOPE + 超2文件或触禁域 + 能做                          | — | 执行推荐方案（A\u002FB 比较） |\n| Cx2 + 不能做（有前置依赖）                                         | — | 记录报告，标注阻塞 |\n| Cx3\u002FCx4                                                  | 任何 | 只输出方案，标注\"需人工决策\" |\n| 任何 + OUT_OF_SCOPE                                        | — | 不修，自动建 backlog issue（4.6 step 3；pri-p0\u002F判不定除外） |\n\n**不可自动执行**: 并发语义变更、接口签名修改、新依赖、数据流方向变更、Cx3+。\n\n> **auto context（无监督）vs manual context（交互 `\u002Ffix`）**：上表 **只有 [AUTO-FIX] 行**（≤2 文件 + 非禁域）能在**无监督自动路径**执行——pr-monitor `--mode=auto` 的 `Skill(\"fix\")` 只跑这一档。「Cx2 超 2 文件或触禁域 → 执行推荐方案」「记录报告，标注阻塞」是 **manual context**（human 在场的交互 `\u002Ffix`）专属；无监督路径遇到这些一律 **surface + 转人工，绝不自动改**。Claude `Skill(\"fix\")` 侧靠本表 + §不可自动执行清单自限。并发语义不可路径检测，留 prompt + Cx3 门兜底。\n\n**何时用 AskUserQuestion**: 见文末 §沟通规则（默认自动决策，不逐条问）。\n\n### 3.5 执行前任务清单（阶段 3 → 4 门禁）\n\n**用 TaskCreate 注册每项任务**，执行时 TaskUpdate 更新状态（✔\u002F◼\u002F◻）。\n\n规则：\n- 所有 finding 都创建 task，OUT_OF_SCOPE 标注 `[→ 自动建 issue（4.6 step 3）；pri-p0\u002F判不定除外]`\n- 单条 Cx1 IN_SCOPE → 跳过清单直接修；批量或 Cx2+ → 必须创建\n- 最后两项固定：`commit + push` + `闭合\u002F创建 GitHub issues`\n- 创建后立即执行，不等确认\n\n### 3.6 决策自检信号（3.4 → 4.x hook 锚点）\n\n进阶段 4 改代码前，发一次决策自检信号：\n\n```\nbash \"$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ffix-self-audit.sh\" emit\n```\n\n`PreToolUse(Bash)` hook 锚定该命令：本次 fix 首次发信号会 deny 并回喂「措施符合彻底、不向后兼容 措施优雅简洁、AI HARD的原则吗」。收到后**真正**按四原则复审本次 fix 方案（彻底 \u002F 不向后兼容 \u002F 优雅简洁 \u002F AI-HARD），按需回调 3.1–3.4 决策，再重发同一命令即放行、进入阶段 4。机制同 ExitPlanMode 的 `.claude\u002Fhooks\u002Fexitplan-self-audit.sh`，但**每个 \u002Ffix 都自检**（消费式 toggle，非每会话一次）。这是自检提醒，**不是**新的 AskUserQuestion 闸门（不重复 §沟通规则）。\n\n---\n\n## 阶段 4: 执行修复\n\n### 4.1 Commit 格式\n\n在当前分支直接修改。Commit: `fix(\u003Cscope>): \u003C问题简述>` + 根因 + 复杂度 + Refs + Co-Authored-By。\nscope 按层：kernel\u002Fruntime\u002Fcells\u002Fpkg。安全约束：只 add 修复文件（不 add -A）；不 amend。\n\n### 4.2 执行代码修改（逐编辑测试循环）\n\n> **批量并行**：4+ 条 finding 时按 Cell 包（cells\u002Fkernel\u002Fruntime\u002Fadapters\u002Fpkg）聚类派发 `developer` sub-agent（**同包同 agent** 防写冲突，组内串行执行下面循环）；并发 4-9→2 \u002F ≥10→3；≤3 条由主 agent 直接处理。triage 同理可按聚类并行（`Explore`）。\n\n对每个任务，执行 Edit-Test Loop + 状态更新：\n\n1. **TaskUpdate → in_progress**（开始处理当前任务）\n2. Read 目标文件\n3. Edit \u002F Write 修改代码\n4. `go build .\u002F...` — 编译检查\n5. `go test .\u002F修改的包\u002F...` — **立即运行测试**（含阶段 1.4 的复现测试）\n6. 如果测试失败：\n   - 分析失败原因\n   - 如果是当前编辑引入 → 立即修正，重回步骤 3\n   - 如果是暴露了后续步骤的依赖 → 记录，继续下一步骤\n7. 测试通过 → **TaskUpdate → completed** → 进入下一个任务\n\n### 4.3 最终测试\n\n全部修改完成后，运行完整测试：\n\n```bash\ngo build .\u002F...\ngo test .\u002Fpath\u002Fto\u002Fmodified\u002Fpackage\u002F...\ngo test -race .\u002Fpath\u002Fto\u002Fmodified\u002Fpackage\u002F...  # 涉及并发时\ngo test .\u002Fkernel\u002F...                            # 改了 kernel 时\n```\n\n### 4.4 测试失败处理（分层回退）\n\n| Round | 策略 |\n|-------|------|\n| 1-2 | 在当前方案上迭代修正 |\n| 3 | `git stash` + 切换到备选方案重新执行 |\n| 4 | 回滚（`git checkout -- \u003C文件>`），Cx1 标 ESCALATE，Cx2 降级到最小修复标遗留 |\n\n### 4.5 验证修复\n\n重新执行阶段 1 的定位逻辑，确认：\n- 原问题代码已被替换\n- 数据流已正确保护\n- 测试覆盖了问题场景\n\n### 4.6 Git 收尾（测试通过后自动执行）\n\n分四步：先提交代码，再冲突预检（阻塞），再立即收尾（评论 + 状态），最后 CI 异步收敛。\n\n**步骤 1: 提交当前分支代码**\n1. `git add` 修复涉及的代码文件\n2. 按 4.1 commit → push；**PR 已存在（输入是 PR 号 \u002F 分支已有 PR）则不重建**，仅当前分支尚无 PR 时才 `gh pr create`\n\n**步骤 2: 冲突预检（阻塞；有 push 时；命令见 `issues` B5 ①）**\n\npush 后按 `issues` B5 ① 验无文件冲突；通过后**立即**进步骤 3（不等 CI）。\n\n**步骤 3: 立即收尾（评论 + 状态，不等 CI；命令形态见 `issues` Part B）**\n\n- **修完** → 贴 fix 评论（命令 + **回显 comment URL\u002Fid** 见 `issues` B4；用 `\u003C!-- pm:fix -->` 模板：findings triage + 修复结果 + 遗留 IN_SCOPE，无损写入（约定见 `pr-comment.md`：每条带 `file:line` + 详表入 `\u003Cdetails>`），OUT_OF_SCOPE 仅一行指针（`? OUT_OF_SCOPE（详见本 PR 的 pm:oos 评论）`），含 footer）。**追加机器块**（贴评论前，接口见 `pr-comment.md` §机器块）：`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=fix --pr=\u003CPR#> --findings='\u003C计数 json>'`（phase\u002Fverdict\u002Fround 全派生），输出单行追加到 `pm:fix` body 末尾，再走 `issues` B4 贴。\n- **OOS findings → 自动建 issue + 独立 pm:oos 评论**（仅当有 OUT_OF_SCOPE findings 时，紧接在 pm:fix 之后贴）：\n  - **逐条自动建 backlog issue**（建单单源命令见 `issues` B1）：finding 字段无损填 `backlog.md` body（现状←证据+三维根因+影响 \u002F 修复方向←三级方案种子 \u002F Files←file:line 全集 \u002F Source←PR #\u003CPR#> F\u003Ck> + `Discovered via \u002Ffix #\u003Coriginal>`）；四轴标签派生 `cx`←`[Cx…]` tag、`area`←finding 文件路径（PROJECT.md §2.1）、`type`←性质、`pri`←`[P…]`（默认 `pri-p2`）；先 `bash hack\u002Fautomation\u002Fissue-labels.sh validate --labels \"…\"` 过门，再 `gh issue create …`，回显 #N\u002FURL。\n  - **安全闸门**：`pri-p0`（incident）→ 停下 AskUserQuestion；`validate` 失败（area\u002Ftype 判不定）→ 标 `deferred=labels-underivable`，回退草稿待人工。\n  - **追加机器块**（贴评论前，`\u003C!-- pm:oos -->` 模板）：`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=oos --pr=\u003CPR#> --oos='{\"items\":[{…,\"issue\":\"#\u003CN>\"},…]}'`——**每个 item 必须带 `issue` 或 `deferred`（`pri-p0-incident`｜`labels-underivable`）之一**，否则 emit-block 拒绝（Hard 闸门）。输出追加到 pm:oos body 末尾，再走 `issues` B4 贴；正文每条回填 `✅ 已建 #N` 或 `? deferred:\u003C原因>`。\n- **切触发 label（OOS 留痕落地后）** → `gh pr edit` 切 `pr-status\u002Fneeds-check-fix`（移除 `pr-status\u002Fneeds-fix`；待 `\u002Fpr-review --check` 验证；**fix 不再直接到 ready**）——OOS artifact（pm:oos\u002Fissue）已先落地、pm:fix 的 `? OUT_OF_SCOPE` 指针不悬空，此刻 check-side 执行器可立即开始，无需等待 CI。**收尾不变式 artifact-before-trigger**：OOS 留痕（建 issue + 贴 pm:oos）必须在切此 label 之前完成，与 ship 阶段 8 同序。\n- **未修 \u002F 待办 finding**（非 OOS 的 Cx3+\u002FRELATED deferred）→ §沟通规则闸门输出 `gh issue create` 建议命令（确认后跑，留 open；label = `backlog` + `pri-pX` + `area-XX` + `type-XX` + `cx-X`（必填，从 finding `[…Cx…]` tag 提取——四轴齐全，建单单源命令见 `issues` B1）；body 按 `backlog.md` 顶部字段映射**无损**填充，不得一句话带过；条件延后型加 `flag-cond` + Trigger，派生注明 `Discovered via \u002Ffix #\u003Coriginal>`）。\n\nPriority：review finding 用原 `[P0-P3]`；`\u002Ffix` 派生默认 `pri-p2`；`pri-p0` 仅 incident（线上故障\u002F数据完整性\u002FCVE），停下 AskUserQuestion 确认。建 issue 必须显式 `--label pri-pX`。\n\n**步骤 4: CI 异步收敛（非阻塞，步骤 3 完成后执行；有 push 时；命令见 `issues` B5 ②）**\n\n按 `issues` B5 ② 等 CI 收敛 + 失败回阶段 1-4 修复循环再推再等（时限 \u002F 3 轮熔断单源在 B5 ②）；CI 收敛后**贴独立 pm:ci 评论**（用 `\u003C!-- pm:ci -->` 模板）：全绿 → `verdict=ci-green`；B5 ② 熔断仍红 → `verdict=ci-failed`（含失败 check 摘要 + run 链接）。**追加机器块**（贴评论前）：`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=ci --pr=\u003CPR#> --ci='{\"failedChecks\":[…],\"passedChecks\":\u003Cn>,\"totalChecks\":\u003Cm>}'`，输出追加到 pm:ci body 末尾，再走 `issues` B4 贴。\n\n**步骤 5: 延迟单次启动监控（必做）**：所有评论 + label 操作完成后，**延迟约 10 分钟后必须启动** `\u002Fpr-monitor \u003CPR#> --mode=auto`（check-side）。外部 app 已实时监听 `pr-status\u002Fneeds-check-fix` 并执行 `\u002Fpr-review --check`；`pr-monitor` 负责检查 check 产生的 label + 机器块，并在 `needs-fix` + 机器可判定 Cx1\u002FCx2 + 未熔断时自动 dispatch `\u002Ffix`。Cx3+ 仍转人工边界；单次跑完即止。\n\n完成后 **TaskUpdate → completed**。\n\n---\n\n## 阶段 5: 输出 + 验证\n\n窗口打印诊断 \u002F 修复报告是主输出、pm:fix 评论（4.6 已贴）是无损留痕，两者都做（输出纪律单源见 `PROJECT.md` §5）。\n\n- 诊断报告（未修）\n- 修复报告（已修）\n- 批量验证（审查报告）\n\n**验证**（4.6 已执行，此处复核，不再查找）：核对 fix 评论 + `pr-status` 已切；OOS → issue 已自动建 + pm:oos 回填 #N（pri-p0\u002F判不定除外）；非 OOS Cx3+ deferred → create 建议命令已输出待确认。\n\n---\n\n## 沟通规则\n\n**默认按分析结果自动决策。** 仅以下情况用 AskUserQuestion：\n- 无法定位问题代码\n- 测试失败且 4 轮回退后仍无法修正\n- **OUT_OF_SCOPE finding \u002F \u002Ffix 派生新问题 → 默认自动 `gh issue create` + 回填 #N**（流程见 4.6 step 3：先反思确认确实 OUT_OF_SCOPE 且非 Cx1 搭车修，再无损填 backlog.md body + 派生四轴标签 → `issue-labels.sh validate` → 建单）。**不逐条问**；仅 `pri-p0`（incident）→ 停下 AskUserQuestion，或 area\u002Ftype 判不定（`validate` 失败）→ 标 `deferred=labels-underivable` 回退草稿。\n- pri-p0 红线升级（incident-driven 或安全 CVE）\n","# 问题诊断与修复\n\n> 真源 = GitHub Issues + Project v2 #3；label \u002F 评级 rubric（P + Cx）见 `.github\u002Fproject-template\u002FPROJECT.md`；issue\u002FPR\u002Flabel\u002F评论原子操作规范见 `issues`（Part B）。\n\n---\n\n## 输入解析\n优先级：**PR 号**（裸数字先按 PR 试 → `gh pr view \u003CN> --json reviews,comments` 读对话评论 + review 摘要（每条带 body\u002Fid\u002Furl\u002FcreatedAt）；再 `gh api repos\u002Fghbvf\u002Fgocell\u002Fpulls\u002F\u003CN>\u002Fcomments --jq length` 探 inline review comments，>0 则 `gh api ...\u002Fpulls\u002F\u003CN>\u002Fcomments` 一并读入（codex\u002F人的 inline finding 不静默漏），=0（本仓常态）跳过；**只取最新一轮**——findings 源 = **最后一条 `\u003C!-- pm:pr-review -->` 评论**（按 createdAt 倒序取首个带该 marker 的评论：`gh pr view \u003CN> --json comments --jq '[.comments[]|select(.body|startswith(\"\u003C!-- pm:pr-review -->\"))]|sort_by(.createdAt)|last|.body'`），其 `\u003Cdetails>` 无损详表即本轮 findings；无 `pm:pr-review` 时回退取最新一条 codex review\u002Fcomment。**跳过**自己上一轮的 `pm:ship`\u002F`pm:fix`\u002F`pm:ci`\u002F`pm:oos` 留痕（已处理）与早于该最新 review 的旧 `pm:pr-review`，**不回头处理上一轮已 triage 的 findings**）> **文件:行号** > **自然语言**（Grep\u002FGlob）。**issue 号不再受理**——裸数字一律先按 PR 解析；issue 状态核查 + triage 收敛到 `issues` 技能（判定后建议 `\u002Fship #\u003CN>` 或 file:line）。\n\n---\n\n## 阶段 1: 问题定位\n\n### 1.1 找到问题代码\n\n按精度递进：明确路径 → Read；模糊描述 → Grep 类型\u002F方法签名 → Grep 错误码\u002F注释 → Agent(Explore) 调用图。三层均无果 → AskUserQuestion。\n\n### 1.2 追踪调用链 + 数据流\n\n从问题代码向上（调用方）和向下（被调用方）追踪。跨 3+ 包用 Agent(Explore)。\n同时追踪数据流：数据源 → 变换 → 消费者。\n\n### 1.3 确认问题是否存在\n\n| 状态 | 含义 | 下一步 |\n|------|------|--------|\n| **CONFIRMED** | 问题真实存在，可以复现 | → 进入阶段 2 |\n| **RESOLVED** | 问题已被修复（给出证据：哪行代码、哪个 PR） | → 向用户报告，结束 |\n| **CHANGED** | 代码重构过，问题形态变化 | → 向用户描述新形态，确认是否继续 |\n| **CANNOT_VERIFY** | 无法确认（缺少上下文、需要运行时验证） | → AskUserQuestion 请求更多信息 |\n\n输出含：状态 \u002F 位置 \u002F 调用链 \u002F 数据流 \u002F 问题描述（自己总结，不照搬 backlog）。\n\n### 1.4 复现测试（Reproduction Test First）\n\nCONFIRMED 后、修复前，先构造一个能**复现问题**的测试用例：\n\n1. 基于调用链和数据流分析，编写最小测试用例触发问题\n2. 运行测试确认 FAIL（证明问题可复现）\n3. 将此测试作为修复验收标准\n\n| 场景 | 操作 |\n|------|------|\n| 已有测试可稍加修改复现 | 修改已有测试 + 确认 FAIL |\n| 需新写测试 | 在 `_test.go` 新增 `TestXxx_Bug描述` |\n| 并发问题 | 写 `go test -race` 可触发的竞态测试 |\n| 无法在单测中复现（需运行时状态） | 标注 `RUNTIME_ONLY`，跳过此步 |\n\n---\n\n## 阶段 2: 根因分析 + 复杂度分级（CONFIRMED 后执行）\n\n### 2.1 根因三维度\n\n- **代码层面**: 哪行代码、哪个设计决策导致的\n- **架构层面**: 是否系统性（Grep 同模式，1 处=局部，3+=架构缺陷）。架构缺陷 → AskUserQuestion 确认局部修还是系统性重构\n- **历史层面**: git log 搜索同类已有修复，发现团队惯例，避免退化\n\n### 2.2 影响范围\n\n直接影响 \u002F 间接影响（列出受影响文件）\u002F 同类问题（Grep 相同模式数量）\n\n### 2.3 复杂度分级\n\n**必须对问题做复杂度判定**，决定后续方案形态（方案数见 3.1）。**Cx1-4 定义单源在 `.github\u002Fproject-template\u002FPROJECT.md` §3.2**（= 改动量\u002F实现风险，本技能不复制）。\n\n> Cx1 表示\"容易修\"，不代表\"不重要\"。IN_SCOPE\u002FOUT_OF_SCOPE 由文件归属（阶段 2.4）决定，与 Cx 等级无关——Cx1 也可以是 IN_SCOPE 且必须修。\n\n判定依据（按顺序检查）：\n1. 修复涉及多少个文件？（`Grep` 搜索所有受影响的调用点）\n2. 是否需要修改 `kernel\u002F` 层的接口或类型？\n3. 是否需要修改数据库 schema（migration）？\n4. 是否影响 wire\u002Fbootstrap 层的组装逻辑？\n5. 同类问题在其他模块是否重复出现？（1 处=局部，3+=系统性）\n\n### 2.4 当前分支归属判定\n\n判断问题是否属于**当前分支\u002FPR 的修复范围**。默认在当前分支处理。\n\n**判定方法：**\n1. `git diff --name-only origin\u002Fdevelop...HEAD` — 获取当前分支改动的文件列表\n2. 对比 finding 涉及的文件是否在这个列表中\n3. 如果当前分支有关联 PR（`gh pr view --json title,body`），检查 PR 描述是否包含该 finding 的 ID 或关键词\n\n**判定结果：**\n\n| 结果 | 判定条件（按文件归属快速判） | 下一步 |\n|------|---------|--------|\n| **IN_SCOPE** | finding 文件在当前分支 diff 中，或 PR 描述含该 finding ID | 在当前分支修复 |\n| **RELATED** | 不在 diff 中但同包 \u002F 同子系统遗留 | 建议搭车修，标注\"搭车\" |\n| **OUT_OF_SCOPE** | 完全不同的包 \u002F 模块 | 不在当前分支修；自动建 backlog issue（4.6 step 3；pri-p0\u002F标签判不定除外） |\n\n输出含：代码\u002F架构\u002F历史三维度根因、复杂度、当前分支归属（含理由）、影响范围（直接\u002F间接\u002F同类）、历史修复。\n\n---\n\n## 阶段 3: 修复方案设计\n\n### 方案设计原则（贯穿 3.0-3.4；进入阶段 4 \u002F 输出 Cx3+ 方案 \u002F 提交批量汇总前强制自检）\n\n- **彻底**：根因级修复，不留 TODO\u002FFIXME\u002Ffollow-up；阶段 2.2 列出的\"同类\"问题一并纳入。自检\"是否还藏 TODO、兼容代码、未列入的同类？\"\n- **不向后兼容**：直接改签名\u002F删字段\u002F换实现，不留 deprecation 别名、shim、双路径。自检\"是否留了别名、旧字段、双路径？\"\n- **优雅简洁**：最少代码、最少抽象、最少新文件，不预设未来需求。自检\"能否用更少代码、抽象、新文件达成？\"\n\n不通过 → 修订；必须保留的违反项 → 显式列入\"遗留 \u002F 取舍说明\"，不得默默放行。默认走彻底方案；Cx2 最小修复仅在 3.2 明确\"不能现在做\"时启用，必须给升级窗口 + 按 §沟通规则闸门输出 issue 建议命令。批量时\"搭车修\"同样适用。\n\n### 3.0 对标参考查询（Cx2+ 必须执行）\n\nCx2 及以上问题，**先查参考实现再动手**。三层按权威性递减：\n\n1. **Go 标准库** → 有做法必须遵循，不自创。查 `docs\u002Freferences\u002Fframework-comparison.md` \"Go 标准库参考\" 表\n2. **组件官方库** → 遵循推荐模式 + 检查 Issues 已知陷阱。查同文件 \"组件官方库参考\" 表\n3. **对标框架** → 参考，可偏离但须注明理由。查同文件 \"按 GoCell 模块的参考映射\"\n\n**决策优先级**: 层 1 > 层 2 > 层 3 > `WebSearch \"golang best practice\"`\n\n**何时跳过**: Cx1 全跳过；纯业务 bug 全跳过\n**不可跳过**（即使 Cx2）: 并发\u002F锁、连接池\u002F生命周期、重连\u002F重试\u002F超时、密码学\u002F认证、事件发布\u002F消费\n\n---\n\n### 3.1 方案分级\n\n| 等级 | 方案数 | 形态 |\n|------|--------|------|\n| Cx1 | 1 | 直接修，跳过比较 |\n| Cx2 | 2 | A 最小修复 + B 彻底方案 |\n| Cx3 | 3 | A 最小 + B 彻底 + C 重构 |\n| Cx4 | 设计文档 | 只输出方案，不执行 |\n\n每个方案须含：改动范围、原理、优缺点、遗留（仅最小修复）、预估改动量、参考来源（Cx2+ 必填）。\n\n### 3.2 时机判断：现在做还是后面做\n\n**必须给出明确的时机建议**，回答三个问题：\n\n**Q0: 是否属于当前分支？** 取 2.4 归属结果：**OUT_OF_SCOPE** → 自动建 backlog issue（4.6 step 3；pri-p0\u002F标签判不定除外），跳过 Q1-Q3；**IN_SCOPE \u002F RELATED** → 进 Q1（RELATED 改动量大可 defer）。\n\n**Q1: 推荐现在做还是后面做？**（仅 IN_SCOPE \u002F RELATED 继续）\n\n| 推荐 | 判定条件 |\n|------|---------|\n| **现在做** | 安全漏洞 \u002F 运行时崩溃 \u002F 阻塞其他工作 \u002F 改动量 ≤ 50 行 |\n| **本迭代做** | 有明确影响但不紧急 \u002F 改动量 50-200 行 \u002F 不阻塞他人 |\n| **下迭代做** | 设计级问题 \u002F 改动量 200+ 行 \u002F 需要先完成其他前置工作 |\n| **记录不做** | 理论风险但实际不触发 \u002F 修复代价远大于收益 |\n\n**Q2: 能不能现在做？** 检查：已有 issue 依赖、活跃分支冲突、kernel 接口消费方。\n\n**Q3: 最小修复的有效期？** 给出彻底方案的建议时间窗口。\n\n### 3.3 详细修复计划\n\n文件级改动清单 + 验证命令（`go build` \u002F `go test` \u002F `go test -race`）。\n\n### 3.4 执行决策（自动，不逐条问用户）\n\n| 复杂度                                                      | 条件 | 决策 |\n|----------------------------------------------------------|------|-----|\n| Cx1\u002FCx2 + IN_SCOPE + ≤2文件 + 不改 kernel 接口\u002Fmigration\u002Fbootstrap\u002F并发语义 | 全满足 | **[AUTO-FIX]** 直接修 |\n| Cx2 + IN_SCOPE + 超2文件或触禁域 + 能做                          | — | 执行推荐方案（A\u002FB 比较） |\n| Cx2 + 不能做（有前置依赖）                                         | — | 记录报告，标注阻塞 |\n| Cx3\u002FCx4                                                  | 任何 | 只输出方案，标注\"需人工决策\" |\n| 任何 + OUT_OF_SCOPE                                        | — | 不修，自动建 backlog issue（4.6 step 3；pri-p0\u002F判不定除外） |\n\n**不可自动执行**: 并发语义变更、接口签名修改、新依赖、数据流方向变更、Cx3+。\n\n> **auto context（无监督）vs manual context（交互 `\u002Ffix`）**：上表 **只有 [AUTO-FIX] 行**（≤2 文件 + 非禁域）能在**无监督自动路径**执行——pr-monitor `--mode=auto` 的 `Skill(\"fix\")` 只跑这一档。「Cx2 超 2 文件或触禁域 → 执行推荐方案」「记录报告，标注阻塞」是 **manual context**（human 在场的交互 `\u002Ffix`）专属；无监督路径遇到这些一律 **surface + 转人工，绝不自动改**。Claude `Skill(\"fix\")` 侧靠本表 + §不可自动执行清单自限。并发语义不可路径检测，留 prompt + Cx3 门兜底。\n\n**何时用 AskUserQuestion**: 见文末 §沟通规则（默认自动决策，不逐条问）。\n\n### 3.5 执行前任务清单（阶段 3 → 4 门禁）\n\n**用 TaskCreate 注册每项任务**，执行时 TaskUpdate 更新状态（✔\u002F◼\u002F◻）。\n\n规则：\n- 所有 finding 都创建 task，OUT_OF_SCOPE 标注 `[→ 自动建 issue（4.6 step 3）；pri-p0\u002F判不定除外]`\n- 单条 Cx1 IN_SCOPE → 跳过清单直接修；批量或 Cx2+ → 必须创建\n- 最后两项固定：`commit + push` + `闭合\u002F创建 GitHub issues`\n- 创建后立即执行，不等确认\n\n### 3.6 决策自检信号（3.4 → 4.x hook 锚点）\n\n进阶段 4 改代码前，发一次决策自检信号：\n\n```\nbash \"$CLAUDE_PROJECT_DIR\u002F.claude\u002Fhooks\u002Ffix-self-audit.sh\" emit\n```\n\n`PreToolUse(Bash)` hook 锚定该命令：本次 fix 首次发信号会 deny 并回喂「措施符合彻底、不向后兼容 措施优雅简洁、AI HARD的原则吗」。收到后**真正**按四原则复审本次 fix 方案（彻底 \u002F 不向后兼容 \u002F 优雅简洁 \u002F AI-HARD），按需回调 3.1–3.4 决策，再重发同一命令即放行、进入阶段 4。机制同 ExitPlanMode 的 `.claude\u002Fhooks\u002Fexitplan-self-audit.sh`，但**每个 \u002Ffix 都自检**（消费式 toggle，非每会话一次）。这是自检提醒，**不是**新的 AskUserQuestion 闸门（不重复 §沟通规则）。\n\n---\n\n## 阶段 4: 执行修复\n\n### 4.1 Commit 格式\n\n在当前分支直接修改。Commit: `fix(\u003Cscope>): \u003C问题简述>` + 根因 + 复杂度 + Refs + Co-Authored-By。\nscope 按层：kernel\u002Fruntime\u002Fcells\u002Fpkg。安全约束：只 add 修复文件（不 add -A）；不 amend。\n\n### 4.2 执行代码修改（逐编辑测试循环）\n\n> **批量并行**：4+ 条 finding 时按 Cell 包（cells\u002Fkernel\u002Fruntime\u002Fadapters\u002Fpkg）聚类派发 `developer` sub-agent（**同包同 agent** 防写冲突，组内串行执行下面循环）；并发 4-9→2 \u002F ≥10→3；≤3 条由主 agent 直接处理。triage 同理可按聚类并行（`Explore`）。\n\n对每个任务，执行 Edit-Test Loop + 状态更新：\n\n1. **TaskUpdate → in_progress**（开始处理当前任务）\n2. Read 目标文件\n3. Edit \u002F Write 修改代码\n4. `go build .\u002F...` — 编译检查\n5. `go test .\u002F修改的包\u002F...` — **立即运行测试**（含阶段 1.4 的复现测试）\n6. 如果测试失败：\n   - 分析失败原因\n   - 如果是当前编辑引入 → 立即修正，重回步骤 3\n   - 如果是暴露了后续步骤的依赖 → 记录，继续下一步骤\n7. 测试通过 → **TaskUpdate → completed** → 进入下一个任务\n\n### 4.3 最终测试\n\n全部修改完成后，运行完整测试：\n\n```bash\ngo build .\u002F...\ngo test .\u002Fpath\u002Fto\u002Fmodified\u002Fpackage\u002F...\ngo test -race .\u002Fpath\u002Fto\u002Fmodified\u002Fpackage\u002F...  # 涉及并发时\ngo test .\u002Fkernel\u002F...                            # 改了 kernel 时\n```\n\n### 4.4 测试失败处理（分层回退）\n\n| Round | 策略 |\n|-------|------|\n| 1-2 | 在当前方案上迭代修正 |\n| 3 | `git stash` + 切换到备选方案重新执行 |\n| 4 | 回滚（`git checkout -- \u003C文件>`），Cx1 标 ESCALATE，Cx2 降级到最小修复标遗留 |\n\n### 4.5 验证修复\n\n重新执行阶段 1 的定位逻辑，确认：\n- 原问题代码已被替换\n- 数据流已正确保护\n- 测试覆盖了问题场景\n\n### 4.6 Git 收尾（测试通过后自动执行）\n\n分四步：先提交代码，再冲突预检（阻塞），再立即收尾（评论 + 状态），最后 CI 异步收敛。\n\n**步骤 1: 提交当前分支代码**\n1. `git add` 修复涉及的代码文件\n2. 按 4.1 commit → push；**PR 已存在（输入是 PR 号 \u002F 分支已有 PR）则不重建**，仅当前分支尚无 PR 时才 `gh pr create`\n\n**步骤 2: 冲突预检（阻塞；有 push 时；命令见 `issues` B5 ①）**\n\npush 后按 `issues` B5 ① 验无文件冲突；通过后**立即**进步骤 3（不等 CI）。\n\n**步骤 3: 立即收尾（评论 + 状态，不等 CI；命令形态见 `issues` Part B）**\n\n- **修完** → 贴 fix 评论（命令 + **回显 comment URL\u002Fid** 见 `issues` B4；用 `\u003C!-- pm:fix -->` 模板：findings triage + 修复结果 + 遗留 IN_SCOPE，无损写入（约定见 `pr-comment.md`：每条带 `file:line` + 详表入 `\u003Cdetails>`），OUT_OF_SCOPE 仅一行指针（`? OUT_OF_SCOPE（详见本 PR 的 pm:oos 评论）`），含 footer）。**追加机器块**（贴评论前，接口见 `pr-comment.md` §机器块）：`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=fix --pr=\u003CPR#> --findings='\u003C计数 json>'`（phase\u002Fverdict\u002Fround 全派生），输出单行追加到 `pm:fix` body 末尾，再走 `issues` B4 贴。\n- **OOS findings → 自动建 issue + 独立 pm:oos 评论**（仅当有 OUT_OF_SCOPE findings 时，紧接在 pm:fix 之后贴）：\n  - **逐条自动建 backlog issue**（建单单源命令见 `issues` B1）：finding 字段无损填 `backlog.md` body（现状←证据+三维根因+影响 \u002F 修复方向←三级方案种子 \u002F Files←file:line 全集 \u002F Source←PR #\u003CPR#> F\u003Ck> + `Discovered via \u002Ffix #\u003Coriginal>`）；四轴标签派生 `cx`←`[Cx…]` tag、`area`←finding 文件路径（PROJECT.md §2.1）、`type`←性质、`pri`←`[P…]`（默认 `pri-p2`）；先 `bash hack\u002Fautomation\u002Fissue-labels.sh validate --labels \"…\"` 过门，再 `gh issue create …`，回显 #N\u002FURL。\n  - **安全闸门**：`pri-p0`（incident）→ 停下 AskUserQuestion；`validate` 失败（area\u002Ftype 判不定）→ 标 `deferred=labels-underivable`，回退草稿待人工。\n  - **追加机器块**（贴评论前，`\u003C!-- pm:oos -->` 模板）：`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=oos --pr=\u003CPR#> --oos='{\"items\":[{…,\"issue\":\"#\u003CN>\"},…]}'`——**每个 item 必须带 `issue` 或 `deferred`（`pri-p0-incident`｜`labels-underivable`）之一**，否则 emit-block 拒绝（Hard 闸门）。输出追加到 pm:oos body 末尾，再走 `issues` B4 贴；正文每条回填 `✅ 已建 #N` 或 `? deferred:\u003C原因>`。\n- **切触发 label（OOS 留痕落地后）** → `gh pr edit` 切 `pr-status\u002Fneeds-check-fix`（移除 `pr-status\u002Fneeds-fix`；待 `\u002Fpr-review --check` 验证；**fix 不再直接到 ready**）——OOS artifact（pm:oos\u002Fissue）已先落地、pm:fix 的 `? OUT_OF_SCOPE` 指针不悬空，此刻 check-side 执行器可立即开始，无需等待 CI。**收尾不变式 artifact-before-trigger**：OOS 留痕（建 issue + 贴 pm:oos）必须在切此 label 之前完成，与 ship 阶段 8 同序。\n- **未修 \u002F 待办 finding**（非 OOS 的 Cx3+\u002FRELATED deferred）→ §沟通规则闸门输出 `gh issue create` 建议命令（确认后跑，留 open；label = `backlog` + `pri-pX` + `area-XX` + `type-XX` + `cx-X`（必填，从 finding `[…Cx…]` tag 提取——四轴齐全，建单单源命令见 `issues` B1）；body 按 `backlog.md` 顶部字段映射**无损**填充，不得一句话带过；条件延后型加 `flag-cond` + Trigger，派生注明 `Discovered via \u002Ffix #\u003Coriginal>`）。\n\nPriority：review finding 用原 `[P0-P3]`；`\u002Ffix` 派生默认 `pri-p2`；`pri-p0` 仅 incident（线上故障\u002F数据完整性\u002FCVE），停下 AskUserQuestion 确认。建 issue 必须显式 `--label pri-pX`。\n\n**步骤 4: CI 异步收敛（非阻塞，步骤 3 完成后执行；有 push 时；命令见 `issues` B5 ②）**\n\n按 `issues` B5 ② 等 CI 收敛 + 失败回阶段 1-4 修复循环再推再等（时限 \u002F 3 轮熔断单源在 B5 ②）；CI 收敛后**贴独立 pm:ci 评论**（用 `\u003C!-- pm:ci -->` 模板）：全绿 → `verdict=ci-green`；B5 ② 熔断仍红 → `verdict=ci-failed`（含失败 check 摘要 + run 链接）。**追加机器块**（贴评论前）：`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=ci --pr=\u003CPR#> --ci='{\"failedChecks\":[…],\"passedChecks\":\u003Cn>,\"totalChecks\":\u003Cm>}'`，输出追加到 pm:ci body 末尾，再走 `issues` B4 贴。\n\n**步骤 5: 延迟单次启动监控（必做）**：所有评论 + label 操作完成后，**延迟约 10 分钟后必须启动** `\u002Fpr-monitor \u003CPR#> --mode=auto`（check-side）。外部 app 已实时监听 `pr-status\u002Fneeds-check-fix` 并执行 `\u002Fpr-review --check`；`pr-monitor` 负责检查 check 产生的 label + 机器块，并在 `needs-fix` + 机器可判定 Cx1\u002FCx2 + 未熔断时自动 dispatch `\u002Ffix`。Cx3+ 仍转人工边界；单次跑完即止。\n\n完成后 **TaskUpdate → completed**。\n\n---\n\n## 阶段 5: 输出 + 验证\n\n窗口打印诊断 \u002F 修复报告是主输出、pm:fix 评论（4.6 已贴）是无损留痕，两者都做（输出纪律单源见 `PROJECT.md` §5）。\n\n- 诊断报告（未修）\n- 修复报告（已修）\n- 批量验证（审查报告）\n\n**验证**（4.6 已执行，此处复核，不再查找）：核对 fix 评论 + `pr-status` 已切；OOS → issue 已自动建 + pm:oos 回填 #N（pri-p0\u002F判不定除外）；非 OOS Cx3+ deferred → create 建议命令已输出待确认。\n\n---\n\n## 沟通规则\n\n**默认按分析结果自动决策。** 仅以下情况用 AskUserQuestion：\n- 无法定位问题代码\n- 测试失败且 4 轮回退后仍无法修正\n- **OUT_OF_SCOPE finding \u002F \u002Ffix 派生新问题 → 默认自动 `gh issue create` + 回填 #N**（流程见 4.6 step 3：先反思确认确实 OUT_OF_SCOPE 且非 Cx1 搭车修，再无损填 backlog.md body + 派生四轴标签 → `issue-labels.sh validate` → 建单）。**不逐条问**；仅 `pri-p0`（incident）→ 停下 AskUserQuestion，或 area\u002Ftype 判不定（`validate` 失败）→ 标 `deferred=labels-underivable` 回退草稿。\n- pri-p0 红线升级（incident-driven 或安全 CVE）\n",{"name":5,"description":7,"allowed-tools":41,"argument-hint":49},[42,43,44,45,46,28,47,48],"Read","Write","Edit","Glob","Grep","Agent","AskUserQuestion","\u003C#PR | 文件:行号 | 问题描述>","develop","043add59bbe840e4a90a4253feec21f074b590dd",".claude\u002Fskills\u002Ffix",0,"https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell","https:\u002F\u002Fgithub.com\u002Fghbvf","2026-06-20 14:38:06",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add ghbvf\u002Fgocell --skill fix",{"tool":63,"command":64},"bunx","bunx skills add ghbvf\u002Fgocell --skill fix",{"tool":66,"command":67},"pnpm","pnpm dlx skills add ghbvf\u002Fgocell --skill fix","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Ffix\u002FSKILL.md",true,[],[72,85,98,117,127,133],{"skillNo":73,"name":27,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":36},"01M6KSVEVMZN9HK0ZRVY3MEJEJ","全流程实施：探索→计划→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",[],[27,28,78,79,80,5,32,31,30,81,29,82,24,83,84],"l2","id","backlog","reviewer","worktree","tdd","review",{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":94,"publishedAt":36},"01M6KSVCP8NB3095MY8M2BR235","pr-review","对指定 PR 跑自动分级六维度 review（默认）；或 --check 模式验证上一轮 findings 是否修复 + 抓回归。按 diff 净增删行数自动分配 2\u002F3\u002F6 reviewer agent 并行（\u003C 200 行不派发，主 agent 自审）；主 agent 做根因聚类 + Cx 分级 + 修复分流建议，不自动 fix。","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Fpr-review\u002FSKILL.md",[91],{"categoryNo":92,"categoryName":93,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[24,95,84,29,28,96,81,97,5,30],"pr review","check","diff",{"skillNo":99,"name":26,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":36},"01M6KSV8P4AYPNHCDR1T7B9YN5","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",[],[26,104,105,106,107,108,34,109,110,111,28,112,5,30,113,114,115,24,116,80],"项目管理","create-issue","labels","整理","EPIC","ci watch","type","project","github","open","ci","create","dag",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":36},"01M6KSV7CX440Q82S9VXQJH02G","git-worktree","Git Worktree 项目约定（编号、基准分支、权限兼容、删除安全）。","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Fgit-worktree\u002FSKILL.md",[],[124,82,125,126],"git","git worktree","安全",{"skillNo":128,"name":5,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":36},"01M6KSV5JB0AR3EJ9V2H4F2MN2","问题诊断与修复: 验证+根因+复杂度分级+修复方案+backlog登记。当用户说'这个问题存在吗''帮我分析这个bug''诊断一下这个模块''修复这个问题'时触发。支持单条问题和多方审查报告批量输入。","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Ffix\u002FSKILL.md",[],[5,35,32,31,30,29,28],{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":36},"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",[],[140,141,142,143,144,145,146,147,148,149,111,150,151,152,26,153,154,155,112,156],"speckit taskstoissues","speckit","structure","for","true","kit","with","spec-kit","actionable","feature","Existing","convert","specify","artifacts","tasks","project structure","design"]