GitHub Issues 管理器

解决什么问题

Issue 的创建、分类和流转往往散落在浏览器、终端脚本和手动沟通之间。重复执行 gh issue create、反复粘贴模板、忘记补 label 或 assignee，都会让 triage 变成低价值的机械劳动。这个技能把这套操作收敛成一条可复用的命令行流程，让 Agent 在统一的上下文里完成议题的初始处理。

核心能力

技能围绕 Issue 的生命周期提供四类能力：

• 创建：按仓库和标题/正文参数创建 Issue，便于批量录入缺陷与需求。
• 分类：对已有 Issue 进行 triage，判断优先级与处理路径。
• 打标签：通过 label 把 Issue 归入对应分类，例如 bug、enhancement 或团队自定义标签。
• 指派：设置 assignee，把任务交到具体负责人手上。

它同时提供两条执行路径：优先走 gh CLI，适合已经登录并配置好认证的环境；在缺少 CLI 或需要脚本化调用时，可退回 REST API。这种双通道设计让技能既能在交互式终端里直接使用，也能嵌入更大的自动化流程。

关键步骤

一次典型的 triage 流程通常是：

1. 确认目标仓库，必要时通过 gh repo view 验证上下文。
2. 创建 Issue 或检索待处理的 Issue。
3. 根据内容补充标题、正文和标签。
4. 设置指派人，必要时更新优先级说明。

整个过程不改变 Git 仓库本身的状态，也不触碰分支与提交，只作用于 Issue 元数据。

适用边界

需要注意几点：

• 认证是前提。gh 路径依赖已登录的 CLI，REST 路径需要具备仓库权限的 token。
• Issue 的标签必须存在于目标仓库中，不存在的标签需要先由仓库侧创建。
• 指派仅对仓库成员或已关联账号生效，跨组织指派要确认账号可见性。
• 技能聚焦 Issue 管理，不覆盖 PR 流程；分支、评审与合并建议交给对应的 github-pr-workflow。
• 在共享环境中使用时，应避免把含敏感信息的正文写入日志或历史记录。

适合的场景是把重复、规则明确的 Issue 操作交给 Agent 执行，而不是替代负责人做出业务判断。