当需要端到端解决或继续 GitHub issue（如…

把 GitHub issue 从研究、实现到准备 PR 的完整流程标准化，适用于用户要求解决、修复、实现或继续某个 issue。

适用场景

解决思路

1. 先询问是否使用专用的 git worktree，这是所有工作流问题中的第一个问题；若选择是，则创建或使用该 worktree 并在其中继续。
2. 确认 issue 上下文与成功标准：读取一次 issue 正文、标签和关联讨论，之后复用该上下文而不要重复获取；复述可实现范围并明确列出范围外事项。
3. 确认 issue 关闭工作的 assignee 意图：检查当前用户是否被指派到主 issue；若未指派，询问是否要在继续前自我指派；对每个将被本工作流解决或关闭的子 issue，只检查一次 assignee 状态并复用于关闭决策；若当前用户未被子 issue 指派，询问是否要在解决/关闭前自我指派。
4. 采用低 token 的 GitHub 策略：当存在等价工具时优先使用 MCP 工具而非临时 `gh api` 或 GraphQL 调用；避免对标签、issue 类型和重复检测的重复查询；缓存每次运行的上下文（issue 元数据、重复匹配、issue 类型支持、标签集、assignee 候选）并复用，不要重新获取本会话已检索的数据；当委派给 `fusion-issue-authoring` 或其下级技能时，编排器的会话缓存规则适用：标签和 assignee 候选每个仓库获取一次，issue 类型每个组织获取一次；仅在 MCP 覆盖不可用时使用 GraphQL 回退，且不要循环重试；GraphQL mutation 每次消耗 5 个二级限制点（查询为 1），将字段批量合并到单次调用中，并在 mutation 调用之间至少暂停 1 秒；预算意识：典型实现会话（读取 issue + 重复检查 + 1–2 次 mutation + 子 issue 链接）应保持在约 20 次 MCP 读取调用和约 5 次 mutation 以内，若累计接近 30+ 次调用，暂停可选增强并继续本地工作；遵守 `retry-after` 和 `x-ratelimit-reset` 头，不要在指示等待时间前重试；若触发速率限制，停止非必要操作并在可能时继续本地实现/PR 准备。
5. 构建并跟踪具体计划：按依赖顺序创建可执行的 todo；始终保持恰好一个步骤处于进行中，并在工作完成时更新状态。
6. 编辑前先研究：检查相关文件、测试和相邻用法；优先根因修复而非表面补丁。
7. 以小范围变更实现：每个变更都与 issue 验收标准对齐；避免无关重构和生成的发布产物。
8. 增量验证：先运行针对性检查，再运行必需的项目检查；若检查失败，修复相关问题并在继续前重新运行。
9. 准备 PR 就绪的输出：总结改了什么及为什么；包含验证证据和已知后续事项；将 PR 正文草稿写入 `.tmp/` 下带 issue/上下文特定名称的文件（例如 `.tmp/pr-body-issue-123-scope-summary.md`），而非共享的 `.tmp/pr-body.md`；草稿基于 `.github/pull_request_template.md` 并随实现演进保持更新；询问目标 base 分支并提出可能的默认值（通常是 `main`，或当前分支切出的分支）；询问 PR 应以 draft 还是 ready for review 打开；询问 PR 是否应指派给用户以及是否应链接相关 issue。
10. 可选的 GitHub mutation 步骤：在任何 GitHub mutation（创建/编辑/评论/关闭）之前，请求用户明确确认；若被要求，用客观进展更新 issue 状态/评论；当存在等价操作时优先使用 MCP 工具 mutation 而非临时 API 调用；若 GitHub API 速率限制阻止 mutation，清晰报告失败，停止重试循环，并提出安全的重新尝试顺序；若被要求，使用仓库 PR 模板和 `.tmp/` PR 正文草稿文件创建或更新 PR，使用已确认的 base 分支、draft/ready 状态、assignee 选择和关联 issue 链接。

适用边界 · 注意事项

• 请求仅为 issue 起草/撰写
• 不期望有实现变更
• 不允许仓库写操作