address-github-issue

获取 GitHub 问题并协调团队处理。

用法：

• /address-github-issue 42 — 处理当前仓库中的问题 #42
• /address-github-issue owner/repo#42 — 处理指定仓库中的问题 #42
• /address-github-issue https://github.com/owner/repo/issues/42 — 按 URL 处理问题

说明：

1. 验证 gh CLI 是否可用：

   • 运行 gh --version 确认已安装
   • 如果找不到，停止并显示：

     ❌ GitHub CLI (`gh`) 未安装。
     使用以下命令安装：brew install gh
     然后使用以下命令进行身份验证：gh auth login
     

   • 运行 gh auth status 确认已完成身份验证
   • 如果未完成身份验证，停止并显示：

     ❌ GitHub CLI 未完成身份验证。
     运行：gh auth login
     

2. 从 $ARGUMENTS 解析问题引用：

   • 如果 $ARGUMENTS 为空，使用 AskUserQuestion 询问问题引用，并在收到回复前停止。
   • 支持的格式：
     • 纯数字（例如 42）→ 使用当前仓库
     • owner/repo#42 → 指定仓库和编号
     • 完整 GitHub URL（例如 https://github.com/owner/repo/issues/42）→ 从中解析仓库和编号
   • 对于纯数字，使用 gh repo view --json nameWithOwner -q .nameWithOwner 确定当前仓库。如果失败（不在 GitHub 仓库中），停止：

     ❌ 无法确定 GitHub 仓库。
     请在 GitHub 仓库内运行此技能，或提供完整的问题引用（例如 owner/repo#42）。
     

3. 获取问题：

   • 运行：

     gh issue view <number> --repo <owner/repo> --json number,title,body,labels,assignees,milestone,state,comments,url
     

   • 如果找不到问题或访问被拒绝，则使用 gh 返回的错误消息停止。
   • 解析 JSON 输出并提取：
     • title、body、labels、state、url
     • comments 数组（每条评论都包含 author.login 和 body）

4. 分析问题：

   • 仔细阅读标题、正文和所有评论。
   • 确定问题类型：
     • Bug — 功能异常；标签可能包括 bug、defect、regression
     • 功能 — 新增能力；标签可能包括 enhancement、feature request
     • 杂项 / 维护 — 技术债务、重构、CI、文档；标签可能包括 chore、docs、refactor
     • 问题 / 调研 — 编码前需要先进行调研
   • 确定范围和复杂度：
     • 简单（1 名开发者）— 独立修复或小型新增，涉及 ≤2 个文件，不更改 API 或架构
     • 中等（2 名开发者）— 涉及多个环节的中等规模功能或 Bug；可能分别涉及前端和后端
     • 复杂（3 名开发者）— 大型功能、架构变更、横向影响的问题，或包含多个独立工作流
   • 记录任何歧义或信息缺失，以便 PM 在需求中澄清。

5. 确定团队组成：

   • 始终恰好启动 1 名 PM。
   • 根据上述复杂度评估，启动 1、2 或 3 名开发者。
   • 此技能不启动设计师或测试人员（预期开发者会在实现中包含测试）。

6. 创建团队：

   • 使用 TeamCreate 创建团队，名称应根据问题标题或编号简短命名，并采用 kebab-case 格式（例如 issue-42、fix-login-crash、add-dark-mode）。
   • 在启动 Agent 前，使用 TaskCreate 为每个角色创建一个任务：
     • PM 任务：“为问题 # 编写需求和验收标准”
     • 每位开发者的任务：“为问题 # 实现 ”

7. 启动 PM（subagent_type: general-purpose）：

   • 提供：
     • 完整的问题内容（标题、正文、所有评论、URL）
     • 问题类型和复杂度评估
     • 团队名称
   • PM 的工作：
     • 全面阅读问题，包括所有评论
     • 编写详细的需求和验收标准，以解决该问题；结合评论和对代码库的了解，消除任何歧义
     • 按以下结构组织需求：

       ## Issue #<number>: <title>
       **Type:** <Bug / Feature / Chore> | **URL:** <url>
       
       ## Context
       <简要概述问题及其重要性>
       
       ## Requirements
       <具体、可测试的编号需求列表>
       
       ## Acceptance Criteria
       <问题解决后必须满足的条件清单>
       
       ## Developer Workstreams
       <如果有多位开发者：清楚描述每个工作流的范围，以及他们需要商定的共享接口或约定>
       
       ## Out of Scope
       <明确排除在此问题范围之外的事项>
       

     • 检查项目知识文件（LORE.md、docs/lore.md、.agent/lore.md 或类似文件），并更新其中与此问题相关的背景信息
     • 通过 TaskUpdate 将任务标记为已完成
     • 完成后通知团队负责人

8. 等待 PM 完成，并从已完成的任务或 PM 消息中获取需求。

9. 启动开发者（subagent_type: general-purpose），针对每个工作流并行启动一位：

   • 向每位开发者提供：
     • 原始问题内容（标题、正文、评论、URL）
     • PM 的需求文档
     • 其负责的具体工作流范围（如果有多位开发者）
     • 问题类型作为背景信息（修复 Bug → 编写回归测试；功能 → 编写单元/集成测试等）
   • 每位开发者的工作：
     • 探索代码库中的相关部分
     • 实现其工作流所需的更改
     • 编写覆盖其更改的测试（至少编写单元测试；适用时编写集成测试）
     • 通过 TaskUpdate 将任务标记为已完成
     • 完成后通知团队负责人

10. 等待所有开发者 完成。

11. 确认不存在冲突：

    • 如果启动了多位开发者，检查是否有两位开发者修改了同一文件
    • 如果存在冲突，阅读双方的更改并进行合理合并
    • 快速进行健全性检查：确保所有更改应用后，代码库可以成功编译且通过 lint 检查（如果项目提供现有的 lint/build 脚本，则使用这些脚本）

12. 向用户提供最终摘要：

    ## 已解决 Issue #<number>
    
    **问题：** <title>
    **URL：** <url>
    
    ### 完成内容
    - <更改内容的项目符号摘要>
    
    ### 新增测试
    - <新增或更新的测试文件列表>
    
    ### 开发者
    - <Developer 1>：<其实现的内容>
    - <Developer 2>：<其实现的内容>（如适用）
    
    ### 建议的后续步骤
    - 使用 `/review-changes` 审查更改
    - 使用 `/create-pr` 创建 PR
    - 在 GitHub 上将 PR 关联到该问题：`gh issue develop <number> --repo <owner/repo>`
    

13. 有序关闭团队：

    • 通过 SendMessage 向每位队友发送 shutdown_request
    • 所有人确认后，调用 TeamDelete