How do I install the Fix Issue skill?

Run npx skillmds@latest add iamneilroberts/fix-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.

Is Fix 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 Fix 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 Fix Issue free to use?

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

Who published Fix Issue?

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

Fix Issue by iamneilroberts — Agent Skill

Name: Fix Issue
Author: iamneilroberts

Fix Issue

Take a GitHub issue and actually resolve it end to end — read the issue, reproduce it, fix it in an isolated branch with a test, verify, and open a PR that closes the issue. The counterpart to /idea (which files issues): /idea captures, /fix-issue clears. Works off `gh` in whatever repo you're in. Triggers on `/fix-issue <number|url>`, "fix issue #N", "resolve this github issue", "pick up and fix issue N".

File contents

/fix-issue — resolve a GitHub issue, branch → fix → PR

Turns a filed issue into a merge-ready change: understand, reproduce, fix with a test, verify, and open a PR that closes the issue. Never pushes or opens a PR without showing the diff first.

Steps

Load the issue. Resolve the arg to an issue number (bare number or full URL). Read it and its discussion:
```
gh issue view <n> --comments
```
Extract the actual problem, repro steps, acceptance criteria, and linked PRs/commits. If the issue is vague or already closed, say so and ask before proceeding — don't guess at scope.
Confirm scope (one beat). State in one or two lines what you're changing and what "done" means for this issue. If the issue is really several changes, do the smallest coherent one and note the rest. Don't expand scope beyond what the issue asks.
Isolate the work. Create a dedicated branch/worktree so this doesn't collide with other work. Prefer the branch skill if it's installed (/branch fix-<n>-<slug>); otherwise git worktree add, or at minimum git checkout -b fix-<n>-<slug>. Check git status first — never start on top of another session's uncommitted WIP.
Reproduce before fixing (for a bug). Write a failing test that captures the issue, or otherwise demonstrate the broken behavior concretely — a fix with no reproduction is a guess. For a feature/chore, write the test that encodes the acceptance criteria. (TDD applied to the issue: red first.)
Fix it. Make the smallest change that turns the test green. Touch only what the issue needs — don't reformat or refactor adjacent code on the way past.
Verify — evidence, not assertion. Run the real commands and read the output: the new test passes, the existing suite still passes, typecheck/lint clean, and (if relevant) a manual check of the behavior the issue described. If anything fails, keep working — do not open the PR.
Review (optional but recommended). Run /codex-review or /review-panel if installed, and address anything critical/important before opening the PR. /curate, if installed, can confirm the "fixed" claim against actual repo state.
Open the PR (with your confirmation). Show the diff summary, then open a PR whose body closes the issue:
```
gh pr create --title "<imperative summary> (closes #<n>)" \
  --body "Closes #<n>\n\n<what changed and why, one short paragraph + the verification you ran>"
```
Use Closes #<n> so merging the PR auto-closes the issue. Don't push or create the PR until you've shown the change and gotten a go-ahead.
Report. One line: branch, PR URL, and the issue it closes. Note any follow-up the issue implied but you consciously left out of scope.

Guardrails

Reproduce first, or say you couldn't. If you can't reproduce a bug, don't ship a speculative fix — report what you tried and ask for more detail.
Scope discipline. One issue, one focused change. File anything extra you notice with /idea rather than dragging it into this PR.
No silent success. Every "passes / fixed / done" must be backed by a command you ran this session and its output.

---name: fix-issuedescription: Take a GitHub issue and actually resolve it end to end — read the issue, reproduce it, fix it in an isolated branch with a test, verify, and open a PR that closes the issue. The counterpart to /idea (which files issues): /idea captures, /fix-issue clears. Works off `gh` in whatever repo you're in. Triggers on `/fix-issue <number|url>`, "fix issue #N", "resolve this github issue", "pick up and fix issue N".---# /fix-issue — resolve a GitHub issue, branch → fix → PRTurns a filed issue into a merge-ready change: understand, reproduce, fix with a test, verify, andopen a PR that closes the issue. Never pushes or opens a PR without showing the diff first.## Steps1. **Load the issue.** Resolve the arg to an issue number (bare number or full URL). Read it and its discussion: ```bash gh issue view <n> --comments ``` Extract the actual problem, repro steps, acceptance criteria, and linked PRs/commits. If the issue is vague or already closed, say so and ask before proceeding — don't guess at scope.2. **Confirm scope (one beat).** State in one or two lines what you're changing and what "done" means for this issue. If the issue is really several changes, do the smallest coherent one and note the rest. Don't expand scope beyond what the issue asks.3. **Isolate the work.** Create a dedicated branch/worktree so this doesn't collide with other work. Prefer the `branch` skill if it's installed (`/branch fix-<n>-<slug>`); otherwise `git worktree add`, or at minimum `git checkout -b fix-<n>-<slug>`. Check `git status` first — never start on top of another session's uncommitted WIP.4. **Reproduce before fixing** (for a bug). Write a failing test that captures the issue, or otherwise demonstrate the broken behavior concretely — a fix with no reproduction is a guess. For a feature/chore, write the test that encodes the acceptance criteria. (TDD applied to the issue: red first.)5. **Fix it.** Make the smallest change that turns the test green. Touch only what the issue needs — don't reformat or refactor adjacent code on the way past.6. **Verify — evidence, not assertion.** Run the real commands and read the output: the new test passes, the existing suite still passes, typecheck/lint clean, and (if relevant) a manual check of the behavior the issue described. If anything fails, keep working — do not open the PR.7. **Review (optional but recommended).** Run `/codex-review` or `/review-panel` if installed, and address anything critical/important before opening the PR. `/curate`, if installed, can confirm the "fixed" claim against actual repo state.8. **Open the PR (with your confirmation).** Show the diff summary, then open a PR whose body **closes the issue**: ```bash gh pr create --title "<imperative summary> (closes #<n>)" \ --body "Closes #<n>\n\n<what changed and why, one short paragraph + the verification you ran>" ``` Use `Closes #<n>` so merging the PR auto-closes the issue. Don't push or create the PR until you've shown the change and gotten a go-ahead.9. **Report.** One line: branch, PR URL, and the issue it closes. Note any follow-up the issue implied but you consciously left out of scope.## Guardrails- **Reproduce first, or say you couldn't.** If you can't reproduce a bug, don't ship a speculative fix — report what you tried and ask for more detail.- **Scope discipline.** One issue, one focused change. File anything extra you notice with `/idea` rather than dragging it into this PR.- **No silent success.** Every "passes / fixed / done" must be backed by a command you ran this session and its output.

Frequently asked questions