GitHub Fix Issue Skill

Description

This skill handles the full lifecycle of resolving a GitHub issue: reading the issue, understanding the requirements, finding relevant code, implementing the fix, validating with tests, and creating a pull request.

Instructions

When the user provides a GitHub issue (number or URL), execute this workflow:

Phase 1: Issue Analysis

Copy
# Fetch issue details
gh issue view 42 --json title,body,labels,assignees,comments

Extract from the issue:

• What needs to change (bug description, feature request)
• Reproduction steps (if bug)
• Acceptance criteria (explicit or inferred)
• Labels for context (bug, enhancement, breaking-change)

Phase 2: Codebase Investigation

Locate relevant code:

Copy
# Search for related files
grep -r "relatedFunction" src/ --include="*.ts" -l

# Check recent changes to affected area
git log --oneline -10 -- src/affected-module/

# Read test files for context
cat src/affected-module/__tests__/

Document findings:

Copy
## Investigation Notes
- **Root cause:** The `validateInput()` function in `src/utils/validation.ts:45`
  does not handle empty arrays, causing a TypeError
- **Affected files:** validation.ts, userController.ts
- **Existing tests:** 3 tests in validation.test.ts, none cover empty arrays

Phase 3: Implementation

1. Create a feature branch:

   Copy
   git checkout -b fix/issue-42-empty-array-validation

2. Implement the fix with minimal, focused changes
3. Add or update tests covering the fix
4. Run the test suite to verify:

   Copy
   npm test

Phase 4: Pull Request

Create a PR that references the issue:

Copy
gh pr create \
  --title "Fix empty array validation error" \
  --body "## Summary
Fixes #42. The validateInput() function now handles empty arrays gracefully.

## Changes
- Added empty array check in validation.ts
- Added 2 test cases for edge cases

## Test Plan
- [x] Existing tests pass
- [x] New tests cover empty array case
- [x] Manual verification with reproduction steps from issue"

Rules

• Always read the full issue including comments before starting
• Create a dedicated branch named fix/issue-{number}-{short-description}
• Keep changes minimal and focused — only fix what the issue describes
• Add tests that would have caught the bug (regression tests)
• Reference the issue number in the PR body with Fixes #N syntax
• If the fix requires breaking changes, flag this prominently in the PR
• If the issue is unclear or ambiguous, ask the user for clarification before implementing
• Run lint and tests before creating the PR
• Never force-push or modify git history on shared branches

Examples

User: Fix issue #42 Action: Read issue, investigate codebase, implement fix, create PR

User: Fix https://github.com/org/repo/issues/42 Action: Same workflow, extract issue number from URL

User: Fix the login bug from issue 15 and the signup issue 16 Action: Handle each issue on its own branch, create separate PRs