How do I install the Resolve Issue skill?

Run npx skillmds@latest add joshukraine/resolve-issue in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Resolve Issue skill do?

Full issue workflow — fetch details, research, plan solution, implement, and verify. It is listed under Research & Search on SkillMD.

Is Resolve Issue safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Resolve Issue?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Resolve Issue free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Resolve Issue?

joshukraine (@joshukraine) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Resolve Issue by joshukraine — Agent Skill

Name: Resolve Issue
Author: joshukraine

File contents

Resolve GitHub Issue

Take a GitHub issue through to a verified, committed implementation on a feature branch — stopping short of the PR.

Fetch — both calls, always

gh issue view $ARGUMENTS                # title, labels, body, and a `comments: N` count
gh issue view $ARGUMENTS --comments     # the thread — this one omits the body, so it is not a swap for the first

Read the comments, not just the body. The body is the oldest artifact on an issue; comments carry scope added later, sequencing against other issues, and decisions that supersede an acceptance criterion still written in the body. An issue filed months ago and worked today is the normal case, not the exception. Run the second call unconditionally — the comments: N count sits in a metadata header that is easy to skim past, and a zero-comment issue costs one wasted call.

Plan before implementing

Right-size the ceremony to the issue:

Small and well-scoped (a few files, an obvious approach) — state the plan in a line and proceed. Don't wait for a reply.
Complex or ambiguous (multiple subsystems, design choices, real risk) — present the implementation plan and wait for explicit approval.

When unsure which applies, treat it as complex and ask.

Branch

Check git branch --show-current first:

Already on a feature branch for this issue (<prefix>/gh-$ARGUMENTS-…) — reuse it, do not create a second branch. This includes re-entering this step inside an autopilot fan-out worktree.
Otherwise — git switch -c <prefix>/gh-$ARGUMENTS-<short-description>

The prefix comes from the issue's type label. If the project defines its own branch convention, that wins.

Type label	Prefix
`feat`	`feat/`
`fix`	`fix/`
`chore`	`chore/`
`docs`	`docs/`
`test`	`test/`

No type label? Bug fixes are fix/, new functionality feat/, everything else chore/.

Commit as you go

Commit each working component rather than everything at the end — typically 3–8 commits for an issue, each one working code.

Never reference the issue number in a commit message. Issues close when the PR merges, so the closing keyword belongs in the PR description, not the commits.

Before reporting done

Run the project's full test suite and confirm no regressions. Do not proceed until it passes.

Then check off the acceptance criteria the work satisfied. Round-trip through a file rather than a shell variable — issue bodies routinely contain backticks and $(...), and a file keeps them out of shell parsing entirely:

gh issue view $ARGUMENTS --json body --jq '.body' > <scratchpad>/issue-body.md
# edit that file: flip `- [ ]` to `- [x]` for the criteria now satisfied
gh issue edit $ARGUMENTS --body-file <scratchpad>/issue-body.md

Check off only what the work actually satisfied. If a criterion was superseded by a comment, say so in the summary rather than silently ticking or skipping it.

Hand off — do not create the PR

Summarize what changed: files touched, commits made, test status, and which acceptance criteria are now met. Then stop and ask.

Recommend /simplify first for anything non-trivial, then /create-pr — it infers the issue number from the branch name.

---name: resolve-issuedescription: Full issue workflow — fetch details, research, plan solution, implement, and verify.---# Resolve GitHub IssueTake a GitHub issue through to a verified, committed implementation on a feature branch — stopping short of the PR.## Fetch — both calls, always```bashgh issue view $ARGUMENTS # title, labels, body, and a `comments: N` countgh issue view $ARGUMENTS --comments # the thread — this one omits the body, so it is not a swap for the first```**Read the comments, not just the body.** The body is the oldest artifact on an issue; comments carry scope added later, sequencing against other issues, and decisions that supersede an acceptance criterion still written in the body. An issue filed months ago and worked today is the normal case, not the exception. Run the second call unconditionally — the `comments: N` count sits in a metadata header that is easy to skim past, and a zero-comment issue costs one wasted call.## Plan before implementingRight-size the ceremony to the issue:- **Small and well-scoped** (a few files, an obvious approach) — state the plan in a line and proceed. Don't wait for a reply.- **Complex or ambiguous** (multiple subsystems, design choices, real risk) — present the implementation plan and **wait for explicit approval**.When unsure which applies, treat it as complex and ask.## BranchCheck `git branch --show-current` first:- **Already on a feature branch for this issue** (`<prefix>/gh-$ARGUMENTS-…`) — reuse it, do not create a second branch. This includes re-entering this step inside an autopilot fan-out worktree.- **Otherwise** — `git switch -c <prefix>/gh-$ARGUMENTS-<short-description>`The prefix comes from the issue's type label. If the project defines its own branch convention, that wins.| Type label | Prefix || --- | --- || `feat` | `feat/` || `fix` | `fix/` || `chore` | `chore/` || `docs` | `docs/` || `test` | `test/` |No type label? Bug fixes are `fix/`, new functionality `feat/`, everything else `chore/`.## Commit as you goCommit each working component rather than everything at the end — typically 3–8 commits for an issue, each one working code.**Never reference the issue number in a commit message.** Issues close when the PR merges, so the closing keyword belongs in the PR description, not the commits.## Before reporting doneRun the project's full test suite and confirm no regressions. **Do not proceed until it passes.**Then check off the acceptance criteria the work satisfied. Round-trip through a file rather than a shell variable — issue bodies routinely contain backticks and `$(...)`, and a file keeps them out of shell parsing entirely:```bashgh issue view $ARGUMENTS --json body --jq '.body' > <scratchpad>/issue-body.md# edit that file: flip `- [ ]` to `- [x]` for the criteria now satisfiedgh issue edit $ARGUMENTS --body-file <scratchpad>/issue-body.md```Check off only what the work actually satisfied. If a criterion was superseded by a comment, say so in the summary rather than silently ticking or skipping it.## Hand off — do not create the PRSummarize what changed: files touched, commits made, test status, and which acceptance criteria are now met. Then **stop and ask**.Recommend `/simplify` first for anything non-trivial, then `/create-pr` — it infers the issue number from the branch name.

Frequently asked questions

Resolve Issue