Fusion Issue Solving

Issue Solving Workflow

When to use

Use 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:

• "lets solve #123"
• "solve #123"
• "work on #123"
• "lets work on https://github.com/owner/repo/issues/123"
• "https://github.com/owner/repo/issues/123"
• "continue work on issue #123"
• "implement issue #123 end-to-end"
• "work on this ticket: [issue URL]"
• "research, implement, and prepare a PR for this issue"

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 serve as the main request payload when no competing intent is stated.

When not to use

• Request is only issue drafting/authoring
• No implementation changes expected
• Repository write operations are disallowed

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:

• related issues/PRs
• risk areas to prioritize
• requested commit/PR granularity

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.

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).

Assets

• assets/issue-solving-checklist.md

Safety & constraints

• This skill is mutation-capable. Repository-local workflow instructions take precedence over inline guidance when they conflict.
• 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 Solving Checklist

Use this checklist while executing the issue-solving workflow.

Changelog

0.1.7 - 2026-05-07

patch

• #170 `5e43223` - Apply caveman-compress prose style to SKILL.md.

• Drop articles, filler, hedging from SKILL.md activation body

0.1.6 - 2026-03-24

patch

• #126 `1470bc8` - Add repository-policy handoff section for governance alignment

• Add explicit "Repository-policy handoff" section that defers commit, validation, changeset, and PR rules to repo-local instructions

Resolves equinor/fusion-core-tasks#581

0.1.5 - 2026-03-17

patch

• #85 `c8ba3df` - Make all GitHub-API-consuming skills more conservative with token usage.

• fusion-issue-authoring: concrete session-cache flow for labels and assignee candidates; per-session budget table
• fusion-issue-solving: expanded low-token strategy with session-cache references and budget awareness
• fusion-github-review-resolution: token budget guidance for thread-heavy reviews; cache PR metadata once
• fusion-issue-task-planning: session-cache delegation rules and batch-size warning for large task plans
• fusion-dependency-review: explicit data-reuse rules across parallel advisor fan-out
• fusion-discover-skills: tighter GraphQL budget and call-count cap for discovery sessions

resolves equinor/fusion-core-tasks#797

0.1.4 - 2026-03-11

patch

• #76 `3efc478` - Improve issue-solving workflow reliability under GitHub API limits by documenting a low-token execution strategy.

• Require reuse of fetched issue context instead of repeated reads
• Add MCP-first guidance for issue workflow mutations and lookups
• Add explicit no-retry-loop behavior for rate-limit failures
• Extend the workflow checklist with token-usage and fallback controls

resolves equinor/fusion-core-tasks#535

0.1.3 - 2026-03-11

patch

• #71 `b7fe258` - Strengthen issue-solving discovery cues for short prompts and direct GitHub issue URLs.

• move representative activation phrases into the frontmatter description so semantic routing can match solve #123, lets solve #123, and full https://github.com/owner/repo/issues/123 prompts
• clarify that direct GitHub issue URLs can stand in for #123 references, including URL-first prompts

resolves equinor/fusion-skills#66

0.1.2 - 2026-03-05

patch

• #55 `2d346c8` - Add required ownership metadata (metadata.owner, metadata.status) to all skills. Owner is set to @equinor/fusion-core (repository default) and status is set according to skill lifecycle (active for production skills, experimental for early-stage skills). Sponsor metadata was considered but is not required for MVP.

resolves equinor/fusion-core-tasks#474

• #55 `2d346c8` - Improve skill activation and discoverability cues

• Enhance description with explicit activation keywords: "continue on", "GitHub issue workflow"
• Reorganize "When to use" section to lead with "continue work on" pattern as primary trigger
• Add discoverable trigger examples matching common issue-solving requests

0.1.1 - 2026-03-03

patch

• #40 `cd68535` - Remove deprecated origin frontmatter metadata from the experimental fusion-issue-solving skill.

0.1.0 - 2026-03-02

minor

• #35 `73809e4` - Add experimental fusion-issue-solving skill under skills/.experimental/ with a structured workflow for issue intake, planning, implementation, validation, and PR-ready reporting.

Includes a companion execution checklist asset for consistent progress tracking.

resolves equinor/fusion-core-tasks#432