Skip to content
OpenSmartRoute
Skillv1.0.0

fusion-issue-solving

Handles GitHub issue resolution end-to-end for prompts like "solve #123", "lets solve #123", "work on #123", "work on https://github.com/owner/repo/issues/123", or by pasting a direct GitHub issue URL

by equinor(0) 0 installs
Free
Sign in to install

Free account. Installing gives you the manifest plus copy-paste snippets.

See reviews

About

Imported from equinor/fusion-skills (skills/.experimental/fusion-issue-solving/SKILL.md) via skills.sh. Install upstream with npx skills add equinor/fusion-skills --skill fusion-issue-solving. Copyright stays with the author (MIT).

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:

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

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.

Use it

Copy one of these into your project. Installing also returns the manifest and these snippets.

yaml
targets:
  - https://api.opensmartroute.ai/api/v1/registry/equinor-fusion-skills-fusion-issue-solving/manifest   # or paste the manifest below

Manifest

An Open Capability Manifest: the router reads it to know what this does, what it costs and when to pick it.

equinor-fusion-skills-fusion-issue-solving.ocm.jsonjson
{
  "ocm": "1",
  "id": "equinor-fusion-skills-fusion-issue-solving",
  "kind": "skill",
  "name": "fusion-issue-solving",
  "description": "Handles GitHub issue resolution end-to-end for prompts like \"solve #123\", \"lets solve #123\", \"work on #123\", \"work on https://github.com/owner/repo/issues/123\", or by pasting a direct GitHub issue URL as the request. USE FOR: solve #123, continue work on issue #123, work on https://github.com/owner/repo/issues/123, paste a GitHub issue URL for implementation work. DO NOT USE FOR: issue drafting only, PR review only, or non-implementation research.",
  "publisher": "equinor",
  "version": "1.0.0",
  "capabilities": {
    "domains": [
      "general"
    ],
    "tags": [
      "skill-md",
      "github",
      "github-issue",
      "issue-solving",
      "issue-workflow",
      "implementation",
      "workflow",
      "continue",
      "skills-sh"
    ],
    "languages": [
      "en"
    ]
  },
  "quality_prior": 0.6,
  "examples": [
    "Handles GitHub issue resolution end-to-end for prompts like \"solve #123\", \"lets solve #123\", \"work on #123\", \"work on https://github.com/owner/repo/issues/123\", or by pasting a direct GitHub issue URL as the request. USE FOR: solve #123, continue work on issue #123, work on https://github.com/owner/repo/issues/123, paste a GitHub issue URL for implementation work. DO NOT USE FOR: issue drafting only, PR review only, or non-implementation research."
  ],
  "primary": false,
  "metadata": {
    "source": {
      "provider": "skills.sh",
      "repository": "https://github.com/equinor/fusion-skills",
      "path": "skills/.experimental/fusion-issue-solving/SKILL.md",
      "ref": "HEAD",
      "url": "https://www.skills.sh/equinor/fusion-skills/fusion-issue-solving",
      "key": "equinor/fusion-skills/skills/.experimental/fusion-issue-solving/SKILL.md"
    },
    "license": "MIT"
  },
  "instructions": "# Issue Solving Workflow\n\n## When to use\n\nUse 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`.\n\nTypical triggers:\n- \"lets solve #123\"\n- \"solve #123\"\n- \"work on #123\"\n- \"lets work on https://github.com/owner/repo/issues/123\"\n- \"https://github.com/owner/repo/issues/123\"\n- \"continue work on issue #123\"\n- \"implement issue #123 end-to-end\"\n- \"work on this ticket: [issue URL]\"\n- \"research, implement, and prepare a PR for this i",
  "cost": {
    "context_tokens": 1608
  }
}

Fetch it by URL: GET /api/v1/registry/equinor-fusion-skills-fusion-issue-solving/manifest?version=1.0.0

Reviews

Star ratings from people who tried it. One review per account; edit yours any time.

No reviews yet. Install it, try it, and be the first to rate it.