/fix-issue Slash Command

---
description: Fix a GitHub issue end to end, implement, verify, and open a PR
argument-hint: [issue-number] [optional extra context]
allowed-tools: Bash(gh issue view:*), Bash(gh pr create:*), Bash(git checkout:*), Bash(git add:*), Bash(git commit:*), Bash(git push:*)
disable-model-invocation: true
---

## Context

- Issue: !`gh issue view $1 --json title,body,labels,comments`
- Current branch and status: !`git status --short && git branch --show-current`

## Task

Fix issue #$1. Extra context from me: $ARGUMENTS

Work in this order. Do not skip the verification gate:

1. **Understand**: restate the issue in one sentence: expected vs. actual behavior. If the issue is a feature request rather than a bug, or is too vague to define "fixed", STOP and tell me what's missing instead of guessing.
2. **Locate**: search the codebase for the code path the issue describes. List the files involved and the root cause before changing anything.
3. **Branch**: create `fix/issue-$1-[short-slug]` from the default branch.
4. **Reproduce first**: write the failing test that captures the bug (in the project's existing test style). Run it, confirm it fails for the issue's reason. A fix without a reproducing test is a guess.
5. **Fix**: the smallest change that makes the test pass without breaking others. Match surrounding code style. No drive-by refactoring. If you see unrelated problems, list them at the end instead of touching them.
6. **Verify**: run the full test suite and the project's lint/typecheck commands. All green or explain exactly what fails and why it's pre-existing.
7. **Ship**: commit (conventional format, referencing #$1), push, and open a PR with: what was broken, the root cause, what the fix changes, and "Closes #$1". Include the test evidence in the PR body.

Rules: commit only what this fix requires. If the fix grows beyond ~150 changed lines or touches more than 5 files, stop and check in with me: issues that big deserve a plan first.