fusion-issue-solving

问题解决工作流

适用场景

当用户希望端到端地解决或继续处理 GitHub 问题时使用，包括简短的当前仓库请求（如 solve #123）、直接的 GitHub 问题 URL，或类似 lets work on https://github.com/owner/repo/issues/123 的请求。

典型触发语句：

• “我们来解决 #123”
• “解决 #123”
• “处理 #123”
• “我们来处理 https://github.com/owner/repo/issues/123”
• “https://github.com/owner/repo/issues/123”
• “继续处理问题 #123”
• “端到端实现问题 #123”
• “处理这个工单：[问题 URL]”
• “研究、实现并为这个问题准备 PR”

对于 solve、fix、implement、continue、finish 或 work on 等动词，将 GitHub 问题 URL 视为与 #123 引用等效。如果没有其他相冲突的意图，直接的 GitHub 问题 URL 可以作为主要请求内容。

不适用场景

• 请求仅涉及起草或撰写问题
• 预期不需要修改实现
• 不允许对仓库进行写入操作

必需输入

执行前收集：

• 问题 URL 或 owner/repo#number
• 仓库以及分支／工作树决策
• 验收标准和范围外约束
• 目标仓库所需的验证命令

可选：

• 相关问题／PR
• 需要优先关注的风险领域
• 期望的提交／PR 粒度

说明

1. 询问是否使用专用的 git worktree

   • 在询问其他工作流问题之前先询问此项。
   • 如果用户同意，则使用或创建工作树，并在其中继续。

2. 确认问题背景和成功标准

   • 阅读问题正文、标签和关联讨论一次，然后复用该背景，避免重复获取。
   • 重述可实现的范围，并明确列出范围外的项目。

3. 确认关闭问题相关工作的负责人意向

   • 检查当前用户是否已被指派处理主要问题。
   • 如果当前用户未被指派，继续之前询问其是否要将自己指派为负责人。
   • 对于此工作流将解决或关闭的每个子问题，检查一次负责人状态，并在关闭决策中复用结果。
   • 如果当前用户未被指派处理某个子问题，在解决或关闭它之前询问其是否要将自己指派为负责人。

4. 采用节省 Token 的 GitHub 策略

   • 存在等效工具时，优先使用由 MCP 支持的工具，而非临时调用 gh api 或 GraphQL。
   • 避免重复查询标签、问题类型和重复问题检测结果。
   • 缓存每次运行的上下文（问题元数据、重复匹配结果、问题类型支持情况、标签集、负责人候选），并复用；不要重新获取本次会话中已获取的数据。
   • 委派给 fusion-issue-authoring 或其下级技能时，编排器的会话缓存规则仍适用：每个仓库只获取一次标签和负责人候选，每个组织只获取一次问题类型。
   • 仅在 MCP 覆盖不可用时使用 GraphQL 作为后备方案，且不要循环重试。
   • 每次 GraphQL 变更操作消耗 5 个次级限流点（查询则为 1 个）；将多个字段合并到单次调用中，并在每次变更调用之间至少等待 1 秒。
   • 关注预算：典型的实现会话（读取问题 + 检查重复项 + 1–2 次变更操作 + 子问题链接）应控制在约 20 次 MCP 读取调用和 5 次变更操作以内。如果累计调用接近 30 次或更多，暂停可选的补充调查，继续本地实现／PR 准备工作。
   • 遵守 retry-after 和 x-ratelimit-reset 标头；不得在指定等待时间之前重试。
   • 如果触发限流，停止非必要操作，并尽可能继续本地实现／PR 准备工作。

5. 制定并跟踪具体计划

   • 按依赖顺序创建可执行的待办事项。
   • 始终只将一个步骤设为进行中，并在工作完成后更新状态。

6. 编辑前先研究

   • 检查相关文件、测试和相邻用法。
   • 优先修复根因，而非进行表面修补。

7. 以小范围变更的方式实施

   • 确保每项变更都符合 issue 的验收标准。
   • 避免无关的重构和生成的发布产物。

8. 逐步验证

   • 先运行有针对性的检查，再运行项目要求的检查。
   • 如果检查失败，修复相关问题并重新运行，然后再继续。

9. 准备好可提交 PR 的内容

   • 总结变更内容及原因。
   • 提供验证依据和已知的后续事项。
   • 根据 issue 或上下文，为 PR 正文草稿创建一个名称具体的 .tmp/ 文件（例如 .tmp/pr-body-issue-123-scope-summary.md），不要使用共享文件 .tmp/pr-body.md。
   • 以 .github/pull_request_template.md 为基础撰写草稿，并随着实施进展持续更新。
   • 询问要以哪个分支为目标，并提出一个可能的默认分支（通常是 main，或当前分支的来源分支）。
   • 询问 PR 应以草稿状态还是可供审查的状态打开。
   • 询问是否应将 PR 指派给用户，以及是否应关联相关 issue。

10. 可选的 GitHub 变更操作

• 执行任何 GitHub 变更操作（创建／编辑／评论／关闭）前，先征求用户明确确认。
• 如果用户提出要求，使用客观的进展信息更新 issue 状态或评论。
• 如果存在等效操作，优先使用 MCP 工具进行变更，而不是临时调用 API。
• 如果 GitHub API 速率限制阻止了变更操作，应清楚说明失败情况，停止反复重试，并提出安全的重试方案。
• 如果用户提出要求，根据仓库 PR 模板和 .tmp/ 中的 PR 正文草稿创建或更新 PR，并使用已确认的目标分支、草稿／可供审查状态、指派选择和相关 issue 链接。

预期输出

返回简洁的交付报告，包括：

• 相对于原始 issue 验收标准已实施的范围，
• 已更改的文件，
• 验证命令及结果，
• 主要 issue 和受影响子 issue 的指派决定，
• 使用的 API 策略（MCP 优先／缓存复用／回退方案），
• 未解决的风险／阻碍，
• PR 正文摘要（或已创建的 .tmp/ 草稿文件路径）。

资源

• assets/issue-solving-checklist.md

安全与约束

• 此技能支持变更操作。如果仓库本地工作流说明与内联指南冲突，应以仓库说明为准。
• 切勿索取或泄露机密／凭据。
• 未经明确确认，切勿运行破坏性命令。
• 将变更限制在 issue 所需的最小范围内。
• 未实际运行检查时，切勿声称检查已通过。
• 遵循仓库说明和贡献规则。