| name | resolve-issue |
| description | Resolve a GitHub issue by analyzing it, implementing the fix, running tests, and creating a PR. Accepts an issue number or context description. |
| disable-model-invocation | true |
| argument-hint | [issue number or context description] |
Resolve GitHub Issue
You are resolving a GitHub issue for the current repository. Follow each phase carefully.
Phase 1: Understand the Issue
Check the argument: $ARGUMENTS
If argument is a number (issue number):
- Fetch issue details:
gh issue view <number> --json title,body,labels,comments,assignees
- Read through the issue title, body, and comments to fully understand the problem
- Summarize your understanding to the user
If argument is text (context description):
- Search for matching open issues:
gh issue list --state open --search "<context>" --json number,title,body,labels
- If a matching issue is found, use it. If not, inform the user and ask whether to proceed without an issue or create one first
- Analyze the provided context to understand what needs to be done
Phase 2: Check for Existing Local Changes
- Check if the user has already made local changes:
git status
git diff --stat
- If changes exist related to the issue:
- Review the changes with
git diff <file> for relevant files
- Verify they address the issue requirements
- If changes are correct, skip to Phase 4 (branch creation) or Phase 5 (commit)
- If changes need modification, inform the user what needs to be adjusted
- If unrelated changes are mixed in:
- Identify which files are relevant to the issue
- Plan to commit only the relevant files (use
git add <specific-files> instead of git add .)
Phase 3: Plan the Solution
Skip this phase if the user has already implemented the fix locally.
- Explore the codebase to understand the relevant code:
- Read CLAUDE.md or README.md if present for project conventions
- Find and read the files related to the issue
- Understand existing patterns and architecture
- Present a concise implementation plan to the user
- Ask the user for confirmation before proceeding:
- Options: "Proceed", "Modify plan", "Cancel"
Phase 4: Implement the Fix
- Check the repository's branch naming convention:
git branch -r | head -20
- Follow the existing convention (e.g.,
fix/, feat/, issue/, feature/)
- If no clear convention exists, use:
fix/ for bugs, feat/ for features, docs/ for documentation
- Create a new branch from the current branch:
git checkout -b <prefix>/<issue-number>-<short-description>
- If changes are not yet implemented, implement them following the plan
- Keep changes minimal and focused on the issue
Phase 5: Test
- Check if the project has a test command defined in CLAUDE.md, package.json, pyproject.toml, or Makefile
- Run the project's recommended test suite
- Report test results to the user:
- If all tests pass: show a summary
- If tests fail: analyze failures, attempt to fix, and re-run
- If no test configuration is found, inform the user and ask how to verify
Phase 6: Review and Commit
IMPORTANT: Always ask for user confirmation before committing.
- Show the user a summary of all changes:
git diff --stat
git diff
- Draft a commit message following conventional format:
type: short description
Detailed explanation of changes.
Closes #<issue-number>
- Ask the user for confirmation:
- Options: "Commit and create PR", "Review changes", "Modify changes", "Cancel"
- Only after user approval:
git add <specific-files>
git commit -m "<message>"
Phase 7: Create PR
IMPORTANT: Always ask for user confirmation before pushing and creating PR.
- Push the branch:
git push -u origin <branch-name>
- Create a PR with:
gh pr create --title "<title>" --body "<body>"
- PR body must include
Closes #<issue-number> to auto-close the issue on merge
- Include a Summary section and a Test plan section
- Display the created PR URL to the user
Guidelines
- Always read and understand existing code before making changes
- Follow the project's existing coding style and conventions
- Keep changes focused — do not fix unrelated issues or refactor unrelated code
- Run tests before committing to catch regressions
- Never force push or amend commits without user approval
- If stuck or uncertain, ask the user rather than guessing
