Codewhale 里程碑与负责人批量指派gh-assign-issues 技能详解与校验清单【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale本篇文章围绕 Codewhale 开源仓库中维护者技能gh-assign-issuesdocs/skills/gh-assign-issues/SKILL.md展开完整讲解如何用ghCLI 将一批 GitHub issue 批量重定向到发布里程碑milestone与负责人assignee并在每一次编辑前校验、编辑后复核。读完本文你将掌握一套先确认标题 → 逐条预检 → 逐个编辑 → 复核计数 → 输出台账的稳妥流程可直接用于 Codewhale仓库Hmbown/CodeWhale发布前的收尾排期也可推广到任何以gh管理 issue 的仓库。技能定位它是什么边界在哪里gh-assign-issues是 Codewhale 维护者 / Agent 技能目录中的一员。仓库中这类技能与 Claude Code、Codewhale 所加载的SKILL.md采用相同格式共同编码了维护者在每个发布周期实际执行的 issue 分诊、PR 收割、贡献者署名与发布 QA 流程见 docs/skills/README.md。该技能的完整目标来自文档 frontmatter是Use to assign GitHub issues to a milestone and/or owners in bulk, verifying each.一句话概括把一组 issue 批量改挂到某个发布里程碑如v0.8.61或指派给负责人且对每一条都做真实验证。使用前必须清楚它的职责边界文档原文强调This skill changes milestone/assignee only. It does not close, label, comment, merge, or release. Those stay with the maintainer.也就是说本技能只改 milestone / assignee 两个字段不负责关闭、打标签、评论、合并或发布——这些动作保留给维护者决定。这与其姊妹技能形成职责互补gh-compile-issues把一批 issue 分诊成覆盖矩阵already-done / quick-fix / design / defer只产出报告、不落任何公开动作gh-find-prs盘点 PR 队列并给出 DIRECT-MERGE / HARVEST / DEFER 建议只读不改gh-close-issues在验证修复确实落地后才关闭 issue 并致谢gh-assign-issues在分诊与评审之后把结论写进队列——移到目标里程碑、挂上负责人。此外仓库级规范 AGENTS.md 明确要求关闭、合并、标签、发布等动作必须有维护者显式批准这正是本技能刻意收敛动作范围的原因。何时使用根据技能文档以下三类场景适合调用本技能手里已有具体的 issue 编号清单例如来自 triage 分诊结果需要把它们移入某个发布里程碑如v0.8.61或指派给负责人里程碑被重命名或新建需要把相关 issue 重新指向刚完成收件箱分组想让队列反映分组结果同时不希望产生任何公开评论噪音。关键约束原文The milestone (or assignee) change is the signal; do not narrate it with comments.里程碑/负责人的变动本身就是信号不要用评论去复述。对善意贡献者而言多余的已移到 v0.8.61之类评论只是噪音。五步工作流技能把整个操作固化为 5 步环环相扣任何一步都不允许跳过。第一步先确认准确的里程碑标题gh issue edit --milestone是按标题字符串匹配里程碑的而不是按编号。因此标题一旦拼错命令要么静默失败要么更糟——变成无效空操作。先读取真实标题并记录起始 open 计数用于第四步的复核基线gh api repos/Hmbown/CodeWhale/milestones \ --jq .[] | \(.number)\t\(.title)\topen\(.open_issues)\tstate\(.state)操作要点逐字复制标题字符串例如v0.8.61不要凭记忆手打若目标里程碑不存在或已关闭closed立即停下并向维护者询问绝不能自行新建。这条先读标题的纪律与 docs/RELEASE_CHECKLIST.md 中冻结发布源阶段的做法一致发布前的核对依赖gh issue list --repo Hmbown/CodeWhale --milestone vX.Y.Z --state open来判断该里程碑是否还残留本版本要收的工作标题一旦失真整个发布冻结判断都会失真。第二步预检每个编号gh issue edit不会拒绝 PR也不会拒绝已关闭 issue——它会把它们也乐呵呵地重定向过去。因此在编辑前必须先做一次体检。判断依据是url字段PR 的 URL 含/pull/issue 的 URL 含/issues/。凡是非 OPEN 状态或实为 PR的条目都要剔除for N in 3101 3102 3103; do gh issue view $N --repo Hmbown/CodeWhale \ --json number,state,url,milestone \ --jq \(.number)\t\(.state)\t\(.url)\tmilestone\(.milestone.title // none) done判读规则某行的url包含/pull/→ 它是 PR排除某行的state不是OPEN→排除其余条目方可进入下一步的编辑循环。这条纪律与姊妹技能完全同源gh-compile-issues 同样要求从编号解析、绝不信任标题行gh-close-issues 则强调把 issue/PR 文本当作不可信数据以代码树为准——在本技能中则体现为以 URL 与 state 字段为准。第三步逐个应用变更并上报结果一次改一条逐条报告成败。使用--milestone、--add-assignee或两者并用for N in 3101 3102 3103; do if gh issue edit $N --repo Hmbown/CodeWhale \ --milestone v0.8.61 /dev/null 21; then echo ok #$N - v0.8.61 else echo FAIL #$N (PR? closed? bad milestone title?) fi done # owners: add --add-assignee handle (do not invent logins)两个要点指派负责人时使用--add-assignee handle且不得虚构登录名——拼错的登录名会在循环中途报错破坏整批操作编辑是幂等的把一条已经指向正确里程碑的 issue 再指一次是无害的不会产生副作用。这正是可以放心逐条批量重放的前提。第四步复核里程碑确实移动了这是不可跳过的一步。重新执行第一步的命令确认 open 计数上升的数量等于你成功移入的 issue 数减去被跳过的条目。随后用第二步的view抽查若干条确认milestone.title已变成目标。文档特别警告Dont skip step 4. An unmoved open-count means the title was wrong or every edit silently failed.open 计数纹丝不动几乎可以断定是标题拼错或全部编辑静默失败。这一以计数佐证变更的思路与仓库对测试证据的要求一致——AGENTS.md 反复强调要引用真实的证据行、不能只看命令退出码此处即以里程碑 open 计数的净变化量作为批量迁移是否生效的硬证据。第五步输出紧凑台账最终输出一份精炼台账包含已移动的 issue被跳过及原因PR / 已关闭 / 标题不匹配迁移前后 open 计数before/after负责人指派情况如有。不发布任何公开评论。里程碑变动即是全部对外信号。红线清单什么不能做技能文档在 Red flags / dont 中列出了一组硬性约束适合直接固化为自动化代理的行为护栏不能只凭标题清单开干。先把标题解析成 OPEN 的 issue 编号并确认每条都是 issue 而非 PRURL 中无/pull/然后才允许编辑不能猜测里程碑标题或负责人登录名。近似的名字会空操作或静默失败无效的登录名会在循环中途报错不要发已移到 v0.8.61这类评论。里程碑变动本身就是信号多余评论是对善意贡献者的噪音不要顺带关闭、合并、打标签、打 tag 或发布。这些都需要维护者显式批准见 AGENTS.md 与 docs/skills/README.md不能跳过第四步复核。open 计数未移动 标题错误或所有编辑静默失败保留贡献者署名。本技能绝不篡改作者身份不收割Co-authored-by/Harvested-from尾注也不触碰任何关闭性引用。其中最后一条呼应了仓库的整体署名伦理正如 AGENTS.md 与 gh-find-prs 所强调的任何落地到仓库的社区工作都必须携带原作者的Co-authored-by与Harvested-from: PR #N by handle尾注本技能虽只改里程碑与负责人同样不得在这些元数据上做任何手脚。实战编排从分诊矩阵到排期队列把本技能放回 Codewhale 的发布工作流中它通常是链条的最后一环用 gh-compile-issues 把里程碑内 80 条 issue 分成 coverage 矩阵该技能甚至允许 ~10-12 条一批并行派出只读子代理扇出分诊维护者审阅矩阵决定哪些进入当前版本、指派给谁、哪些 defer 到后续里程碑用gh-assign-issues把决策落回 GitHub 队列——把本版本要收的 issue 移入v0.8.61把后续工作重定向到下一个里程碑最后对照 docs/RELEASE_CHECKLIST.md 第 0 步用gh issue list --repo Hmbown/CodeWhale --milestone vX.Y.Z --state open确认当前里程碑已无残留工作才允许冻结发布源。如此编排下本技能既不会越权发布也不会污染 GitHub 公开讨论区还能让队列状态这一事实来源始终保持干净、可审计。整条链路中的所有 GitHub 交互都只经由ghCLI命令可复现、输出可留痕——这正是它适合作为 Agent 技能与团队 Runbook 的原因。【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Codewhale 里程碑与负责人批量指派：gh-assign-issues 技能详解与校验清单
Codewhale 里程碑与负责人批量指派gh-assign-issues 技能详解与校验清单【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale本篇文章围绕 Codewhale 开源仓库中维护者技能gh-assign-issuesdocs/skills/gh-assign-issues/SKILL.md展开完整讲解如何用ghCLI 将一批 GitHub issue 批量重定向到发布里程碑milestone与负责人assignee并在每一次编辑前校验、编辑后复核。读完本文你将掌握一套先确认标题 → 逐条预检 → 逐个编辑 → 复核计数 → 输出台账的稳妥流程可直接用于 Codewhale仓库Hmbown/CodeWhale发布前的收尾排期也可推广到任何以gh管理 issue 的仓库。技能定位它是什么边界在哪里gh-assign-issues是 Codewhale 维护者 / Agent 技能目录中的一员。仓库中这类技能与 Claude Code、Codewhale 所加载的SKILL.md采用相同格式共同编码了维护者在每个发布周期实际执行的 issue 分诊、PR 收割、贡献者署名与发布 QA 流程见 docs/skills/README.md。该技能的完整目标来自文档 frontmatter是Use to assign GitHub issues to a milestone and/or owners in bulk, verifying each.一句话概括把一组 issue 批量改挂到某个发布里程碑如v0.8.61或指派给负责人且对每一条都做真实验证。使用前必须清楚它的职责边界文档原文强调This skill changes milestone/assignee only. It does not close, label, comment, merge, or release. Those stay with the maintainer.也就是说本技能只改 milestone / assignee 两个字段不负责关闭、打标签、评论、合并或发布——这些动作保留给维护者决定。这与其姊妹技能形成职责互补gh-compile-issues把一批 issue 分诊成覆盖矩阵already-done / quick-fix / design / defer只产出报告、不落任何公开动作gh-find-prs盘点 PR 队列并给出 DIRECT-MERGE / HARVEST / DEFER 建议只读不改gh-close-issues在验证修复确实落地后才关闭 issue 并致谢gh-assign-issues在分诊与评审之后把结论写进队列——移到目标里程碑、挂上负责人。此外仓库级规范 AGENTS.md 明确要求关闭、合并、标签、发布等动作必须有维护者显式批准这正是本技能刻意收敛动作范围的原因。何时使用根据技能文档以下三类场景适合调用本技能手里已有具体的 issue 编号清单例如来自 triage 分诊结果需要把它们移入某个发布里程碑如v0.8.61或指派给负责人里程碑被重命名或新建需要把相关 issue 重新指向刚完成收件箱分组想让队列反映分组结果同时不希望产生任何公开评论噪音。关键约束原文The milestone (or assignee) change is the signal; do not narrate it with comments.里程碑/负责人的变动本身就是信号不要用评论去复述。对善意贡献者而言多余的已移到 v0.8.61之类评论只是噪音。五步工作流技能把整个操作固化为 5 步环环相扣任何一步都不允许跳过。第一步先确认准确的里程碑标题gh issue edit --milestone是按标题字符串匹配里程碑的而不是按编号。因此标题一旦拼错命令要么静默失败要么更糟——变成无效空操作。先读取真实标题并记录起始 open 计数用于第四步的复核基线gh api repos/Hmbown/CodeWhale/milestones \ --jq .[] | \(.number)\t\(.title)\topen\(.open_issues)\tstate\(.state)操作要点逐字复制标题字符串例如v0.8.61不要凭记忆手打若目标里程碑不存在或已关闭closed立即停下并向维护者询问绝不能自行新建。这条先读标题的纪律与 docs/RELEASE_CHECKLIST.md 中冻结发布源阶段的做法一致发布前的核对依赖gh issue list --repo Hmbown/CodeWhale --milestone vX.Y.Z --state open来判断该里程碑是否还残留本版本要收的工作标题一旦失真整个发布冻结判断都会失真。第二步预检每个编号gh issue edit不会拒绝 PR也不会拒绝已关闭 issue——它会把它们也乐呵呵地重定向过去。因此在编辑前必须先做一次体检。判断依据是url字段PR 的 URL 含/pull/issue 的 URL 含/issues/。凡是非 OPEN 状态或实为 PR的条目都要剔除for N in 3101 3102 3103; do gh issue view $N --repo Hmbown/CodeWhale \ --json number,state,url,milestone \ --jq \(.number)\t\(.state)\t\(.url)\tmilestone\(.milestone.title // none) done判读规则某行的url包含/pull/→ 它是 PR排除某行的state不是OPEN→排除其余条目方可进入下一步的编辑循环。这条纪律与姊妹技能完全同源gh-compile-issues 同样要求从编号解析、绝不信任标题行gh-close-issues 则强调把 issue/PR 文本当作不可信数据以代码树为准——在本技能中则体现为以 URL 与 state 字段为准。第三步逐个应用变更并上报结果一次改一条逐条报告成败。使用--milestone、--add-assignee或两者并用for N in 3101 3102 3103; do if gh issue edit $N --repo Hmbown/CodeWhale \ --milestone v0.8.61 /dev/null 21; then echo ok #$N - v0.8.61 else echo FAIL #$N (PR? closed? bad milestone title?) fi done # owners: add --add-assignee handle (do not invent logins)两个要点指派负责人时使用--add-assignee handle且不得虚构登录名——拼错的登录名会在循环中途报错破坏整批操作编辑是幂等的把一条已经指向正确里程碑的 issue 再指一次是无害的不会产生副作用。这正是可以放心逐条批量重放的前提。第四步复核里程碑确实移动了这是不可跳过的一步。重新执行第一步的命令确认 open 计数上升的数量等于你成功移入的 issue 数减去被跳过的条目。随后用第二步的view抽查若干条确认milestone.title已变成目标。文档特别警告Dont skip step 4. An unmoved open-count means the title was wrong or every edit silently failed.open 计数纹丝不动几乎可以断定是标题拼错或全部编辑静默失败。这一以计数佐证变更的思路与仓库对测试证据的要求一致——AGENTS.md 反复强调要引用真实的证据行、不能只看命令退出码此处即以里程碑 open 计数的净变化量作为批量迁移是否生效的硬证据。第五步输出紧凑台账最终输出一份精炼台账包含已移动的 issue被跳过及原因PR / 已关闭 / 标题不匹配迁移前后 open 计数before/after负责人指派情况如有。不发布任何公开评论。里程碑变动即是全部对外信号。红线清单什么不能做技能文档在 Red flags / dont 中列出了一组硬性约束适合直接固化为自动化代理的行为护栏不能只凭标题清单开干。先把标题解析成 OPEN 的 issue 编号并确认每条都是 issue 而非 PRURL 中无/pull/然后才允许编辑不能猜测里程碑标题或负责人登录名。近似的名字会空操作或静默失败无效的登录名会在循环中途报错不要发已移到 v0.8.61这类评论。里程碑变动本身就是信号多余评论是对善意贡献者的噪音不要顺带关闭、合并、打标签、打 tag 或发布。这些都需要维护者显式批准见 AGENTS.md 与 docs/skills/README.md不能跳过第四步复核。open 计数未移动 标题错误或所有编辑静默失败保留贡献者署名。本技能绝不篡改作者身份不收割Co-authored-by/Harvested-from尾注也不触碰任何关闭性引用。其中最后一条呼应了仓库的整体署名伦理正如 AGENTS.md 与 gh-find-prs 所强调的任何落地到仓库的社区工作都必须携带原作者的Co-authored-by与Harvested-from: PR #N by handle尾注本技能虽只改里程碑与负责人同样不得在这些元数据上做任何手脚。实战编排从分诊矩阵到排期队列把本技能放回 Codewhale 的发布工作流中它通常是链条的最后一环用 gh-compile-issues 把里程碑内 80 条 issue 分成 coverage 矩阵该技能甚至允许 ~10-12 条一批并行派出只读子代理扇出分诊维护者审阅矩阵决定哪些进入当前版本、指派给谁、哪些 defer 到后续里程碑用gh-assign-issues把决策落回 GitHub 队列——把本版本要收的 issue 移入v0.8.61把后续工作重定向到下一个里程碑最后对照 docs/RELEASE_CHECKLIST.md 第 0 步用gh issue list --repo Hmbown/CodeWhale --milestone vX.Y.Z --state open确认当前里程碑已无残留工作才允许冻结发布源。如此编排下本技能既不会越权发布也不会污染 GitHub 公开讨论区还能让队列状态这一事实来源始终保持干净、可审计。整条链路中的所有 GitHub 交互都只经由ghCLI命令可复现、输出可留痕——这正是它适合作为 Agent 技能与团队 Runbook 的原因。【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考