[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KSSN6ZEC1WQXCWXR49HF6D":3,"skill-same:01M6KSSN6ZEC1WQXCWXR49HF6D":69},{"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":17,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M6KSSN6ZEC1WQXCWXR49HF6D","issues",null,"GitHub Issues + Project v2 #3 项目管理单源技能。Part A：epic 拆解 + wave 实施顺序评论（找子任务 → blocked-by DAG → wave 1-4 容量装箱排序：每 wave ≤4、pri 优先、wave 内切并行组\u002F串行链、OPEN 重排、已完成不动、装箱溢出顺延下一 wave、仅超窗(Wave 4 后仍未分配)单列 → 只追加 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 是否还成立时使用。","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\u002Fissues\u002FSKILL.md",[],[5,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"backlog","项目管理","create-issue","labels","整理","EPIC","close","ci watch","type","project","github","fix","read","Bash","open","ci","create","pr","dag","2026-11-10 10:12:30",false,"---\nname: issues\ndescription: \"GitHub Issues + Project v2 #3 项目管理单源技能。Part A：epic 拆解 + wave 实施顺序评论（找子任务 → blocked-by DAG → wave 1-4 容量装箱排序：每 wave ≤4、pri 优先、wave 内切并行组\u002F串行链、OPEN 重排、已完成不动、装箱溢出顺延下一 wave、仅超窗(Wave 4 后仍未分配)单列 → 只追加 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 是否还成立时使用。\"\nargument-hint: \"\u003Cepic #N | #issue（非epic→状态核查）| create-issue | edit-labels | pr-status | comment> [...]\"\nallowed-tools: [Read, Grep, Bash, Agent, AskUserQuestion]\n---\n\n# issues — 项目管理单源（Epic\u002FWave + Issue\u002FPR\u002FLabel\u002F评论）\n\n> 真源 = GitHub Issues + Project v2 #3。**内容\u002F结构 + 治理全在 `.github\u002Fproject-template\u002F`**：issue body → `backlog.md`\u002F`epic.md`，PR body → `pull_request_template.md`，PR 评论 → `pr-comment.md`，label\u002F字段\u002F评级\u002F流程 → `PROJECT.md`（索引见 `README.md`）。本技能只负责编排，不复制模版内容。\n> 输入分派：**`epic #N` \u002F 带 `epic` label 的 issue** → Part A（拆解 + wave 调度）；**普通 issue 号（无 `epic` label）** → 下方「非 epic issue 状态核查」；**动词**（create \u002F edit \u002F pr-status \u002F comment）→ Part B 原子操作。\n> create issue 前先 search 查重（幂等）。\n> 仓库：`ghbvf\u002Fgocell`。Project v2：`--owner ghbvf --number 3`（title `gocell`）。\n\n---\n\n## 非 epic issue 状态核查（查代码判状态，只判不修）\n\n输入普通 issue 号（无 `epic` label）时，不排 wave，而是查代码判断该 issue 是否仍成立：\n\n1. `gh issue view \u003CN> --json title,body,labels` 读问题描述 + body 的 Files。\n2. 按 Files \u002F 关键字 Read\u002FGrep 定位代码；跨 3+ 文件时并行派 `Agent(Explore)` 核查。\n3. 判状态（**只判不修**）：**存在** \u002F **已修复**（给证据：哪行 \u002F 哪 PR）\u002F **已变更**（形态变化）\u002F **无法确认**。\n4. 输出状态 + 证据 + 建议：需修 → 建议 `\u002Fship #\u003CN>`（或定位到 file:line 后 `\u002Ffix`）；已修复 \u002F 过期 → 建议 Part B 关闭（`gh issue close --reason ...`）。\n\n---\n\n# Part A — Epic 拆解 + Wave 实施顺序评论\n\n> 负责 epic 级「找子任务 → 排 wave → 追加 epic 评论」。不写 Project 字段，不改 epic body；issue\u002Flabel\u002F评论原子操作见 Part B。\n\n## A1. 读 epic → 关键字查找相关 issues → 关联 → 汇总子 issues\n\n1. **读 epic**：`gh issue view \u003Cepic#> --json number,title,body,labels`（确认 epic label；从 title + 目标\u002F范围提取关键字）。\n2. **关键字查找相关 issues**：`gh issue list --search \"\u003C关键字>\" --state open --json number,title,labels`，挑出属于本 epic 的候选；用 AskUserQuestion 确认候选集（不擅自全关联）。\n3. **关联到 epic**（建 sub-issue 关系，已是 sub-issue 的跳过）：\n   ```bash\n   id=$(gh api repos\u002Fghbvf\u002Fgocell\u002Fissues\u002F\u003Cchild#> --jq .id)   # 取整数 id（非 number）\n   gh api --method POST repos\u002Fghbvf\u002Fgocell\u002Fissues\u002F\u003Cepic#>\u002Fsub_issues -F sub_issue_id=$id\n   ```\n4. **汇总子 issues**：`gh api repos\u002Fghbvf\u002Fgocell\u002Fissues\u002F\u003Cepic#>\u002Fsub_issues --jq '.[]|{number,title,state}'`（含新关联）；对每个 OPEN 子任务读 label（area\u002Ftype\u002Fpri）+ body 的 `Blocked-by: #NNN`（多行\u002F逗号分隔，无声明=无前置）。\n\n> 子任务跨 3+ 包或描述模糊时，用 `Agent(Explore)` 核实归属 \u002F 状态 \u002F `Blocked-by` 再汇总（**wave 内冲突分区 + 实施顺序的分析在 A2 第 6 步，见下**）。\n\n## A2. 建 blocked-by DAG + wave 容量装箱排序（每 wave ≤4，Wave 1-4 有界）\n\n**滚动 + 有界 + 容量装箱算法**（每次更新 epic 都重跑；作用域 = epic 的 **OPEN** 子任务）。wave 不再纯=依赖深度，而是「依赖约束 + 每 wave ≤4 容量」的贪心 list-scheduling——**pri 决定容量受限时谁进早 wave**：\n\n1. **节点 = OPEN 子任务**；CLOSED（已完成）子任务**排除**——不参与排序，仅在评论中单列为已完成。\n2. 有向边 `blocker → dependent`（来自 `Blocked-by`），**仅当 blocker 也 OPEN**；blocker 已 close = 依赖已满足 → 删该边。**这是「滚动」的来源**：前置完成后 dependent 自动前移到更早 wave。\n3. 检测环：若有环，AskUserQuestion 让用户裁定断哪条边（不静默）。\n4. **逐 wave w=1..4 贪心装箱**（每 wave 至多 **4** 个 issue）：\n   - `ready 集` = 全部 blocker 都已分到**更早** wave 的未分配 OPEN 节点（无 blocker 的节点天然 ready）。\n   - ready 集按 `pri`(p0>p1>p2>p3) → **基础性产出先** → `Cx`(小先，由 `cx-X` label 提供) → issue# 排序，取前 **≤4** 入 wave w。\n   - 其余（含同深度溢出、blocker 刚入本 wave 而本轮未 ready 的）**留待下一 wave**（溢出顺延）。\n5. **有界 cap = Wave 4**：装箱到 Wave 4 仍未分配的节点标记 **超窗**，在评论中单列，不写任何 Project 字段。\n6. **wave 内冲突分区**（确认「真并行」vs「须串行」）：对每个 wave（成员 ≥2）**并行**派 `Agent(Explore)` 分析其中每个任务的 scope \u002F 触碰文件 \u002F 产出↔消费 \u002F 风险，主 agent 汇总后切：\n   - **并行组**：两两**无文件重叠 + 无隐式产出↔消费 + 无资源冲突** → 可同时跑（≤4 并行 agent）。「可并行」= 经冲突分析确认无冲突，**非**仅「无 `Blocked-by`」。\n   - **串行链**：有上述任一冲突 → 须串行，链内按 `pri` → 基础性产出先 → `Cx` → issue# 定序，并注明冲突原因（如「同改 foo.go」）。\n   - 单任务 wave 跳过分析。\n7. 输出每个 OPEN 子任务的 `(wave, 并行组\u002F串行链, 链内序)` 或「超窗」。\n\n呈现给用户的 dry-run 表（只列 OPEN；超窗与已完成单列）：\n\n```\nWave 1（依赖深度1，取 pri 前4）:\n  并行组 A（零冲突，可同时）: #a(p0·Cx1)  #b(p0·Cx2)\n  串行链 B（#c→#d 同改 foo.go，按 pri）: [1] #c(p1·Cx2)  [2] #d(p2·Cx1)\nWave 2（深度1溢出 + 依赖 Wave 1）:\n  并行组 A: #e(p3·Cx1 深度1溢出)  #g(p1·Cx2 ←blocked-by #a)\n超窗(>W4，评论单列): #z(依赖链\u002F装箱 >4)\n已完成(不动): #y\n```\n\n## A3. 追加 epic 实施顺序评论\n\n```bash\n# 只追加评论；不编辑 epic body，不写 Project 字段。\ngh issue comment \u003Cepic#> --body \"$(cat \u003C\u003C'C'\n\u003C!-- pm:epic-wave -->\n? Epic 实施顺序更新：每 wave ≤4 容量装箱，OPEN 按 pri 排 Wave 1-4；wave 内标明并行组 \u002F 串行链；已完成与超窗(>W4)单列。排序结果只写在本评论中，不写 Project 字段，不改 epic body。\n\n\u003C粘贴 A2 dry-run 表>\nC\n)\"\n```\n\n## A4. 沟通规则\n\n- 环检测命中：停下 AskUserQuestion。\n- DAG 排序结果先 dry-run 呈现，确认后只追加 epic 评论。\n- 不改子任务代码 \u002F 不关 issue \u002F 不改 area-type-pri label（那是 Part B \u002F `fix` 职责）。\n\n---\n\n# Part B — Issue \u002F PR \u002F Label \u002F 评论\n\n> issue\u002FPR 的 `gh` 编排，是 issue\u002FPR\u002Flabel\u002F评论**固定 gh 命令形态的单源**——ship\u002Ffix\u002Fpr-review 引用本部分，不重印命令。body 骨架见 `.github\u002Fproject-template\u002F` 的 `backlog.md` \u002F `epic.md` \u002F `pull_request_template.md`；PR 评论格式见 `pr-comment.md`；label \u002F 字段 \u002F 评级 rubric 见 `PROJECT.md`。本部分不复制模版内容。\n\n## B1. 新建 backlog issue\n\n四轴 label 齐全（area + type + pri + cx）+ `backlog`，全部 CLI 显式贴（pri\u002Fcx 必填，cx 无 unknown sentinel）：\n\n```bash\n# 建单前强制门：校验 area\u002Ftype\u002Fpri\u002Fcx 四轴完整（exit 0 才执行 create；下游 selftest-locked，见 PROJECT.md §2.6）\nbash hack\u002Fautomation\u002Fissue-labels.sh validate --labels \"backlog,pri-p2,area-eventing,type-bug,cx-2\"\ngh issue create \\\n  --label backlog --label pri-p2 --label area-eventing --label type-bug --label cx-2 \\\n  --title \"[\u003CID>] \u003C简短标题>\" --body-file \u003C填好的 backlog.md>\n# body 骨架单源 = .github\u002Fproject-template\u002Fbacklog.md（现状 \u002F 修复方向 \u002F Files \u002F Trigger \u002F Source）——本技能不复制其结构\n```\n\n> **由 review\u002Ffix finding（OUT_OF_SCOPE \u002F 派生）成文时**：body 按 `backlog.md` 顶部的字段映射**无损**填充，不得一句话带过——否则后续无法据此修复；并从 finding 的 `[…Cx…]` tag 取 `--label cx-X` 一并贴。\n\n- **area-XX**（1 个，8 选）：见 `.github\u002Fproject-template\u002FPROJECT.md` §2.1。\n- **type-XX**（1 个，8 选）：见 §2.2。\n- **pri-pX**：评级 rubric 见 `.github\u002Fproject-template\u002FPROJECT.md` §3。`\u002Ffix` 派生默认 `pri-p2`；`pri-p0` 仅 incident-driven，停下 AskUserQuestion 确认。\n- **cx-X**（必填）：复杂度 rubric 见 `.github\u002Fproject-template\u002FPROJECT.md` §3.2 \u002F §2.6。建单前必须定级并显式 `--label cx-X`（与 pri 对称，无 unknown sentinel——定不到级也要就近取一档）；finding 派生从 `[…Cx…]` tag 取。epic 例外（不贴 cx）。\n- **flag-cond**（可选）：条件延后型加此 label + body 写 `## Trigger`。\n\n> P0 红线不得默认贴。area\u002Ftype\u002Fcx 漏贴时用 `gh issue edit \u003CN> --add-label area-X --add-label type-X --add-label cx-X` 补；建单前 `issue-labels.sh validate` 强制门正常会先拦截，此为绕过门（raw gh \u002F web UI）后的补救。\n\n## B2. 编辑 label \u002F 关闭 issue\n\n```bash\ngh issue edit \u003CN> --add-label area-data --remove-label area-eventing      # 改领域\ngh issue edit \u003CN> --add-label type-debt                                   # 加类型\ngh issue close \u003CN> --reason completed --comment \"Fixed in PR #\u003CNNN>\"      # 修复闭合\ngh issue close \u003CN> --reason \"not planned\" --comment \"\u003C理由>\"              # wontfix\n```\n\nepic 用 `epic` label + GitHub 原生 sub-issue（不手写 body task list）。子任务关联用 issue 页 \"Create sub-issue\"\n或 `gh`（sub-issue API）。wave 排序见 Part A。\n\n## B3. PR 状态 label 流转（编排）\n\n> 两正交轴（pr-status 流转 \u002F pr-review 结论）的取值与「何时切」语义见 `.github\u002Fproject-template\u002FPROJECT.md` §2.5 + §5（单源，不在此复制表）。**两轴各自互斥**：pr-status 恰好一个；pr-review `approved` XOR `changes-requested`——**切一侧必 `--remove-label` 同轴对侧**。本节只给切换命令。\n\n```bash\n# ship 后：待再审（首次交接，唯一使用 needs-review-again 的地方）\ngh pr edit \u003CN> --add-label pr-status\u002Fneeds-review-again --remove-label pr-status\u002Fin-progress\n# review 轮结论（默认 \u002Fpr-review 或 codex；review 轴互斥）\n# 有 finding → changes-requested + needs-fix（5-state：review 轮 changes-requested 始终切 needs-fix）\ngh pr edit \u003CN> --add-label pr-review\u002Fchanges-requested --add-label pr-status\u002Fneeds-fix --remove-label pr-review\u002Fapproved --remove-label pr-status\u002Fneeds-review-again\n# 无 finding → approved + pr-status\u002Fready（无需 fix\u002Fcheck 的终态）\ngh pr edit \u003CN> --add-label pr-review\u002Fapproved --add-label pr-status\u002Fready --remove-label pr-review\u002Fchanges-requested --remove-label pr-status\u002Fneeds-review-again\n# fix 后：待 --check 验证（fix 不直接到 ready）\ngh pr edit \u003CN> --add-label pr-status\u002Fneeds-check-fix --remove-label pr-status\u002Fneeds-fix\n# --check 全修复：可合并（清 pr-status 前态 + review 轴对侧）\ngh pr edit \u003CN> --add-label pr-status\u002Fready --add-label pr-review\u002Fapproved --remove-label pr-status\u002Fneeds-check-fix --remove-label pr-review\u002Fchanges-requested\n# --check 有未修\u002F回归：回 fix（清 pr-status 前态 + review 轴对侧）\ngh pr edit \u003CN> --add-label pr-review\u002Fchanges-requested --add-label pr-status\u002Fneeds-fix --remove-label pr-status\u002Fneeds-check-fix --remove-label pr-review\u002Fapproved\n```\n\n## B4. PR 评论（编排）\n\n留痕约定 \u002F 标记规则见 `.github\u002Fproject-template\u002FPROJECT.md` §5；评论格式（`pm:ship` \u002F `pm:fix` \u002F `pm:pr-review` 三模板 + footer）见 `.github\u002Fproject-template\u002Fpr-comment.md`。本节是贴评论命令 + **回显 comment id** 的单源（ship\u002Ffix\u002Fpr-review 引用本节，不重印）：\n\n```bash\nURL=$(gh pr comment \u003CN> --body-file \u003C填好的 pr-comment.md 模板>)   # stdout = https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fpull\u002F\u003CN>#issuecomment-\u003Cid>（实测返回，成功 exit 0）\necho \"✅ 已贴评论：$URL\"                                            # 必须回显给用户；comment id = URL 尾段 #issuecomment-\u003Cid>\n```\n\n- stdout 即评论 URL（含 `#issuecomment-\u003Cid>`）——**贴完必须捕获并回显**，便于用户跳转 \u002F 引用该评论。\n- 命令非 0 退出 → 报错退出，不静默跳过。\n- footer 格式见 `.github\u002Fproject-template\u002Fpr-comment.md`（PR#\u002F工具\u002F分支\u002Fworktree\u002Fsession，AI 自填）。\n\n## B5. PR 冲突预检 + CI 跟进（ship\u002Ffix 共用）\n\npush 后流程分**两阶段**：① 冲突预检（阻塞，贴评论前必过）→ 立即收尾（贴评论 + 切 label，不等 CI）→ ② CI 异步收敛（收尾后再跑，结果贴独立 pm:ci 评论）。\n\n**① 冲突预检**（阻塞，必须先于收尾）：`gh pr view \u003CN> --json mergeable,mergeStateStatus`。`mergeable` 由 GitHub **异步计算**，刚 push 常返回 `UNKNOWN`——**轮询几次（~5-10s 间隔）直到落定** `MERGEABLE` \u002F `CONFLICTING`，单查 UNKNOWN 无效。`CONFLICTING`（或 `mergeStateStatus=DIRTY`）→ 先解冲突：`git -C \u003Cwt> fetch origin && git -C \u003Cwt> merge origin\u002Fdevelop --no-edit`（解冲突 → commit → push）→ 回本步重检。`MERGEABLE` → 立即进行收尾（贴评论 + 切 label），**不等 CI**。\n\n**② CI 异步收敛**（收尾评论 + label 切换之后再跑）：本仓 PR CI 五个 check 并行跑，**典型 ~5-6 min**（实测最慢 PR Check 中位 ~4.6 \u002F 峰值 ~5.5 min；Governance ~4-5 min；Race \u002F Static ~3 min；govulncheck ~40s）。\n\n```bash\n# 阻塞轮询直到所有 check 完成（exit 0=全绿 \u002F 8=pending \u002F 非0=有失败；--fail-fast 见首个失败即退）\ngh pr checks \u003CN> --watch --interval 30 --fail-fast       # Bash timeout 设 ~600000ms（10min 工具上限）；预计 6min 内返回\n# 失败 → 列失败 check（精确到 PR head，bucket=fail）+ run 链接\ngh pr checks \u003CN> --json name,bucket,link --jq '.[] | select(.bucket==\"fail\") | [.name,.link] | @tsv'\ngh run view \u003Crun-id> --job \u003Cjob-id> --log-failed         # link=\u002Factions\u002Fruns\u002F\u003Crun-id>\u002Fjob\u002F\u003Cjob-id>：中段 run-id、末段 job-id（裸 job-id 给 gh run view 会 404）\n```\n\n- **等待上限 ~12-15 min**（~2.5× 典型，吸收 runner 排队）。超 Bash 10min 上限用后台轮询兜底（`run_in_background` 跑 watch，或循环 `gh pr checks \u003CN> --json bucket --jq 'any(.[]; .bucket==\"pending\")'` 间隔 30-60s）；超上限仍 pending → 停下报告，不无限等。\n- 失败 → 回 `fix` 修复循环（定位 → 修 → commit → push → 重新预检），**最多 3 轮**；**3 轮仍红 → 停下交人工，不 AskUserQuestion**。\n- CI 收敛后（全绿或 3 轮红）贴独立 `pm:ci` 评论（`verdict=ci-green` 或 `verdict=ci-failed`），不合并进主 pm:ship \u002F pm:fix 评论。\n\n## B6. 沟通规则\n\n- label 编辑 \u002F PR 状态切换 \u002F 评论：按流程自动执行，不逐条问。\n- CI watch \u002F 取失败日志：自动执行；CI 修复 3 轮仍红 → 贴 PR 评论留痕 + 停下交人工（不 AskUserQuestion）。\n","# issues — 项目管理单源（Epic\u002FWave + Issue\u002FPR\u002FLabel\u002F评论）\n\n> 真源 = GitHub Issues + Project v2 #3。**内容\u002F结构 + 治理全在 `.github\u002Fproject-template\u002F`**：issue body → `backlog.md`\u002F`epic.md`，PR body → `pull_request_template.md`，PR 评论 → `pr-comment.md`，label\u002F字段\u002F评级\u002F流程 → `PROJECT.md`（索引见 `README.md`）。本技能只负责编排，不复制模版内容。\n> 输入分派：**`epic #N` \u002F 带 `epic` label 的 issue** → Part A（拆解 + wave 调度）；**普通 issue 号（无 `epic` label）** → 下方「非 epic issue 状态核查」；**动词**（create \u002F edit \u002F pr-status \u002F comment）→ Part B 原子操作。\n> create issue 前先 search 查重（幂等）。\n> 仓库：`ghbvf\u002Fgocell`。Project v2：`--owner ghbvf --number 3`（title `gocell`）。\n\n---\n\n## 非 epic issue 状态核查（查代码判状态，只判不修）\n\n输入普通 issue 号（无 `epic` label）时，不排 wave，而是查代码判断该 issue 是否仍成立：\n\n1. `gh issue view \u003CN> --json title,body,labels` 读问题描述 + body 的 Files。\n2. 按 Files \u002F 关键字 Read\u002FGrep 定位代码；跨 3+ 文件时并行派 `Agent(Explore)` 核查。\n3. 判状态（**只判不修**）：**存在** \u002F **已修复**（给证据：哪行 \u002F 哪 PR）\u002F **已变更**（形态变化）\u002F **无法确认**。\n4. 输出状态 + 证据 + 建议：需修 → 建议 `\u002Fship #\u003CN>`（或定位到 file:line 后 `\u002Ffix`）；已修复 \u002F 过期 → 建议 Part B 关闭（`gh issue close --reason ...`）。\n\n---\n\n# Part A — Epic 拆解 + Wave 实施顺序评论\n\n> 负责 epic 级「找子任务 → 排 wave → 追加 epic 评论」。不写 Project 字段，不改 epic body；issue\u002Flabel\u002F评论原子操作见 Part B。\n\n## A1. 读 epic → 关键字查找相关 issues → 关联 → 汇总子 issues\n\n1. **读 epic**：`gh issue view \u003Cepic#> --json number,title,body,labels`（确认 epic label；从 title + 目标\u002F范围提取关键字）。\n2. **关键字查找相关 issues**：`gh issue list --search \"\u003C关键字>\" --state open --json number,title,labels`，挑出属于本 epic 的候选；用 AskUserQuestion 确认候选集（不擅自全关联）。\n3. **关联到 epic**（建 sub-issue 关系，已是 sub-issue 的跳过）：\n   ```bash\n   id=$(gh api repos\u002Fghbvf\u002Fgocell\u002Fissues\u002F\u003Cchild#> --jq .id)   # 取整数 id（非 number）\n   gh api --method POST repos\u002Fghbvf\u002Fgocell\u002Fissues\u002F\u003Cepic#>\u002Fsub_issues -F sub_issue_id=$id\n   ```\n4. **汇总子 issues**：`gh api repos\u002Fghbvf\u002Fgocell\u002Fissues\u002F\u003Cepic#>\u002Fsub_issues --jq '.[]|{number,title,state}'`（含新关联）；对每个 OPEN 子任务读 label（area\u002Ftype\u002Fpri）+ body 的 `Blocked-by: #NNN`（多行\u002F逗号分隔，无声明=无前置）。\n\n> 子任务跨 3+ 包或描述模糊时，用 `Agent(Explore)` 核实归属 \u002F 状态 \u002F `Blocked-by` 再汇总（**wave 内冲突分区 + 实施顺序的分析在 A2 第 6 步，见下**）。\n\n## A2. 建 blocked-by DAG + wave 容量装箱排序（每 wave ≤4，Wave 1-4 有界）\n\n**滚动 + 有界 + 容量装箱算法**（每次更新 epic 都重跑；作用域 = epic 的 **OPEN** 子任务）。wave 不再纯=依赖深度，而是「依赖约束 + 每 wave ≤4 容量」的贪心 list-scheduling——**pri 决定容量受限时谁进早 wave**：\n\n1. **节点 = OPEN 子任务**；CLOSED（已完成）子任务**排除**——不参与排序，仅在评论中单列为已完成。\n2. 有向边 `blocker → dependent`（来自 `Blocked-by`），**仅当 blocker 也 OPEN**；blocker 已 close = 依赖已满足 → 删该边。**这是「滚动」的来源**：前置完成后 dependent 自动前移到更早 wave。\n3. 检测环：若有环，AskUserQuestion 让用户裁定断哪条边（不静默）。\n4. **逐 wave w=1..4 贪心装箱**（每 wave 至多 **4** 个 issue）：\n   - `ready 集` = 全部 blocker 都已分到**更早** wave 的未分配 OPEN 节点（无 blocker 的节点天然 ready）。\n   - ready 集按 `pri`(p0>p1>p2>p3) → **基础性产出先** → `Cx`(小先，由 `cx-X` label 提供) → issue# 排序，取前 **≤4** 入 wave w。\n   - 其余（含同深度溢出、blocker 刚入本 wave 而本轮未 ready 的）**留待下一 wave**（溢出顺延）。\n5. **有界 cap = Wave 4**：装箱到 Wave 4 仍未分配的节点标记 **超窗**，在评论中单列，不写任何 Project 字段。\n6. **wave 内冲突分区**（确认「真并行」vs「须串行」）：对每个 wave（成员 ≥2）**并行**派 `Agent(Explore)` 分析其中每个任务的 scope \u002F 触碰文件 \u002F 产出↔消费 \u002F 风险，主 agent 汇总后切：\n   - **并行组**：两两**无文件重叠 + 无隐式产出↔消费 + 无资源冲突** → 可同时跑（≤4 并行 agent）。「可并行」= 经冲突分析确认无冲突，**非**仅「无 `Blocked-by`」。\n   - **串行链**：有上述任一冲突 → 须串行，链内按 `pri` → 基础性产出先 → `Cx` → issue# 定序，并注明冲突原因（如「同改 foo.go」）。\n   - 单任务 wave 跳过分析。\n7. 输出每个 OPEN 子任务的 `(wave, 并行组\u002F串行链, 链内序)` 或「超窗」。\n\n呈现给用户的 dry-run 表（只列 OPEN；超窗与已完成单列）：\n\n```\nWave 1（依赖深度1，取 pri 前4）:\n  并行组 A（零冲突，可同时）: #a(p0·Cx1)  #b(p0·Cx2)\n  串行链 B（#c→#d 同改 foo.go，按 pri）: [1] #c(p1·Cx2)  [2] #d(p2·Cx1)\nWave 2（深度1溢出 + 依赖 Wave 1）:\n  并行组 A: #e(p3·Cx1 深度1溢出)  #g(p1·Cx2 ←blocked-by #a)\n超窗(>W4，评论单列): #z(依赖链\u002F装箱 >4)\n已完成(不动): #y\n```\n\n## A3. 追加 epic 实施顺序评论\n\n```bash\n# 只追加评论；不编辑 epic body，不写 Project 字段。\ngh issue comment \u003Cepic#> --body \"$(cat \u003C\u003C'C'\n\u003C!-- pm:epic-wave -->\n? Epic 实施顺序更新：每 wave ≤4 容量装箱，OPEN 按 pri 排 Wave 1-4；wave 内标明并行组 \u002F 串行链；已完成与超窗(>W4)单列。排序结果只写在本评论中，不写 Project 字段，不改 epic body。\n\n\u003C粘贴 A2 dry-run 表>\nC\n)\"\n```\n\n## A4. 沟通规则\n\n- 环检测命中：停下 AskUserQuestion。\n- DAG 排序结果先 dry-run 呈现，确认后只追加 epic 评论。\n- 不改子任务代码 \u002F 不关 issue \u002F 不改 area-type-pri label（那是 Part B \u002F `fix` 职责）。\n\n---\n\n# Part B — Issue \u002F PR \u002F Label \u002F 评论\n\n> issue\u002FPR 的 `gh` 编排，是 issue\u002FPR\u002Flabel\u002F评论**固定 gh 命令形态的单源**——ship\u002Ffix\u002Fpr-review 引用本部分，不重印命令。body 骨架见 `.github\u002Fproject-template\u002F` 的 `backlog.md` \u002F `epic.md` \u002F `pull_request_template.md`；PR 评论格式见 `pr-comment.md`；label \u002F 字段 \u002F 评级 rubric 见 `PROJECT.md`。本部分不复制模版内容。\n\n## B1. 新建 backlog issue\n\n四轴 label 齐全（area + type + pri + cx）+ `backlog`，全部 CLI 显式贴（pri\u002Fcx 必填，cx 无 unknown sentinel）：\n\n```bash\n# 建单前强制门：校验 area\u002Ftype\u002Fpri\u002Fcx 四轴完整（exit 0 才执行 create；下游 selftest-locked，见 PROJECT.md §2.6）\nbash hack\u002Fautomation\u002Fissue-labels.sh validate --labels \"backlog,pri-p2,area-eventing,type-bug,cx-2\"\ngh issue create \\\n  --label backlog --label pri-p2 --label area-eventing --label type-bug --label cx-2 \\\n  --title \"[\u003CID>] \u003C简短标题>\" --body-file \u003C填好的 backlog.md>\n# body 骨架单源 = .github\u002Fproject-template\u002Fbacklog.md（现状 \u002F 修复方向 \u002F Files \u002F Trigger \u002F Source）——本技能不复制其结构\n```\n\n> **由 review\u002Ffix finding（OUT_OF_SCOPE \u002F 派生）成文时**：body 按 `backlog.md` 顶部的字段映射**无损**填充，不得一句话带过——否则后续无法据此修复；并从 finding 的 `[…Cx…]` tag 取 `--label cx-X` 一并贴。\n\n- **area-XX**（1 个，8 选）：见 `.github\u002Fproject-template\u002FPROJECT.md` §2.1。\n- **type-XX**（1 个，8 选）：见 §2.2。\n- **pri-pX**：评级 rubric 见 `.github\u002Fproject-template\u002FPROJECT.md` §3。`\u002Ffix` 派生默认 `pri-p2`；`pri-p0` 仅 incident-driven，停下 AskUserQuestion 确认。\n- **cx-X**（必填）：复杂度 rubric 见 `.github\u002Fproject-template\u002FPROJECT.md` §3.2 \u002F §2.6。建单前必须定级并显式 `--label cx-X`（与 pri 对称，无 unknown sentinel——定不到级也要就近取一档）；finding 派生从 `[…Cx…]` tag 取。epic 例外（不贴 cx）。\n- **flag-cond**（可选）：条件延后型加此 label + body 写 `## Trigger`。\n\n> P0 红线不得默认贴。area\u002Ftype\u002Fcx 漏贴时用 `gh issue edit \u003CN> --add-label area-X --add-label type-X --add-label cx-X` 补；建单前 `issue-labels.sh validate` 强制门正常会先拦截，此为绕过门（raw gh \u002F web UI）后的补救。\n\n## B2. 编辑 label \u002F 关闭 issue\n\n```bash\ngh issue edit \u003CN> --add-label area-data --remove-label area-eventing      # 改领域\ngh issue edit \u003CN> --add-label type-debt                                   # 加类型\ngh issue close \u003CN> --reason completed --comment \"Fixed in PR #\u003CNNN>\"      # 修复闭合\ngh issue close \u003CN> --reason \"not planned\" --comment \"\u003C理由>\"              # wontfix\n```\n\nepic 用 `epic` label + GitHub 原生 sub-issue（不手写 body task list）。子任务关联用 issue 页 \"Create sub-issue\"\n或 `gh`（sub-issue API）。wave 排序见 Part A。\n\n## B3. PR 状态 label 流转（编排）\n\n> 两正交轴（pr-status 流转 \u002F pr-review 结论）的取值与「何时切」语义见 `.github\u002Fproject-template\u002FPROJECT.md` §2.5 + §5（单源，不在此复制表）。**两轴各自互斥**：pr-status 恰好一个；pr-review `approved` XOR `changes-requested`——**切一侧必 `--remove-label` 同轴对侧**。本节只给切换命令。\n\n```bash\n# ship 后：待再审（首次交接，唯一使用 needs-review-again 的地方）\ngh pr edit \u003CN> --add-label pr-status\u002Fneeds-review-again --remove-label pr-status\u002Fin-progress\n# review 轮结论（默认 \u002Fpr-review 或 codex；review 轴互斥）\n# 有 finding → changes-requested + needs-fix（5-state：review 轮 changes-requested 始终切 needs-fix）\ngh pr edit \u003CN> --add-label pr-review\u002Fchanges-requested --add-label pr-status\u002Fneeds-fix --remove-label pr-review\u002Fapproved --remove-label pr-status\u002Fneeds-review-again\n# 无 finding → approved + pr-status\u002Fready（无需 fix\u002Fcheck 的终态）\ngh pr edit \u003CN> --add-label pr-review\u002Fapproved --add-label pr-status\u002Fready --remove-label pr-review\u002Fchanges-requested --remove-label pr-status\u002Fneeds-review-again\n# fix 后：待 --check 验证（fix 不直接到 ready）\ngh pr edit \u003CN> --add-label pr-status\u002Fneeds-check-fix --remove-label pr-status\u002Fneeds-fix\n# --check 全修复：可合并（清 pr-status 前态 + review 轴对侧）\ngh pr edit \u003CN> --add-label pr-status\u002Fready --add-label pr-review\u002Fapproved --remove-label pr-status\u002Fneeds-check-fix --remove-label pr-review\u002Fchanges-requested\n# --check 有未修\u002F回归：回 fix（清 pr-status 前态 + review 轴对侧）\ngh pr edit \u003CN> --add-label pr-review\u002Fchanges-requested --add-label pr-status\u002Fneeds-fix --remove-label pr-status\u002Fneeds-check-fix --remove-label pr-review\u002Fapproved\n```\n\n## B4. PR 评论（编排）\n\n留痕约定 \u002F 标记规则见 `.github\u002Fproject-template\u002FPROJECT.md` §5；评论格式（`pm:ship` \u002F `pm:fix` \u002F `pm:pr-review` 三模板 + footer）见 `.github\u002Fproject-template\u002Fpr-comment.md`。本节是贴评论命令 + **回显 comment id** 的单源（ship\u002Ffix\u002Fpr-review 引用本节，不重印）：\n\n```bash\nURL=$(gh pr comment \u003CN> --body-file \u003C填好的 pr-comment.md 模板>)   # stdout = https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fpull\u002F\u003CN>#issuecomment-\u003Cid>（实测返回，成功 exit 0）\necho \"✅ 已贴评论：$URL\"                                            # 必须回显给用户；comment id = URL 尾段 #issuecomment-\u003Cid>\n```\n\n- stdout 即评论 URL（含 `#issuecomment-\u003Cid>`）——**贴完必须捕获并回显**，便于用户跳转 \u002F 引用该评论。\n- 命令非 0 退出 → 报错退出，不静默跳过。\n- footer 格式见 `.github\u002Fproject-template\u002Fpr-comment.md`（PR#\u002F工具\u002F分支\u002Fworktree\u002Fsession，AI 自填）。\n\n## B5. PR 冲突预检 + CI 跟进（ship\u002Ffix 共用）\n\npush 后流程分**两阶段**：① 冲突预检（阻塞，贴评论前必过）→ 立即收尾（贴评论 + 切 label，不等 CI）→ ② CI 异步收敛（收尾后再跑，结果贴独立 pm:ci 评论）。\n\n**① 冲突预检**（阻塞，必须先于收尾）：`gh pr view \u003CN> --json mergeable,mergeStateStatus`。`mergeable` 由 GitHub **异步计算**，刚 push 常返回 `UNKNOWN`——**轮询几次（~5-10s 间隔）直到落定** `MERGEABLE` \u002F `CONFLICTING`，单查 UNKNOWN 无效。`CONFLICTING`（或 `mergeStateStatus=DIRTY`）→ 先解冲突：`git -C \u003Cwt> fetch origin && git -C \u003Cwt> merge origin\u002Fdevelop --no-edit`（解冲突 → commit → push）→ 回本步重检。`MERGEABLE` → 立即进行收尾（贴评论 + 切 label），**不等 CI**。\n\n**② CI 异步收敛**（收尾评论 + label 切换之后再跑）：本仓 PR CI 五个 check 并行跑，**典型 ~5-6 min**（实测最慢 PR Check 中位 ~4.6 \u002F 峰值 ~5.5 min；Governance ~4-5 min；Race \u002F Static ~3 min；govulncheck ~40s）。\n\n```bash\n# 阻塞轮询直到所有 check 完成（exit 0=全绿 \u002F 8=pending \u002F 非0=有失败；--fail-fast 见首个失败即退）\ngh pr checks \u003CN> --watch --interval 30 --fail-fast       # Bash timeout 设 ~600000ms（10min 工具上限）；预计 6min 内返回\n# 失败 → 列失败 check（精确到 PR head，bucket=fail）+ run 链接\ngh pr checks \u003CN> --json name,bucket,link --jq '.[] | select(.bucket==\"fail\") | [.name,.link] | @tsv'\ngh run view \u003Crun-id> --job \u003Cjob-id> --log-failed         # link=\u002Factions\u002Fruns\u002F\u003Crun-id>\u002Fjob\u002F\u003Cjob-id>：中段 run-id、末段 job-id（裸 job-id 给 gh run view 会 404）\n```\n\n- **等待上限 ~12-15 min**（~2.5× 典型，吸收 runner 排队）。超 Bash 10min 上限用后台轮询兜底（`run_in_background` 跑 watch，或循环 `gh pr checks \u003CN> --json bucket --jq 'any(.[]; .bucket==\"pending\")'` 间隔 30-60s）；超上限仍 pending → 停下报告，不无限等。\n- 失败 → 回 `fix` 修复循环（定位 → 修 → commit → push → 重新预检），**最多 3 轮**；**3 轮仍红 → 停下交人工，不 AskUserQuestion**。\n- CI 收敛后（全绿或 3 轮红）贴独立 `pm:ci` 评论（`verdict=ci-green` 或 `verdict=ci-failed`），不合并进主 pm:ship \u002F pm:fix 评论。\n\n## B6. 沟通规则\n\n- label 编辑 \u002F PR 状态切换 \u002F 评论：按流程自动执行，不逐条问。\n- CI watch \u002F 取失败日志：自动执行；CI 修复 3 轮仍红 → 贴 PR 评论留痕 + 停下交人工（不 AskUserQuestion）。\n",{"name":5,"description":7,"allowed-tools":42,"argument-hint":47},[43,44,31,45,46],"Read","Grep","Agent","AskUserQuestion","\u003Cepic #N | #issue（非epic→状态核查）| create-issue | edit-labels | pr-status | comment> [...]","develop","043add59bbe840e4a90a4253feec21f074b590dd",".claude\u002Fskills\u002Fissues",0,"https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell","https:\u002F\u002Fgithub.com\u002Fghbvf","2026-06-20 14:38:06",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add ghbvf\u002Fgocell --skill issues",{"tool":61,"command":62},"bunx","bunx skills add ghbvf\u002Fgocell --skill issues",{"tool":64,"command":65},"pnpm","pnpm dlx skills add ghbvf\u002Fgocell --skill issues","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Fissues\u002FSKILL.md",true,[],[70,86,101,107,117,124],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":37},"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",[],[72,31,77,78,18,29,79,80,30,81,82,83,35,84,85],"l2","id","edit","write","reviewer","grep","worktree","tdd","review",{"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":97,"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",[92],{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[35,98,85,82,31,99,81,100,29,30],"pr review","check","diff",{"skillNo":102,"name":5,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":37},"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",[],[5,19,20,21,22,23,24,25,26,27,31,28,29,30,32,33,34,35,36,18],{"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":37},"01M6KSV7CX440Q82S9VXQJH02G","git-worktree","Git Worktree 项目约定（编号、基准分支、权限兼容、删除安全）。","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Fgit-worktree\u002FSKILL.md",[],[114,83,115,116],"git","git worktree","安全",{"skillNo":118,"name":29,"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":37},"01M6KSV5JB0AR3EJ9V2H4F2MN2","问题诊断与修复: 验证+根因+复杂度分级+修复方案+backlog登记。当用户说'这个问题存在吗''帮我分析这个bug''诊断一下这个模块''修复这个问题'时触发。支持单条问题和多方审查报告批量输入。","https:\u002F\u002Fgithub.com\u002Fghbvf\u002Fgocell\u002Fblob\u002Fdevelop\u002F.codex\u002Fskills\u002Ffix\u002FSKILL.md",[],[29,123,79,80,30,82,31],"文件",{"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":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",[],[131,132,133,134,135,136,137,138,139,140,27,141,142,143,5,144,145,146,28,147],"speckit taskstoissues","speckit","structure","for","true","kit","with","spec-kit","actionable","feature","Existing","convert","specify","artifacts","tasks","project structure","design"]