Back to Details

fusion-issue-solving

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Issue Solving Workflow

GitHub Issue解决工作流

When to use

适用场景

Use this skill when the user wants to solve or continue a GitHub issue end-to-end, including short current-repo prompts like 
solve #123
, direct GitHub issue URLs, or requests like 
lets work on https://github.com/owner/repo/issues/123
.
Typical triggers:
Treat GitHub issue URLs as interchangeable with 
#123
references for verbs like 
solve
, 
fix
, 
implement
, 
continue
, 
finish
, or 
work on
. A direct GitHub issue URL can also serve as the main request payload for this workflow when no competing intent is stated.
当用户希望端到端解决或继续处理某个GitHub issue时，可使用此技能，支持的请求包括当前仓库内的简短指令（如
solve #123
）、GitHub issue的直接URL，或类似「lets work on https://github.com/owner/repo/issues/123」的请求。
典型触发指令：
对于
solve
「fix」「implement」「continue」「finish」「work on」等动词，GitHub issue URL与
#123
引用格式可互换使用。当没有其他冲突意图时，直接的GitHub issue URL也可作为此工作流的主要请求内容。

When not to use

不适用场景

Do not use this skill when:
  • the request is only issue drafting/authoring,
  • no implementation changes are expected,
  • repository write operations are disallowed.
请勿在以下场景使用此技能：
  • 仅需起草/撰写issue，
  • 无需进行任何代码实现变更，
  • 仓库禁止写入操作。

Required inputs

必要输入项

Collect before execution:
  • issue URL or 
    owner/repo#number
    ,
  • repository and branch/worktree decision,
  • acceptance criteria and out-of-scope constraints,
  • required validation commands for the target repository.
Optional inputs:
  • related issues/PRs,
  • risk areas to prioritize,
  • requested commit/PR granularity.
执行前需收集：
  • issue URL或
    owner/repo#number
    格式的标识，
  • 仓库及分支/工作树的选择，
  • 验收标准与范围外约束条件，
  • 目标仓库要求的验证命令。
可选输入项：
  • 相关issue/PR，
  • 需要优先关注的风险点，
  • 要求的提交/PR粒度。

Instructions

