fix-issue

name	fix-issue
description	End-to-end flow for resolving a GitHub issue — fetch and understand the issue, create a feature branch off `beta`, implement and verify the fix, then hand off to the open-pr skill. Use when the user says "fix issue <n>", "work on issue <n>", or wants to take an issue from investigation through to a PR.

Drive a GitHub issue from investigation to a ready-to-review fix on a feature branch. This skill owns understanding, branching, and implementing. It hands the commit/push/PR step off to the open-pr skill.

Take the issue number/URL from the user. If none is given, ask for it.

1. Understand the issue

• gh issue view <n> --json title,body,state,labels,comments,author,createdAt to read it. (Plain gh issue view <n> may fail on Projects-classic GraphQL — prefer the --json form.)
• Read any linked reproduction repo, error output, and referenced files. Identify the affected package/area.
• Trace the root cause in the codebase before writing anything — read the relevant source, not just the symptom. Delegate broad searches to the Explore agent when the cause could live in several places.
• Restate the root cause and intended fix to the user, and confirm the approach before large or behavior-changing edits. Surface trade-offs and regression risks.

2. Create a feature branch off beta

• Branch from the base branch (beta by default; honor a different base if the user names one). First sync the base with its remote so the new branch starts from the latest tip: git checkout <base> && git pull --ff-only && git checkout -b <type>/<n>-<short-slug> <base> — pick <type> from the change (fix, feat, chore, docs, refactor, test) and a short kebab slug referencing the issue, e.g. fix/2348-dts-in-source.
• If git pull --ff-only fails (local diverged from remote), stop and surface it to the user — don't force or rebase silently.
• If the user already created/named a branch, use that instead. Never implement on the base branch.

3. Implement the fix

• Make the minimal, well-scoped change that addresses the root cause. Match the surrounding code's style and idioms.
• Add or update tests when the repo's conventions call for them — but respect explicit user direction (e.g. "no snapshot test").
• Verify as far as the environment allows: run the affected package's tests/typecheck if dependencies are installed; if they aren't, say so plainly rather than claiming success. Consider the verify or code-review skills for behavior changes.
• Reason explicitly about regressions: who else hits this code path, and does the change alter their behavior?

4. Hand off to open-pr

• Once the fix is on the feature branch and verified, invoke the open-pr skill to format, commit (with Closes #<n>), push, and open the PR against beta.
• Don't duplicate open-pr's logic here — it owns commit message conventions, the PR template, scope mapping, and the outward-facing confirmation.

Notes

• Keep investigation findings concise but show the evidence (file:line) for the root cause.
• If the issue turns out to be invalid, already fixed, or a usage question rather than a bug, report that instead of forcing a fix.