[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KST1E3P5D5Y8BF7FHFZCDW":3,"skill-same:01M6KST1E3P5D5Y8BF7FHFZCDW":72},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6KST1E3P5D5Y8BF7FHFZCDW","ship",null,"全流程实施：探索→计划→worktree→TDD→实施→PR→review→\u002Ffix Cx1\u002FCx2→人工确认。L1(跳过探索,1 reviewer)\u002FL2(单agent探索,1 reviewer)\u002FL3(默认,三agent探索,按diff行数1\u002F2\u002F3\u002F6 reviewer自动)","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\u002Fship\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"review","tdd","pr","worktree","Bash","grep","reviewer","read","write","edit","fix","issue","l2","number","2026-11-10 10:12:30",false,"---\nname: ship\ndescription: \"全流程实施：探索→计划→worktree→TDD→实施→PR→review→\u002Ffix Cx1\u002FCx2→人工确认。L1(跳过探索,1 reviewer)\u002FL2(单agent探索,1 reviewer)\u002FL3(默认,三agent探索,按diff行数1\u002F2\u002F3\u002F6 reviewer自动)\"\nargument-hint: \"[--level=L1|L2|L3] \u003C#issue-number 或任务描述>\"\nallowed-tools: [Read, Write, Edit, Glob, Grep, Bash, Agent, AskUserQuestion]\n---\n\n# GoCell Ship — 全流程实施\n\n> **多沟通原则（默认多问、有歧义即停）**：L2\u002FL3 在创建 worktree（阶段 3）**之前**必须完整呈现「方案方向\n> （阶段 1）+ 改动计划（阶段 2）」并经 AskUserQuestion 确认——不在未对齐时就开工。实施中（阶段 5）surface\n> 阶段性进度与 blocker；阶段 7→8 呈现内置 review findings 表，**Cx1\u002FCx2 IN_SCOPE 自动修**，仅 Cx3\u002FCx4 \u002F 归属-取舍\n> 不清才停下问。任何方案歧义 \u002F 范围不清 \u002F 取舍没把握 → 停下问，不默默假设。\n\n剥离 `--level=` flag 后，剩余参数匹配 `^#?[0-9]+$` 时视为 issue 号，先 `gh issue view \u003CN> --json title,body,labels,state` 拉取作为任务上下文；后续阶段以 issue title\u002Fbody 替代自由文本任务描述，阶段 6 PR body 追加 `Closes #\u003CN>`。`state != \"OPEN\"`（CLOSED \u002F MERGED 等）或 `gh issue view` 失败均用 AskUserQuestion 让用户裁定是否继续。\n\n## 等级\n\n| 等级 | 探索 | 计划确认 | 实施 agent | review |\n|------|------|---------|-----------|--------|\n| L1 | 不探索 | 不需要 | 1-2 并行 | 1 reviewer |\n| L2 | 1 explorer | 展示给用户 | 1-2 并行 | 1 reviewer |\n| L3（默认） | 3 并行 explorer | AskUserQuestion 确认 | ≤ 4 并行 | 1\u002F2\u002F3\u002F6 reviewer（按 diff 行数自动，见阶段 7） |\n\n---\n\n## 阶段 1：探索（L1 跳过）\n\n**L2**：启动 1 个 `explorer` agent，研究对标开源项目实现方案，查 `docs\u002Freferences\u002Fframework-comparison.md` 找 primary 对标框架，用 WebFetch 拉取源码（`raw.githubusercontent.com`），提取接口签名、生命周期、错误处理关键设计，输出采纳建议和偏离理由。\n\n**L3（默认）**：并行启动 3 个 `explorer` agent：\n1. **对标开源项目实现方案**\n2. 测试策略（table-driven \u002F 集成 \u002F benchmark 覆盖模式）\n3. 边界条件与安全处理\n\n全部完成后按「方案与计划原则（含自检）」汇总并逐条自查，再**用 AskUserQuestion 与用户确认方案方向**后继续。\n\n---\n\n### 方案与计划原则（含进入下一步前的自检）\n\n阶段 1 汇总 \u002F 阶段 2 计划必须满足下列原则；L3 在 AskUserQuestion 前逐条自查，任一不通过 → 在确认问题中**显式列出取舍及理由**，不默认放行：\n\n- **彻底**：根因 + 完整解法，范围内紧密相关的小工作一并纳入。自查「是否还藏 TODO\u002FFIXME\u002Ffollow-up、兼容代码、未列入范围的关联工作？」→ 合并进当前 PR 或写明 blocker 理由。\n- **不向后兼容**：删字段\u002F改签名\u002F换实现直接做。自查「是否留了 deprecation 别名、旧字段、兼容 shim、双路径？」→ 删掉或写明保留理由。\n- **优雅简洁**：最少代码改动达成目标，不引入新抽象层、不预设未来需求。自查「能否用更少的代码\u002F抽象\u002F新文件达成同样目标？」→ 简化或写明保留理由。\n- **开源对标**：做了嘛，方向正确吗。\n\n---\n\n## 阶段 2：计划\n\n按「方案与计划原则（含自检）」生成改动文件清单（按依赖顺序）、任务分组（串行\u002F并行批次）、TDD 测试先写清单、对标参考（`ref: framework file`）。生成后逐条自查，L3 用 AskUserQuestion 与用户确认计划后继续。\n\n**并行批次分析**（改动文件 ≥ 4 时必须在计划中明确）：\n- 标注各任务的文件归属和批次编号\n- 标注批次间依赖关系（有依赖 → 串行；无依赖 → 可并行）\n- 解决同文件冲突：同一文件必须归入同一批次\u002Fagent\n\n---\n\n## 阶段 3：Worktree\n\n基于 `origin\u002Fdevelop` 创建（依照 `git-worktree` skill 约定）：\n\n```bash\ngit fetch origin\ngit worktree add worktrees\u002F\u003Ctype>\u002F\u003Cissue#-short-name> -b \u003Ctype>\u002F\u003Cissue#-short-name> origin\u002Fdevelop\n```\n\n命名依 `git-worktree` skill：**编号 = 关联 issue#**（无 issue 不编号），path 与分支首段含 **type**（feature\u002Ffix\u002Frefactor\u002Fdocs\u002Fexperiment，一律小写）。下文 `worktrees\u002F\u003Cwt>` 简写指该 worktree 目录。\n\n---\n\n## 阶段 4：TDD — 先写测试\n\n在 worktree 中先写 `*_test.go`，覆盖正常\u002F边界\u002F错误路径（kernel\u002F ≥ 90%，其余 ≥ 80%）。运行 `go -C worktrees\u002F\u003Cwt> test .\u002F...` 确认测试先 **FAIL**，再进入实施。\n\n---\n\n## 阶段 5：实施\n\n### 5.0 分组与并行度决策（实施前必须执行）\n\n主 agent 根据阶段 2 的改动文件清单和批次依赖关系，**自主决定**：\n- 哪些任务无文件交叉且无逻辑依赖 → 可并行启动 developer agent\n- 哪些任务有依赖或改同一文件 → 串行或归入同一 agent\n\n**硬约束**：\n- 同一文件只能分给同一 agent（防写冲突）\n- 有前置依赖的批次必须等上一批全部完成后再启动\n- 并行 developer agent 上限 **4 个**\n\n### 5.1 Sub-agent prompt 自包含要求\n\n每个 developer sub-agent prompt 必须包含：\n- worktree 路径（`worktrees\u002F\u003Cwt>`）\n- 分配的任务列表（文件路径 + 改动描述）\n- go 命令格式：`go -C worktrees\u002F\u003Cwt> test .\u002F...`\n- CLAUDE.md 关键约束（分层规则、覆盖率要求）\n- commit 格式：`\u003Ctype>(\u003Cscope>): \u003C描述>`\n\n每个 sub-agent 在自己负责的任务上**串行**执行 Edit-Test Loop，完成后跑 `golangci-lint run .\u002F...`（0 issues 才 commit）。\n\n### 5.2 主 agent 汇总（所有并行 agent 完成后）\n\n```bash\ngo -C worktrees\u002F\u003Cwt> build .\u002F...\ngo -C worktrees\u002F\u003Cwt> test .\u002F...\ngolangci-lint run .\u002F...   # 0 issues 才进阶段 6\n```\n\n---\n\n## 阶段 6：PR\n\n```bash\ngit -C worktrees\u002F\u003Cwt> push -u origin \u003Cbranch>\ngh pr create --title \"...\" --body-file \u003C填好的 pull_request_template.md>\ngh pr edit \u003CPR#> --add-label pr-status\u002Fin-progress   # 进入 ship→review→fix→check 流程（见 .github\u002Fproject-template\u002FPROJECT.md §5）\n```\n\nPR body 结构单源 = `.github\u002Fproject-template\u002Fpull_request_template.md`；读模版填占位（`Refs: Closes #\u003CID>` + `ref: framework file`），不在技能内重述结构。本仓 PR 全程 CLI 创建，必须 `--body-file` 读填好的模版。\n\n---\n\n## 阶段 7：Review（内置 reviewer）\n\n> ship 的 review 是 ship→review→fix→check 流程里的**内置首审**（6 维 reviewer）；外部再审（codex \u002F `\u002Fpr-review`）由你在外部跑，\n> 续修走 `\u002Ffix \u003CPR#>`（见 `.github\u002Fproject-template\u002FPROJECT.md` §5）。ship 单独使用只做内置审。\n\n**L1\u002FL2**：1 个 `reviewer` agent（GoCell 六维度）。\n\n**L3**：按 PR diff 净增删行数确定 `reviewer` agent 数量：\n\n```bash\ngit -C worktrees\u002F\u003Cwt> diff --shortstat origin\u002Fdevelop   # N files changed, X insertions(+), Y deletions(-)\n```\n\ndiff 行数 = X + Y（缺项按 0 计）。阶段 7 被单独调用（无 worktree）时回退仓库根 `git diff --shortstat origin\u002Fdevelop`。\n\nGoCell 六维度 = 架构合规 \u002F 安全 \u002F 测试 \u002F 运维可观测 \u002F DX \u002F 产品。**reviewer 数 + 维度切分单源 = `.claude\u002Fagents\u002Freviewer.md` §派发分档**（按上面算出的 diff 行数定档，区间左闭右开，边界归更高档）。\n\n多 agent 时并行启动，每个 agent prompt 自包含其负责维度 + 必读 `.github\u002Fproject-template\u002FPROJECT.md` §3（P\u002FCx 评级单源）；全部完成后由主 agent 汇总去重 findings 表（含 Cx 分级）。\n\n---\n\n## 阶段 8：Fix（内置审 findings）+ 收尾\n\n1. **先在对话窗口完整打印内置 review findings 表**（主输出：含 P\u002FCx 分级 + IN_SCOPE\u002FOUT 归属 + 每条 `file:line`），再贴 pm:ship 评论留痕——窗口=主输出、评论=无损留痕，两者都做（输出纪律单源见 `PROJECT.md` §5）。\n2. **Cx1\u002FCx2 IN_SCOPE findings 自动修**（派 `developer` agent 按 `fix` 的 [AUTO-FIX] 流程直接 Edit-Test 修——developer 无 Skill 工具，不真调 `\u002Ffix`，是复用其判定 + 修复循环；**不逐条问**）；Cx3\u002FCx4 遗留与 OUT_OF_SCOPE 不进主评论详表（移至下面步骤 4 的独立 pm:oos 评论）。**仅当**归属不清 \u002F 取舍没把握 \u002F 有 Cx3+ 需现在做时才 AskUserQuestion。\n3. **推送 + 冲突预检（阻塞）**：`git -C worktrees\u002F\u003Cwt> push` 推送内置修复 commits；按 `issues` B5 ① 先验无文件冲突（冲突则 merge origin\u002Fdevelop --no-edit 解冲突再 push）。冲突预检通过后**立即**执行步骤 4（不等 CI）。\n4. **立即收尾（评论 + 状态，不等 CI）**（命令形态见 `issues` Part B；评论用 `.github\u002Fproject-template\u002Fpr-comment.md` 的 `\u003C!-- pm:ship -->` 模板，含 footer，**评论必留**）：\n   - 贴 ship 评论（命令 + **回显 comment URL\u002Fid** 见 `issues` B4）：IN_SCOPE findings 无损写入（无损约定见 `pr-comment.md`：每条带 `file:line`、详表入 `\u003Cdetails>`，供再审 \u002F `\u002Ffix` 直接读取）；含 reviewer 数 \u002F 已修 Cx1-Cx2 \u002F 遗留 Cx3\u002FCx4 \u002F OUT_OF_SCOPE 数量（OOS 仅一行指针：`? OUT_OF_SCOPE（详见本 PR 的 pm:oos 评论）`，全量无损记录由步骤 5 独立 pm:oos 承载）。\n   - **追加机器块**（贴评论前，接口见 `pr-comment.md` §机器块）：`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=ship --pr=\u003CPR#> --findings='\u003C计数 json>'`（phase\u002Fverdict\u002Fround\u002Frefs\u002Fsession\u002Fworktree 全派生），输出单行追加到填好的 `pm:ship` body 末尾（footer 之后），再走 `issues` B4 贴评论。\n5. **OOS findings → 自动建 issue + 独立 pm:oos 评论**（仅当有 OUT_OF_SCOPE findings 时；**在切触发 label 之前完成**——见步骤 8 下「收尾不变式」）：\n   - **逐条自动建 backlog issue**（建单单源命令见 `issues` B1）：从 finding 字段无损填 `.github\u002Fproject-template\u002Fbacklog.md` body（现状←证据+三维根因+影响 \u002F 修复方向←三级方案种子 \u002F Files←file:line 全集 \u002F Source←PR #\u003CPR#> F\u003Ck> + `Discovered via \u002Fship`）；四轴标签派生：`cx`←finding `[Cx…]` tag、`area`←finding 文件路径（PROJECT.md §2.1 path-glob）、`type`←finding 性质、`pri`←finding `[P…]`（无则默认 `pri-p2`）；先 `bash hack\u002Fautomation\u002Fissue-labels.sh validate --labels \"backlog,pri-pX,area-XX,type-XX,cx-X\"` 过四轴门，再 `gh issue create …`，回显 issue #N\u002FURL。\n   - **安全闸门（不自动建 → 标 deferred）**：`pri-p0`（incident：线上故障\u002F数据完整性\u002FCVE）→ 停下 AskUserQuestion 确认后再决定；`issue-labels.sh validate` 失败（area\u002Ftype 判不定）→ 该条标 `deferred=labels-underivable`（**机器块 item 仍写 `deferred`，XOR funnel 照常满足**），pm:oos 正文回退打印草稿命令待人工。\n   - **追加机器块**（贴评论前，用 `\u003C!-- pm:oos -->` 模板）：`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=oos --pr=\u003CPR#> --oos='{\"items\":[{\"fileLine\":\"…\",\"rootCause\":{\"code\":\"…\",\"arch\":\"…\",\"history\":\"…\"},\"solutionSeeds\":{\"minimal\":\"…\",\"thorough\":\"…\",\"refactor\":\"…\"},\"issue\":\"#\u003CN>\"},…]}'`——**每个 item 必须带 `issue`（已建号\u002FURL）或 `deferred`（`pri-p0-incident`｜`labels-underivable`）之一**，否则 emit-block 拒绝（Hard 闸门：没建 issue 也没显式 defer 就发不出 pm:oos 评论）。输出追加到 pm:oos body 末尾，再走 `issues` B4 贴评论；评论正文每条回填 `✅ 已建 #N \u003Curl>` 或 `? deferred:\u003C原因>`。\n6. **切触发 label**：`gh pr edit` 切 `pr-status\u002Fneeds-review-again`（移除 `pr-status\u002Fin-progress`）——OOS artifact（步骤 5）已先落地、pm:ship 的 OOS 指针不悬空，此刻 review-side 执行器可立即开始，无需等待 CI。\n7. **CI 异步收敛（非阻塞收尾，切 label 后执行）**：按 `issues` B5 ② 等 CI 收敛 + 失败回 `fix` 修复循环再推再等（时限 \u002F 3 轮熔断单源在 B5 ②）；CI 收敛后**贴独立 pm:ci 评论**（用 `.github\u002Fproject-template\u002Fpr-comment.md` 的 `\u003C!-- pm:ci -->` 模板）：\n   - 全绿 → `verdict=ci-green`；B5 ② 熔断仍红 → `verdict=ci-failed`（含失败 check 摘要 + run 链接）。\n   - **追加机器块**（贴评论前）：`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=ci --pr=\u003CPR#> --ci='{\"failedChecks\":[{\"name\":\"…\",\"url\":\"…\"},…],\"passedChecks\":\u003Cn>,\"totalChecks\":\u003Cm>}'`（verdict 由 failedChecks 派生、round carry），输出追加到 pm:ci body 末尾，再走 `issues` B4 贴评论。\n8. **延迟单次启动监控（必做）**：所有评论 + label 操作完成后，**延迟约 10 分钟后必须启动** `\u002Fpr-monitor \u003CPR#> --mode=auto`（review-side）。外部 app 已实时监听 `pr-status\u002Fneeds-review-again` 并执行 review；`pr-monitor` 负责检查 review 产生的 label + 机器块，并在 `needs-fix` + 机器可判定 Cx1\u002FCx2 + 未熔断时自动 dispatch `\u002Ffix`。Cx3+ 仍转人工边界；单次跑完即止。\n\n> **收尾不变式（artifact-before-trigger）**：OOS 留痕（建 issue + 贴 pm:oos）必须在切 `needs-review-again`（步骤 6）**之前**完成——切 label 即触发 review-side 执行器，pm:ship 的 `? OUT_OF_SCOPE` 指针在那一刻必须已指向真实的 pm:oos\u002Fissue，不得悬空；CI（步骤 7）异步在后，不阻塞 backlog 落地。`\u002Ffix` 4.6 step 3 同序（pm:fix → OOS 留痕 → 切 `needs-check-fix` → CI）。\n\n> ship 到此结束（内置审 + 修；评论 + OOS 留痕 + 状态已先行；CI 异步收敛在后）。再审（codex \u002F `\u002Fpr-review`）后，续修走 `\u002Ffix \u003CPR#>`。\n\n---\n\n## 阶段 9：人工确认\n\n```\nPR: #\u003C编号> \u003CURL>\n评论: \u003Cpm:ship 评论 URL，含 #issuecomment-\u003Cid>（来自 issues B4 回显）>\n已完成：TDD \u002F 实施 \u002F PR \u002F review（实跑 reviewer 数：按 diff 1\u002F2\u002F3\u002F6 自动） \u002F Cx1-Cx2 fix \u002F CI 绿\n\n未处理问题（需人工确认）——本表仅摘要 + 指针；完整无损详表（证据\u002F三维根因\u002F三级方案种子）见 pm:ship\n评论的 `\u003Cdetails>`；OUT_OF_SCOPE findings **已自动建 issue**（#N \u002F deferred 原因见本 PR 的 pm:oos 评论）：\n| # | Finding (file:line) | Cx | 归属 | 建议方案 | 原因 |\n|---|---------------------|----|------|---------|----|\n```\n\n---\n\n## 约束\n\n- lint 0 issues 才 push；不 `--no-verify`；不 amend 已 push commit\n- worktree merge 后提示用户手动 `git worktree remove`，不自动删除\n","# GoCell Ship — 全流程实施\n\n> **多沟通原则（默认多问、有歧义即停）**：L2\u002FL3 在创建 worktree（阶段 3）**之前**必须完整呈现「方案方向\n> （阶段 1）+ 改动计划（阶段 2）」并经 AskUserQuestion 确认——不在未对齐时就开工。实施中（阶段 5）surface\n> 阶段性进度与 blocker；阶段 7→8 呈现内置 review findings 表，**Cx1\u002FCx2 IN_SCOPE 自动修**，仅 Cx3\u002FCx4 \u002F 归属-取舍\n> 不清才停下问。任何方案歧义 \u002F 范围不清 \u002F 取舍没把握 → 停下问，不默默假设。\n\n剥离 `--level=` flag 后，剩余参数匹配 `^#?[0-9]+$` 时视为 issue 号，先 `gh issue view \u003CN> --json title,body,labels,state` 拉取作为任务上下文；后续阶段以 issue title\u002Fbody 替代自由文本任务描述，阶段 6 PR body 追加 `Closes #\u003CN>`。`state != \"OPEN\"`（CLOSED \u002F MERGED 等）或 `gh issue view` 失败均用 AskUserQuestion 让用户裁定是否继续。\n\n## 等级\n\n| 等级 | 探索 | 计划确认 | 实施 agent | review |\n|------|------|---------|-----------|--------|\n| L1 | 不探索 | 不需要 | 1-2 并行 | 1 reviewer |\n| L2 | 1 explorer | 展示给用户 | 1-2 并行 | 1 reviewer |\n| L3（默认） | 3 并行 explorer | AskUserQuestion 确认 | ≤ 4 并行 | 1\u002F2\u002F3\u002F6 reviewer（按 diff 行数自动，见阶段 7） |\n\n---\n\n## 阶段 1：探索（L1 跳过）\n\n**L2**：启动 1 个 `explorer` agent，研究对标开源项目实现方案，查 `docs\u002Freferences\u002Fframework-comparison.md` 找 primary 对标框架，用 WebFetch 拉取源码（`raw.githubusercontent.com`），提取接口签名、生命周期、错误处理关键设计，输出采纳建议和偏离理由。\n\n**L3（默认）**：并行启动 3 个 `explorer` agent：\n1. **对标开源项目实现方案**\n2. 测试策略（table-driven \u002F 集成 \u002F benchmark 覆盖模式）\n3. 边界条件与安全处理\n\n全部完成后按「方案与计划原则（含自检）」汇总并逐条自查，再**用 AskUserQuestion 与用户确认方案方向**后继续。\n\n---\n\n### 方案与计划原则（含进入下一步前的自检）\n\n阶段 1 汇总 \u002F 阶段 2 计划必须满足下列原则；L3 在 AskUserQuestion 前逐条自查，任一不通过 → 在确认问题中**显式列出取舍及理由**，不默认放行：\n\n- **彻底**：根因 + 完整解法，范围内紧密相关的小工作一并纳入。自查「是否还藏 TODO\u002FFIXME\u002Ffollow-up、兼容代码、未列入范围的关联工作？」→ 合并进当前 PR 或写明 blocker 理由。\n- **不向后兼容**：删字段\u002F改签名\u002F换实现直接做。自查「是否留了 deprecation 别名、旧字段、兼容 shim、双路径？」→ 删掉或写明保留理由。\n- **优雅简洁**：最少代码改动达成目标，不引入新抽象层、不预设未来需求。自查「能否用更少的代码\u002F抽象\u002F新文件达成同样目标？」→ 简化或写明保留理由。\n- **开源对标**：做了嘛，方向正确吗。\n\n---\n\n## 阶段 2：计划\n\n按「方案与计划原则（含自检）」生成改动文件清单（按依赖顺序）、任务分组（串行\u002F并行批次）、TDD 测试先写清单、对标参考（`ref: framework file`）。生成后逐条自查，L3 用 AskUserQuestion 与用户确认计划后继续。\n\n**并行批次分析**（改动文件 ≥ 4 时必须在计划中明确）：\n- 标注各任务的文件归属和批次编号\n- 标注批次间依赖关系（有依赖 → 串行；无依赖 → 可并行）\n- 解决同文件冲突：同一文件必须归入同一批次\u002Fagent\n\n---\n\n## 阶段 3：Worktree\n\n基于 `origin\u002Fdevelop` 创建（依照 `git-worktree` skill 约定）：\n\n```bash\ngit fetch origin\ngit worktree add worktrees\u002F\u003Ctype>\u002F\u003Cissue#-short-name> -b \u003Ctype>\u002F\u003Cissue#-short-name> origin\u002Fdevelop\n```\n\n命名依 `git-worktree` skill：**编号 = 关联 issue#**（无 issue 不编号），path 与分支首段含 **type**（feature\u002Ffix\u002Frefactor\u002Fdocs\u002Fexperiment，一律小写）。下文 `worktrees\u002F\u003Cwt>` 简写指该 worktree 目录。\n\n---\n\n## 阶段 4：TDD — 先写测试\n\n在 worktree 中先写 `*_test.go`，覆盖正常\u002F边界\u002F错误路径（kernel\u002F ≥ 90%，其余 ≥ 80%）。运行 `go -C worktrees\u002F\u003Cwt> test .\u002F...` 确认测试先 **FAIL**，再进入实施。\n\n---\n\n## 阶段 5：实施\n\n### 5.0 分组与并行度决策（实施前必须执行）\n\n主 agent 根据阶段 2 的改动文件清单和批次依赖关系，**自主决定**：\n- 哪些任务无文件交叉且无逻辑依赖 → 可并行启动 developer agent\n- 哪些任务有依赖或改同一文件 → 串行或归入同一 agent\n\n**硬约束**：\n- 同一文件只能分给同一 agent（防写冲突）\n- 有前置依赖的批次必须等上一批全部完成后再启动\n- 并行 developer agent 上限 **4 个**\n\n### 5.1 Sub-agent prompt 自包含要求\n\n每个 developer sub-agent prompt 必须包含：\n- worktree 路径（`worktrees\u002F\u003Cwt>`）\n- 分配的任务列表（文件路径 + 改动描述）\n- go 命令格式：`go -C worktrees\u002F\u003Cwt> test .\u002F...`\n- CLAUDE.md 关键约束（分层规则、覆盖率要求）\n- commit 格式：`\u003Ctype>(\u003Cscope>): \u003C描述>`\n\n每个 sub-agent 在自己负责的任务上**串行**执行 Edit-Test Loop，完成后跑 `golangci-lint run .\u002F...`（0 issues 才 commit）。\n\n### 5.2 主 agent 汇总（所有并行 agent 完成后）\n\n```bash\ngo -C worktrees\u002F\u003Cwt> build .\u002F...\ngo -C worktrees\u002F\u003Cwt> test .\u002F...\ngolangci-lint run .\u002F...   # 0 issues 才进阶段 6\n```\n\n---\n\n## 阶段 6：PR\n\n```bash\ngit -C worktrees\u002F\u003Cwt> push -u origin \u003Cbranch>\ngh pr create --title \"...\" --body-file \u003C填好的 pull_request_template.md>\ngh pr edit \u003CPR#> --add-label pr-status\u002Fin-progress   # 进入 ship→review→fix→check 流程（见 .github\u002Fproject-template\u002FPROJECT.md §5）\n```\n\nPR body 结构单源 = `.github\u002Fproject-template\u002Fpull_request_template.md`；读模版填占位（`Refs: Closes #\u003CID>` + `ref: framework file`），不在技能内重述结构。本仓 PR 全程 CLI 创建，必须 `--body-file` 读填好的模版。\n\n---\n\n## 阶段 7：Review（内置 reviewer）\n\n> ship 的 review 是 ship→review→fix→check 流程里的**内置首审**（6 维 reviewer）；外部再审（codex \u002F `\u002Fpr-review`）由你在外部跑，\n> 续修走 `\u002Ffix \u003CPR#>`（见 `.github\u002Fproject-template\u002FPROJECT.md` §5）。ship 单独使用只做内置审。\n\n**L1\u002FL2**：1 个 `reviewer` agent（GoCell 六维度）。\n\n**L3**：按 PR diff 净增删行数确定 `reviewer` agent 数量：\n\n```bash\ngit -C worktrees\u002F\u003Cwt> diff --shortstat origin\u002Fdevelop   # N files changed, X insertions(+), Y deletions(-)\n```\n\ndiff 行数 = X + Y（缺项按 0 计）。阶段 7 被单独调用（无 worktree）时回退仓库根 `git diff --shortstat origin\u002Fdevelop`。\n\nGoCell 六维度 = 架构合规 \u002F 安全 \u002F 测试 \u002F 运维可观测 \u002F DX \u002F 产品。**reviewer 数 + 维度切分单源 = `.claude\u002Fagents\u002Freviewer.md` §派发分档**（按上面算出的 diff 行数定档，区间左闭右开，边界归更高档）。\n\n多 agent 时并行启动，每个 agent prompt 自包含其负责维度 + 必读 `.github\u002Fproject-template\u002FPROJECT.md` §3（P\u002FCx 评级单源）；全部完成后由主 agent 汇总去重 findings 表（含 Cx 分级）。\n\n---\n\n## 阶段 8：Fix（内置审 findings）+ 收尾\n\n1. **先在对话窗口完整打印内置 review findings 表**（主输出：含 P\u002FCx 分级 + IN_SCOPE\u002FOUT 归属 + 每条 `file:line`），再贴 pm:ship 评论留痕——窗口=主输出、评论=无损留痕，两者都做（输出纪律单源见 `PROJECT.md` §5）。\n2. **Cx1\u002FCx2 IN_SCOPE findings 自动修**（派 `developer` agent 按 `fix` 的 [AUTO-FIX] 流程直接 Edit-Test 修——developer 无 Skill 工具，不真调 `\u002Ffix`，是复用其判定 + 修复循环；**不逐条问**）；Cx3\u002FCx4 遗留与 OUT_OF_SCOPE 不进主评论详表（移至下面步骤 4 的独立 pm:oos 评论）。**仅当**归属不清 \u002F 取舍没把握 \u002F 有 Cx3+ 需现在做时才 AskUserQuestion。\n3. **推送 + 冲突预检（阻塞）**：`git -C worktrees\u002F\u003Cwt> push` 推送内置修复 commits；按 `issues` B5 ① 先验无文件冲突（冲突则 merge origin\u002Fdevelop --no-edit 解冲突再 push）。冲突预检通过后**立即**执行步骤 4（不等 CI）。\n4. **立即收尾（评论 + 状态，不等 CI）**（命令形态见 `issues` Part B；评论用 `.github\u002Fproject-template\u002Fpr-comment.md` 的 `\u003C!-- pm:ship -->` 模板，含 footer，**评论必留**）：\n   - 贴 ship 评论（命令 + **回显 comment URL\u002Fid** 见 `issues` B4）：IN_SCOPE findings 无损写入（无损约定见 `pr-comment.md`：每条带 `file:line`、详表入 `\u003Cdetails>`，供再审 \u002F `\u002Ffix` 直接读取）；含 reviewer 数 \u002F 已修 Cx1-Cx2 \u002F 遗留 Cx3\u002FCx4 \u002F OUT_OF_SCOPE 数量（OOS 仅一行指针：`? OUT_OF_SCOPE（详见本 PR 的 pm:oos 评论）`，全量无损记录由步骤 5 独立 pm:oos 承载）。\n   - **追加机器块**（贴评论前，接口见 `pr-comment.md` §机器块）：`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=ship --pr=\u003CPR#> --findings='\u003C计数 json>'`（phase\u002Fverdict\u002Fround\u002Frefs\u002Fsession\u002Fworktree 全派生），输出单行追加到填好的 `pm:ship` body 末尾（footer 之后），再走 `issues` B4 贴评论。\n5. **OOS findings → 自动建 issue + 独立 pm:oos 评论**（仅当有 OUT_OF_SCOPE findings 时；**在切触发 label 之前完成**——见步骤 8 下「收尾不变式」）：\n   - **逐条自动建 backlog issue**（建单单源命令见 `issues` B1）：从 finding 字段无损填 `.github\u002Fproject-template\u002Fbacklog.md` body（现状←证据+三维根因+影响 \u002F 修复方向←三级方案种子 \u002F Files←file:line 全集 \u002F Source←PR #\u003CPR#> F\u003Ck> + `Discovered via \u002Fship`）；四轴标签派生：`cx`←finding `[Cx…]` tag、`area`←finding 文件路径（PROJECT.md §2.1 path-glob）、`type`←finding 性质、`pri`←finding `[P…]`（无则默认 `pri-p2`）；先 `bash hack\u002Fautomation\u002Fissue-labels.sh validate --labels \"backlog,pri-pX,area-XX,type-XX,cx-X\"` 过四轴门，再 `gh issue create …`，回显 issue #N\u002FURL。\n   - **安全闸门（不自动建 → 标 deferred）**：`pri-p0`（incident：线上故障\u002F数据完整性\u002FCVE）→ 停下 AskUserQuestion 确认后再决定；`issue-labels.sh validate` 失败（area\u002Ftype 判不定）→ 该条标 `deferred=labels-underivable`（**机器块 item 仍写 `deferred`，XOR funnel 照常满足**），pm:oos 正文回退打印草稿命令待人工。\n   - **追加机器块**（贴评论前，用 `\u003C!-- pm:oos -->` 模板）：`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=oos --pr=\u003CPR#> --oos='{\"items\":[{\"fileLine\":\"…\",\"rootCause\":{\"code\":\"…\",\"arch\":\"…\",\"history\":\"…\"},\"solutionSeeds\":{\"minimal\":\"…\",\"thorough\":\"…\",\"refactor\":\"…\"},\"issue\":\"#\u003CN>\"},…]}'`——**每个 item 必须带 `issue`（已建号\u002FURL）或 `deferred`（`pri-p0-incident`｜`labels-underivable`）之一**，否则 emit-block 拒绝（Hard 闸门：没建 issue 也没显式 defer 就发不出 pm:oos 评论）。输出追加到 pm:oos body 末尾，再走 `issues` B4 贴评论；评论正文每条回填 `✅ 已建 #N \u003Curl>` 或 `? deferred:\u003C原因>`。\n6. **切触发 label**：`gh pr edit` 切 `pr-status\u002Fneeds-review-again`（移除 `pr-status\u002Fin-progress`）——OOS artifact（步骤 5）已先落地、pm:ship 的 OOS 指针不悬空，此刻 review-side 执行器可立即开始，无需等待 CI。\n7. **CI 异步收敛（非阻塞收尾，切 label 后执行）**：按 `issues` B5 ② 等 CI 收敛 + 失败回 `fix` 修复循环再推再等（时限 \u002F 3 轮熔断单源在 B5 ②）；CI 收敛后**贴独立 pm:ci 评论**（用 `.github\u002Fproject-template\u002Fpr-comment.md` 的 `\u003C!-- pm:ci -->` 模板）：\n   - 全绿 → `verdict=ci-green`；B5 ② 熔断仍红 → `verdict=ci-failed`（含失败 check 摘要 + run 链接）。\n   - **追加机器块**（贴评论前）：`bash hack\u002Fautomation\u002Fpr-meta.sh emit-block --kind=ci --pr=\u003CPR#> --ci='{\"failedChecks\":[{\"name\":\"…\",\"url\":\"…\"},…],\"passedChecks\":\u003Cn>,\"totalChecks\":\u003Cm>}'`（verdict 由 failedChecks 派生、round carry），输出追加到 pm:ci body 末尾，再走 `issues` B4 贴评论。\n8. **延迟单次启动监控（必做）**：所有评论 + label 操作完成后，**延迟约 10 分钟后必须启动** `\u002Fpr-monitor \u003CPR#> --mode=auto`（review-side）。外部 app 已实时监听 `pr-status\u002Fneeds-review-again` 并执行 review；`pr-monitor` 负责检查 review 产生的 label + 机器块，并在 `needs-fix` + 机器可判定 Cx1\u002FCx2 + 未熔断时自动 dispatch `\u002Ffix`。Cx3+ 仍转人工边界；单次跑完即止。\n\n> **收尾不变式（artifact-before-trigger）**：OOS 留痕（建 issue + 贴 pm:oos）必须在切 `needs-review-again`（步骤 6）**之前**完成——切 label 即触发 review-side 执行器，pm:ship 的 `? OUT_OF_SCOPE` 指针在那一刻必须已指向真实的 pm:oos\u002Fissue，不得悬空；CI（步骤 7）异步在后，不阻塞 backlog 落地。`\u002Ffix` 4.6 step 3 同序（pm:fix → OOS 留痕 → 切 `needs-check-fix` → CI）。\n\n> ship 到此结束（内置审 + 修；评论 + OOS 留痕 + 状态已先行；CI 异步收敛在后）。再审（codex \u002F `\u002Fpr-review`）后，续修走 `\u002Ffix \u003CPR#>`。\n\n---\n\n## 阶段 9：人工确认\n\n```\nPR: #\u003C编号> \u003CURL>\n评论: \u003Cpm:ship 评论 URL，含 #issuecomment-\u003Cid>（来自 issues B4 回显）>\n已完成：TDD \u002F 实施 \u002F PR \u002F review（实跑 reviewer 数：按 diff 1\u002F2\u002F3\u002F6 自动） \u002F Cx1-Cx2 fix \u002F CI 绿\n\n未处理问题（需人工确认）——本表仅摘要 + 指针；完整无损详表（证据\u002F三维根因\u002F三级方案种子）见 pm:ship\n评论的 `\u003Cdetails>`；OUT_OF_SCOPE findings **已自动建 issue**（#N \u002F deferred 原因见本 PR 的 pm:oos 评论）：\n| # | Finding (file:line) | Cx | 归属 | 建议方案 | 原因 |\n|---|---------------------|----|------|---------|----|\n```\n\n---\n\n## 约束\n\n- lint 0 issues 才 push；不 `--no-verify`；不 amend 已 push commit\n- worktree merge 后提示用户手动 `git worktree remove`，不自动删除\n",{"name":5,"description":7,"allowed-tools":42,"argument-hint":50},[43,44,45,46,47,27,48,49],"Read","Write","Edit","Glob","Grep","Agent","AskUserQuestion","[--level=L1|L2|L3] \u003C#issue-number 或任务描述>","develop","043add59bbe840e4a90a4253feec21f074b590dd",".claude\u002Fskills\u002Fship",0,"https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell","https:\u002F\u002Fgithub.com\u002Fghbvf","2026-06-20 14:38:06",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add ghbvf\u002Fgocell --skill ship",{"tool":64,"command":65},"bunx","bunx skills add ghbvf\u002Fgocell --skill ship",{"tool":67,"command":68},"pnpm","pnpm dlx skills add ghbvf\u002Fgocell --skill ship","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Fship\u002FSKILL.md",true,[],[73,80,91,112,122,129],{"skillNo":74,"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":75,"categories":76,"keywords":77,"publishedAt":37},"01M6KSVEVMZN9HK0ZRVY3MEJEJ","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Fship\u002FSKILL.md",[],[5,27,35,78,79,33,32,31,30,29,28,26,25,24,23],"id","backlog",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":87,"publishedAt":37},"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",[86],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[25,88,23,28,27,89,29,90,33,30],"pr review","check","diff",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":37},"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",[],[93,98,99,100,101,102,103,104,105,106,27,107,33,30,108,109,110,25,111,79],"项目管理","create-issue","labels","整理","EPIC","close","ci watch","type","project","github","open","ci","create","dag",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":37},"01M6KSV7CX440Q82S9VXQJH02G","git-worktree","Git Worktree 项目约定（编号、基准分支、权限兼容、删除安全）。","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Fgit-worktree\u002FSKILL.md",[],[119,26,120,121],"git","git worktree","安全",{"skillNo":123,"name":33,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":37},"01M6KSV5JB0AR3EJ9V2H4F2MN2","问题诊断与修复: 验证+根因+复杂度分级+修复方案+backlog登记。当用户说'这个问题存在吗''帮我分析这个bug''诊断一下这个模块''修复这个问题'时触发。支持单条问题和多方审查报告批量输入。","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Ffix\u002FSKILL.md",[],[33,128,32,31,30,28,27],"文件",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":37},"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",[],[136,137,138,139,140,141,142,143,144,145,106,146,147,148,93,149,150,151,107,152],"speckit taskstoissues","speckit","structure","for","true","kit","with","spec-kit","actionable","feature","Existing","convert","specify","artifacts","tasks","project structure","design"]