操作步骤

  1. Ask whether to use a dedicated git worktree
    • Ask this before any other workflow questions.
    • If yes, use/create the worktree and continue there.
  2. Confirm issue context and success criteria
    • Read the issue body, labels, and linked discussions once, then reuse that context instead of refetching.
    • Restate the implementable scope and explicitly list out-of-scope items.
  3. Confirm assignee intent for issue closure work
    • Check whether the current user is assigned to the primary issue.
    • If the current user is not assigned, ask whether they want to assign themselves before continuing.
    • For each sub-issue that will be resolved or closed by this workflow, check assignee status once and reuse the result for closure decisions.
    • If the current user is not assigned on a sub-issue, ask whether they want to assign themselves before resolving/closing it.
  4. Apply low-token GitHub strategy
    • Prefer MCP-backed tools over ad hoc 
      gh api
      or GraphQL calls when equivalent tools exist.
    • Avoid duplicate lookups for labels, issue types, and duplicate detection.
    • Cache per-run context (issue metadata, duplicate matches, issue-type support, label sets, assignee candidates) and reuse it — do not re-fetch data that was already retrieved in this session.
    • When delegating to 
      fusion-issue-authoring
      or its subordinate skills, the orchestrator's session-cache rules apply: labels and assignee candidates are fetched once per repository, issue types once per organization.
    • Use GraphQL fallback only when MCP coverage is unavailable and do not loop retries.
    • GraphQL mutations cost 5 secondary-limit points each (vs 1 for queries); batch fields into single calls and pause at least 1 second between mutation calls.
    • Budget awareness: a typical implementation session (read issue + duplicate check + 1–2 mutations + sub-issue links) should stay under ~20 MCP read calls and ~5 mutations. If the running total approaches 30+ calls, pause optional enrichment and proceed with local work.
    • Respect 
      retry-after
      and 
      x-ratelimit-reset
      headers; do not retry before the indicated wait.
    • If rate limits are hit, stop non-essential operations and continue with local implementation/PR preparation when possible.
  5. Build and track a concrete plan
    • Create actionable todos ordered by dependencies.
    • Keep exactly one step in progress and update status as work completes.
  6. Research before edits
    • Inspect relevant files, tests, and adjacent usage.
    • Prefer root-cause fixes over surface patches.
  7. Implement in small scoped changes
    • Keep each change aligned to issue acceptance criteria.
    • Avoid unrelated refactors and generated release artifacts.
  8. Validate incrementally
    • Run targeted checks first, then required project checks.
    • If checks fail, fix relevant issues and re-run before proceeding.
  9. Prepare PR-ready output
    • Summarize what changed and why.
    • Include validation evidence and known follow-ups.
    • Draft the PR body in a 
      .tmp/
      file with an issue/context-specific name (for example, 
      .tmp/pr-body-issue-123-scope-summary.md
      ), not a shared 
      .tmp/pr-body.md
      .
    • Base the draft on 
      .github/pull_request_template.md
      and keep it updated as implementation evolves.
    • Ask which base branch to target and propose a likely default (typically 
      main
      , or the branch the current branch was cut from).
    • Ask whether the PR should be opened as draft or ready for review.
    • Ask whether the PR should be assigned to the user and whether related issues should be linked.
  10. Optional GitHub mutation steps
  • Before any GitHub mutation (create/edit/comment/close), ask for explicit user confirmation.
  • If requested, update issue status/comments with objective progress.
  • Prefer MCP tool mutations over ad hoc API calls when equivalent operations exist.
  • If GitHub API rate limits block mutation, report the failure clearly, stop retry loops, and propose a safe retry sequence.
  • If requested, create or update the PR using the repository PR template and the 
    .tmp/
    PR body draft file, using the confirmed base branch, draft/ready state, assignee choice, and related issue links.
  1. 询问是否使用专用的git worktree
    • 此问题需在其他工作流问题之前提出。
    • 若用户同意，使用/创建该worktree并在其中继续后续操作。
  2. 确认issue上下文与成功标准
    • 读取一次issue正文、标签及关联讨论内容，之后复用该上下文信息，无需重复获取。
    • 重述可实施的范围，并明确列出不属于实施范围的内容。
  3. 确认用户对issue关闭工作的分配意向
    • 检查当前用户是否已被分配为主要issue的负责人。
    • 若当前用户未被分配，询问其是否希望在继续操作前将自己设为负责人。
    • 对于本工作流将解决或关闭的每个子issue，仅检查一次负责人状态，并将结果复用至关闭决策中。
    • 若当前用户未被分配为子issue的负责人，询问其是否希望在解决/关闭该子issue前将自己设为负责人。
  4. 应用低令牌消耗的GitHub策略
    • 当存在等效工具时，优先使用基于MCP的工具，而非临时的
      gh api
      或GraphQL调用。
    • 避免重复查询标签、issue类型及重复项检测信息。
    • 缓存单次运行的上下文信息（如issue元数据、重复匹配项、支持的issue类型、标签集、负责人候选）并复用——无需重新获取本次会话中已检索到的数据。
    • 当委托给
      fusion-issue-authoring
      或其下属技能时，需遵循编排器的会话缓存规则：标签和负责人候选按仓库单次获取，issue类型按组织单次获取。
    • 仅当MCP未覆盖相关功能时，才使用GraphQL作为备选方案，且不要循环重试。
    • 每次GraphQL变更操作会消耗5个次级限制点数（查询操作仅消耗1个）；将字段批量整合到单次调用中，且变更调用之间至少暂停1秒。
    • 预算意识：一次典型的实施会话（读取issue + 重复项检查 + 1-2次变更 + 子issue关联）的MCP读取调用应控制在约20次以内，变更调用控制在5次以内。若累计调用量接近30次及以上，暂停可选的信息补充操作，继续进行本地实施工作。
    • 遵守
      retry-after
      和
      x-ratelimit-reset
      响应头；在指示的等待时间之前不要重试。
    • 若触发速率限制，停止非必要操作，尽可能继续进行本地实施/PR准备工作。
  5. 制定并跟踪具体计划
    • 创建按依赖关系排序的可执行待办事项。
    • 同时仅推进一个步骤，完成后更新状态。
  6. 编辑前开展调研
    • 检查相关文件、测试用例及周边代码的使用方式。
    • 优先修复问题根源，而非仅做表面补丁。
  7. 以小范围变更的方式实施
    • 确保每次变更都符合issue的验收标准。
    • 避免进行无关的重构操作及生成发布工件。
  8. 逐步验证
    • 先运行针对性检查，再执行项目要求的检查。
    • 若检查失败，修复相关问题后重新运行，再继续后续操作。
  9. 准备可提交PR的输出内容
    • 总结变更内容及变更原因。
    • 包含验证证据及已知的后续工作。
    • 在
      .tmp/
      目录下创建一个与issue/上下文相关的命名文件（例如
      .tmp/pr-body-issue-123-scope-summary.md
      ）来起草PR正文，而非使用共享的
      .tmp/pr-body.md
      文件。
    • 基于
      .github/pull_request_template.md
      起草PR正文，并随着实施进展不断更新。
    • 询问目标基准分支，并建议一个合理的默认选项（通常为
      main
      ，或当前分支的源分支）。
    • 询问PR应设为草稿状态还是可审核状态。
    • 询问是否将PR分配给当前用户，以及是否关联相关issue。
  10. 可选的GitHub变更步骤
    • 在执行任何GitHub变更操作（创建/编辑/评论/关闭）前，需获得用户的明确确认。
    • 若用户要求，更新issue状态/评论以客观反映进展。
    • 当存在等效操作时，优先使用MCP工具执行变更，而非临时API调用。
    • 若GitHub API速率限制阻止了变更操作，清晰报告失败情况，停止重试循环，并提出安全的重试方案。
    • 若用户要求，使用仓库的PR模板和
      .tmp/
      目录下的PR正文草稿文件创建或更新PR，同时使用已确认的基准分支、草稿/可审核状态、负责人选择及相关issue关联。

