拓冰网站定制 
人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载导读本文以 gsd-2 仓库中内置的 GitHub 标签管理技能文档src/resources/skills/github-workflows/references/gh/references/labels.md为骨架系统讲解一套可复用的 Issue 标签分类法priority / type / status 三轴以及覆盖 CLI、Python 脚本、JavaScript Hook 三种场景的完整操作方案。读完本文你将掌握如何用gh label快速管理单个标签、如何用 PyGithub 编写多步自动化脚本、如何在 Claude Code Hook 中用octokit/rest处理标签以及如何用仓库自带的github_project_setup.py一键批量初始化整套标签体系并结合源码与测试用例理解其底层实现。一、工具选型什么时候用哪种方式原文档给出了一个非常务实的选型判断标准核心原则是“按场景选工具而不是一律用gh”场景推荐工具快速一次性命令gh labelCLI脚本化 / 多步骤操作PyGithubPython或octokit/restJavaScriptClaude Code Hookoctokit/rest或 Node.js 内置https模块其中两条红线值得强调Python 脚本中永远不要 shell 出去调用gh统一使用PyGithubgithub包.cjsHook 文件中永远不要用child_process调gh统一使用octokit/rest。这一设计在 gsd-2 的 gh 技能入口 SKILL.md 中有明确呼应该技能描述指出在 AI Agent 环境中gh可能未预装、且 git remote 指向本地代理而非github.com因此凡是需要认证访问 GitHub API 的操作都依赖GITHUB_TOKEN并通过-R显式指定仓库。这也解释了为什么下面的命令示例全部带-R OWNER/REPO——在代理环境下缺少-R会直接报failed to determine base repo。二、标准标签分类法Taxonomy所有标签围绕三个轴展开priority优先级、type类型、status状态。标签命名统一采用轴:值的小写冒号格式便于脚本过滤与排序。2.1 优先级标签Priority标签颜色含义priority:p0#D73A4A关键——阻塞工作或生产priority:p1#E99695高——下一步就应该做priority:p2#F9D0C4中——P0/P1 清空后再做priority:idea#BFD4F2未排期——未来考虑2.2 类型标签Type标签颜色含义type:feature#0E8A16新能力或新技能type:bug#B60205某处损坏type:refactor#5319E7内部改进无行为变化type:docs#0075CA仅文档type:chore#EDEDED维护、工具链、CI2.3 状态标签Status状态标签完整对应 backlog 状态机的 8 个生命周期状态原文档引用.claude/skills/backlog/references/state-machine.md在 gsd-2 中该技能体系落位于 gh 技能目录 下同一目录还提供了 issue-stories.md、milestones.md 与 projects-v2.md 作为配套参考标签颜色含义status:needs-grooming#FEF2C0已捕获但尚未梳理groomingstatus:groomed#C2E0C6梳理完成RT-ICA APPROVEDstatus:blocked#B60205RT-ICA BLOCKED 或 AC 验证 FAILstatus:in-milestone#BFD4F2已分配到活跃里程碑status:in-progress#1D76DB正在实施status:done#0E8A16实施完成AC 验证 PASSstatus:resolved#6B737B未完整实施即关闭废弃/被取代status:closed#EDEDED终态——里程碑归档兼容性提示status:needs-review曾存在于旧分类法中但它不属于状态机生命周期的一部分。它被保留在github_project_setup.py中仅出于向后兼容目的颜色#D876E3backlog 命令不应再应用该标签。在源码 github_project_setup.py 中这 17 个标签4 优先级 5 类型 8 状态 1 兼容保留以LABELS常量列表硬编码作为批量初始化的事实标准同时脚本里还维护了两张映射表PRIORITY_LABEL_MAP {P0: priority:p0, P1: priority:p1, P2: priority:p2, IDEAS: priority:idea}用于把 backlog 条目的优先级换算成 Issue 标签_LABEL_TO_PROJECT_STATUS把status:*标签映射到 Projects V2 的看板状态如status:in-progress → In Progress、status:done → Done打通“标签”与“看板”两套视图。三、gh CLI 快速命令适合人机交互或一次性操作。所有命令都必须带-R OWNER/REPO指定仓库# 列出所有标签 gh label list -R Jamie-BitFlight/claude_skills # 创建标签 gh label create priority:p1 \ --color E99695 \ --description High priority — should be done next \ -R Jamie-BitFlight/claude_skills # 编辑标签 gh label edit priority:p1 \ --description High priority — updated \ -R Jamie-BitFlight/claude_skills # 给 Issue 应用/移除标签 gh issue edit 42 -R Jamie-BitFlight/claude_skills \ --add-label status:in-progress \ --remove-label status:needs-grooming注意gh label create的--color参数与文档表格中的色值写法一致如E99695不带#前缀。这与 PyGithub 的create_label(color...)保持同样的格式约定源码中LABELS常量里的颜色字段同样不含#。四、PyGithub 脚本化操作Python适合 CI、定时任务、批量导入等多步骤场景。脚本使用 uv 内联依赖声明无需手工创建虚拟环境认证统一读取环境变量GITHUB_TOKEN#!/usr/bin/env -S uv run --quiet --script # /// script # requires-python 3.11 # dependencies [PyGithub2.1.1] # /// from __future__ import annotations import os from github import Auth, Github gh Github(authAuth.Token(os.environ[GITHUB_TOKEN])) repo gh.get_repo(Jamie-BitFlight/claude_skills) # 创建标签 repo.create_label(namepriority:p1, colorE99695, descriptionHigh priority) # 编辑已有标签 label repo.get_label(priority:p1) label.edit(namepriority:p1, colorE99695, descriptionUpdated description) # 给 Issue 应用/移除标签 issue repo.get_issue(42) issue.add_to_labels(repo.get_label(status:in-progress)) issue.remove_from_labels(repo.get_label(status:needs-grooming))github_project_setup.py正是这套模式的规模化落地其labels子命令遍历LABELS常量先repository.get_labels()拉取仓库现有标签构建existing字典对不存在的标签调用repository.create_label(...)对已存在的标签默认跳过exists:提示仅当传入--force时才调用label.edit(...)强制刷新名称、颜色与描述最后输出Labels: N created, N updated, N skipped汇总。认证函数get_github()在缺少GITHUB_TOKEN时直接报错并以退出码 1 结束。配套测试 test_github_project_setup.py 用 TyperCliRunnerunittest.mock全程无网络验证了四个关键行为缺失标签被创建、已有标签默认跳过、--force触发edit、缺 token 时退出码为 1——这为标签初始化脚本的正确性提供了可复现的保障。五、octokit/rest — Claude Code HooksJavaScript适用于 Claude Code 的.cjs事件 Hook。同样读取process.env.GITHUB_TOKEN认证绝不通过child_process调gh// In a Claude Code hook (.cjs) const { Octokit } require(octokit/rest); const octokit new Octokit({ auth: process.env.GITHUB_TOKEN }); // 给 Issue 应用标签 await octokit.rest.issues.addLabels({ owner: Jamie-BitFlight, repo: claude_skills, issue_number: 42, labels: [status:in-progress], }); // 移除标签 await octokit.rest.issues.removeLabel({ owner: Jamie-BitFlight, repo: claude_skills, issue_number: 42, name: status:needs-grooming, });配套的 issue-stories.md 还展示了用octokit.rest.issues.create一次性携带labels数组创建 Issue 的写法可见在 Hook 场景下标签操作天然与 Issue 生命周期创建 → 打标 → 关单绑定。六、批量标签初始化Bulk Label Setup仓库自带的自动化脚本可以一次性把整套分类法铺到目标仓库且天然幂等# 创建所有分类标签已存在的跳过 uv run src/resources/skills/github-workflows/references/gh/scripts/github_project_setup.py labels \ --repo Jamie-BitFlight/claude_skills # 强制更新已有标签颜色、描述以脚本为准 uv run src/resources/skills/github-workflows/references/gh/scripts/github_project_setup.py labels \ --repo Jamie-BitFlight/claude_skills --force路径说明原文档中的.claude/skills/gh/scripts/github_project_setup.py在当前 gsd-2 仓库中的对应路径为src/resources/skills/github-workflows/references/gh/scripts/github_project_setup.py请按此路径执行。脚本本身基于 Typer 构建除labels外还提供setup、milestone create/list/start/close、issue create/list、project update-status等子命令用法见脚本顶部 docstring。其中与标签体系联动最紧密的是里程碑转换逻辑milestone start --number N把里程碑内 open Issue 上的status:needs-grooming批量替换为status:in-progress_transition_issues实现若标签缺失则由_ensure_label即时创建milestone close --number N把 open Issue 统一转为status:done_transition_to_done实现会剔除status:in-progress与status:needs-grooming再关闭里程碑。这两条命令都支持--dry-run预演且测试覆盖了“已处于 in-progress 的 Issue 被跳过”“仅移除 status 标签、保留priority:p1/type:feature等非状态标签”“单个 Issue 失败不中断其余处理并最终以退出码 1 收尾”等关键边界见 test_github_project_setup.py。七、Backlog 条目优先级 → Issue 标签映射当 backlog 条目的 frontmatter 中声明了优先级时按如下规则映射为标签与PRIORITY_LABEL_MAP一致每条目文件中的优先级Issue 标签P0priority:p0P1priority:p1P2priority:p2Ideaspriority:ideaissue create子命令会自动为新建 Issue 打上status:needs-grooming作为生命周期起点并可选追加--priority-label、--type-label与--milestoneissue list --priority p1则按优先级标签过滤。这些语义与 issue-stories.md 的“Backlog 条目 ↔ GitHub Issue 字段映射”一一对应metadata.priority → priority:*标签、metadata.status → status:*标签。八、实践要点与验证闭环标签是元数据不是分类gh 技能入口 SKILL.md 明确提醒不要用标签做 bug/feature 等类型分类分类应使用 GitHub Issue TypesGraphQL 设置标签只承载 priority、status、auto-generated 等元数据。幂等优先labels命令默认跳过已存在标签重复执行安全需要更新时显式加--force。状态标签唯一性同一 Issue 在任一时刻应只有一个status:*标签如needs-grooming → in-progress → done源码中的_transition_*函数正是围绕“移除旧状态、追加新状态”实现。测试驱动所有命令行为都有离线单测锚定src/resources/skills/github-workflows/references/gh/tests/test_github_project_setup.py可放心修改扩展后回归验证。这套“文档定义分类法、脚本执行初始化、测试锁定行为”的三层结构正是 gsd-2 面向长期自主运行的 Agent 管理 Issue 元数据的可复制范式。赞分享人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐GSD-2 规范分诊标签体系从 triage 角色到 GitHub issue 标签的落地实践GSD 2 规范分诊标签体系从 triage 角色到 GitHub issue 标签的落地实践 本文以 GSD 2 仓库的 docs/agents/triag人工智能AI Agent代码智能体Agent 编排CLIAI 应用React Native Portal源码解析从Context到状态管理的实现原理React Native Portal源码解析从Context到状态管理的实现原理 React Native Portal是一个简化版的Portal实现专为Kata Containers GitHub 标签归档全解析labeler 扫描旧标签体系与标签数据库自动化管理Kata Containers GitHub 标签归档全解析labeler 扫描旧标签体系与标签数据库自动化管理 导读 Kata Containers 项目横示例工程深度学习人工智能上一篇如何一次性安装所有Visual C运行库终极完整解决方案指南下一篇终极开源任务管理工具OpenTodoList完全使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 gsd-2 GitHub Labels 标签体系与自动化管理实战：从 gh CLI 到 PyGithub 与 Octokit Hook
人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载导读本文以 gsd-2 仓库中内置的 GitHub 标签管理技能文档src/resources/skills/github-workflows/references/gh/references/labels.md为骨架系统讲解一套可复用的 Issue 标签分类法priority / type / status 三轴以及覆盖 CLI、Python 脚本、JavaScript Hook 三种场景的完整操作方案。读完本文你将掌握如何用gh label快速管理单个标签、如何用 PyGithub 编写多步自动化脚本、如何在 Claude Code Hook 中用octokit/rest处理标签以及如何用仓库自带的github_project_setup.py一键批量初始化整套标签体系并结合源码与测试用例理解其底层实现。一、工具选型什么时候用哪种方式原文档给出了一个非常务实的选型判断标准核心原则是“按场景选工具而不是一律用gh”场景推荐工具快速一次性命令gh labelCLI脚本化 / 多步骤操作PyGithubPython或octokit/restJavaScriptClaude Code Hookoctokit/rest或 Node.js 内置https模块其中两条红线值得强调Python 脚本中永远不要 shell 出去调用gh统一使用PyGithubgithub包.cjsHook 文件中永远不要用child_process调gh统一使用octokit/rest。这一设计在 gsd-2 的 gh 技能入口 SKILL.md 中有明确呼应该技能描述指出在 AI Agent 环境中gh可能未预装、且 git remote 指向本地代理而非github.com因此凡是需要认证访问 GitHub API 的操作都依赖GITHUB_TOKEN并通过-R显式指定仓库。这也解释了为什么下面的命令示例全部带-R OWNER/REPO——在代理环境下缺少-R会直接报failed to determine base repo。二、标准标签分类法Taxonomy所有标签围绕三个轴展开priority优先级、type类型、status状态。标签命名统一采用轴:值的小写冒号格式便于脚本过滤与排序。2.1 优先级标签Priority标签颜色含义priority:p0#D73A4A关键——阻塞工作或生产priority:p1#E99695高——下一步就应该做priority:p2#F9D0C4中——P0/P1 清空后再做priority:idea#BFD4F2未排期——未来考虑2.2 类型标签Type标签颜色含义type:feature#0E8A16新能力或新技能type:bug#B60205某处损坏type:refactor#5319E7内部改进无行为变化type:docs#0075CA仅文档type:chore#EDEDED维护、工具链、CI2.3 状态标签Status状态标签完整对应 backlog 状态机的 8 个生命周期状态原文档引用.claude/skills/backlog/references/state-machine.md在 gsd-2 中该技能体系落位于 gh 技能目录 下同一目录还提供了 issue-stories.md、milestones.md 与 projects-v2.md 作为配套参考标签颜色含义status:needs-grooming#FEF2C0已捕获但尚未梳理groomingstatus:groomed#C2E0C6梳理完成RT-ICA APPROVEDstatus:blocked#B60205RT-ICA BLOCKED 或 AC 验证 FAILstatus:in-milestone#BFD4F2已分配到活跃里程碑status:in-progress#1D76DB正在实施status:done#0E8A16实施完成AC 验证 PASSstatus:resolved#6B737B未完整实施即关闭废弃/被取代status:closed#EDEDED终态——里程碑归档兼容性提示status:needs-review曾存在于旧分类法中但它不属于状态机生命周期的一部分。它被保留在github_project_setup.py中仅出于向后兼容目的颜色#D876E3backlog 命令不应再应用该标签。在源码 github_project_setup.py 中这 17 个标签4 优先级 5 类型 8 状态 1 兼容保留以LABELS常量列表硬编码作为批量初始化的事实标准同时脚本里还维护了两张映射表PRIORITY_LABEL_MAP {P0: priority:p0, P1: priority:p1, P2: priority:p2, IDEAS: priority:idea}用于把 backlog 条目的优先级换算成 Issue 标签_LABEL_TO_PROJECT_STATUS把status:*标签映射到 Projects V2 的看板状态如status:in-progress → In Progress、status:done → Done打通“标签”与“看板”两套视图。三、gh CLI 快速命令适合人机交互或一次性操作。所有命令都必须带-R OWNER/REPO指定仓库# 列出所有标签 gh label list -R Jamie-BitFlight/claude_skills # 创建标签 gh label create priority:p1 \ --color E99695 \ --description High priority — should be done next \ -R Jamie-BitFlight/claude_skills # 编辑标签 gh label edit priority:p1 \ --description High priority — updated \ -R Jamie-BitFlight/claude_skills # 给 Issue 应用/移除标签 gh issue edit 42 -R Jamie-BitFlight/claude_skills \ --add-label status:in-progress \ --remove-label status:needs-grooming注意gh label create的--color参数与文档表格中的色值写法一致如E99695不带#前缀。这与 PyGithub 的create_label(color...)保持同样的格式约定源码中LABELS常量里的颜色字段同样不含#。四、PyGithub 脚本化操作Python适合 CI、定时任务、批量导入等多步骤场景。脚本使用 uv 内联依赖声明无需手工创建虚拟环境认证统一读取环境变量GITHUB_TOKEN#!/usr/bin/env -S uv run --quiet --script # /// script # requires-python 3.11 # dependencies [PyGithub2.1.1] # /// from __future__ import annotations import os from github import Auth, Github gh Github(authAuth.Token(os.environ[GITHUB_TOKEN])) repo gh.get_repo(Jamie-BitFlight/claude_skills) # 创建标签 repo.create_label(namepriority:p1, colorE99695, descriptionHigh priority) # 编辑已有标签 label repo.get_label(priority:p1) label.edit(namepriority:p1, colorE99695, descriptionUpdated description) # 给 Issue 应用/移除标签 issue repo.get_issue(42) issue.add_to_labels(repo.get_label(status:in-progress)) issue.remove_from_labels(repo.get_label(status:needs-grooming))github_project_setup.py正是这套模式的规模化落地其labels子命令遍历LABELS常量先repository.get_labels()拉取仓库现有标签构建existing字典对不存在的标签调用repository.create_label(...)对已存在的标签默认跳过exists:提示仅当传入--force时才调用label.edit(...)强制刷新名称、颜色与描述最后输出Labels: N created, N updated, N skipped汇总。认证函数get_github()在缺少GITHUB_TOKEN时直接报错并以退出码 1 结束。配套测试 test_github_project_setup.py 用 TyperCliRunnerunittest.mock全程无网络验证了四个关键行为缺失标签被创建、已有标签默认跳过、--force触发edit、缺 token 时退出码为 1——这为标签初始化脚本的正确性提供了可复现的保障。五、octokit/rest — Claude Code HooksJavaScript适用于 Claude Code 的.cjs事件 Hook。同样读取process.env.GITHUB_TOKEN认证绝不通过child_process调gh// In a Claude Code hook (.cjs) const { Octokit } require(octokit/rest); const octokit new Octokit({ auth: process.env.GITHUB_TOKEN }); // 给 Issue 应用标签 await octokit.rest.issues.addLabels({ owner: Jamie-BitFlight, repo: claude_skills, issue_number: 42, labels: [status:in-progress], }); // 移除标签 await octokit.rest.issues.removeLabel({ owner: Jamie-BitFlight, repo: claude_skills, issue_number: 42, name: status:needs-grooming, });配套的 issue-stories.md 还展示了用octokit.rest.issues.create一次性携带labels数组创建 Issue 的写法可见在 Hook 场景下标签操作天然与 Issue 生命周期创建 → 打标 → 关单绑定。六、批量标签初始化Bulk Label Setup仓库自带的自动化脚本可以一次性把整套分类法铺到目标仓库且天然幂等# 创建所有分类标签已存在的跳过 uv run src/resources/skills/github-workflows/references/gh/scripts/github_project_setup.py labels \ --repo Jamie-BitFlight/claude_skills # 强制更新已有标签颜色、描述以脚本为准 uv run src/resources/skills/github-workflows/references/gh/scripts/github_project_setup.py labels \ --repo Jamie-BitFlight/claude_skills --force路径说明原文档中的.claude/skills/gh/scripts/github_project_setup.py在当前 gsd-2 仓库中的对应路径为src/resources/skills/github-workflows/references/gh/scripts/github_project_setup.py请按此路径执行。脚本本身基于 Typer 构建除labels外还提供setup、milestone create/list/start/close、issue create/list、project update-status等子命令用法见脚本顶部 docstring。其中与标签体系联动最紧密的是里程碑转换逻辑milestone start --number N把里程碑内 open Issue 上的status:needs-grooming批量替换为status:in-progress_transition_issues实现若标签缺失则由_ensure_label即时创建milestone close --number N把 open Issue 统一转为status:done_transition_to_done实现会剔除status:in-progress与status:needs-grooming再关闭里程碑。这两条命令都支持--dry-run预演且测试覆盖了“已处于 in-progress 的 Issue 被跳过”“仅移除 status 标签、保留priority:p1/type:feature等非状态标签”“单个 Issue 失败不中断其余处理并最终以退出码 1 收尾”等关键边界见 test_github_project_setup.py。七、Backlog 条目优先级 → Issue 标签映射当 backlog 条目的 frontmatter 中声明了优先级时按如下规则映射为标签与PRIORITY_LABEL_MAP一致每条目文件中的优先级Issue 标签P0priority:p0P1priority:p1P2priority:p2Ideaspriority:ideaissue create子命令会自动为新建 Issue 打上status:needs-grooming作为生命周期起点并可选追加--priority-label、--type-label与--milestoneissue list --priority p1则按优先级标签过滤。这些语义与 issue-stories.md 的“Backlog 条目 ↔ GitHub Issue 字段映射”一一对应metadata.priority → priority:*标签、metadata.status → status:*标签。八、实践要点与验证闭环标签是元数据不是分类gh 技能入口 SKILL.md 明确提醒不要用标签做 bug/feature 等类型分类分类应使用 GitHub Issue TypesGraphQL 设置标签只承载 priority、status、auto-generated 等元数据。幂等优先labels命令默认跳过已存在标签重复执行安全需要更新时显式加--force。状态标签唯一性同一 Issue 在任一时刻应只有一个status:*标签如needs-grooming → in-progress → done源码中的_transition_*函数正是围绕“移除旧状态、追加新状态”实现。测试驱动所有命令行为都有离线单测锚定src/resources/skills/github-workflows/references/gh/tests/test_github_project_setup.py可放心修改扩展后回归验证。这套“文档定义分类法、脚本执行初始化、测试锁定行为”的三层结构正是 gsd-2 面向长期自主运行的 Agent 管理 Issue 元数据的可复制范式。赞分享人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐GSD-2 规范分诊标签体系从 triage 角色到 GitHub issue 标签的落地实践GSD 2 规范分诊标签体系从 triage 角色到 GitHub issue 标签的落地实践 本文以 GSD 2 仓库的 docs/agents/triag人工智能AI Agent代码智能体Agent 编排CLIAI 应用React Native Portal源码解析从Context到状态管理的实现原理React Native Portal源码解析从Context到状态管理的实现原理 React Native Portal是一个简化版的Portal实现专为Kata Containers GitHub 标签归档全解析labeler 扫描旧标签体系与标签数据库自动化管理Kata Containers GitHub 标签归档全解析labeler 扫描旧标签体系与标签数据库自动化管理 导读 Kata Containers 项目横示例工程深度学习人工智能上一篇如何一次性安装所有Visual C运行库终极完整解决方案指南下一篇终极开源任务管理工具OpenTodoList完全使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考