Expected output

预期输出

Return a concise delivery report with:
  • implemented scope vs original issue criteria,
  • files changed,
  • validation commands and outcomes,
  • assignment decisions for primary issue and affected sub-issues,
  • API usage strategy used (MCP-first/cache reuse/fallbacks),
  • open risks/blockers,
  • PR body summary (or 
    .tmp/
    draft file path when created).
返回一份简洁的交付报告，包含：
  • 已实施范围与原始issue标准的对比，
  • 已变更的文件，
  • 验证命令及结果，
  • 主issue及受影响子issue的负责人分配决策，
  • 使用的API策略（优先MCP/缓存复用/备选方案），
  • 未解决的风险/阻塞点，
  • PR正文摘要（或已创建的
    .tmp/
    草稿文件路径）。

Assets

相关资源

  • assets/issue-solving-checklist.md
  • assets/issue-solving-checklist.md

Safety & constraints

安全与约束

  • Never request or expose secrets/credentials.
  • Never run destructive commands without explicit confirmation.
  • Keep changes minimal and scoped to the issue.
  • Do not claim checks passed without running them.
  • Follow repository instructions and contribution rules.
  • 绝不请求或泄露密钥/凭证。
  • 未经明确确认，绝不执行破坏性命令。
  • 保持变更最小化，且严格限定在issue范围内。
  • 未实际运行检查的情况下，不得声称检查通过。
  • 遵循仓库的操作指南及贡献规则。