|
| 1 | +--- |
| 2 | +# prettier-ignore |
| 3 | +description: "Autonomously triage and resolve a GitHub issue from analysis to PR ready for merge - handles investigation, fixes, testing, and PR workflow" |
| 4 | +argument-hint: "[issue-number]" |
| 5 | +version: 1.0.0 |
| 6 | +--- |
| 7 | + |
| 8 | +# /do-issue - Autonomous Issue Resolution |
| 9 | + |
| 10 | +<objective> |
| 11 | +Take a GitHub issue from initial triage to PR ready for merge, handling the complete lifecycle autonomously. Triage professionally, implement efficiently, deliver production-ready code. |
| 12 | +</objective> |
| 13 | + |
| 14 | +<user-provides> |
| 15 | +Issue number (or auto-detect from current branch) |
| 16 | +</user-provides> |
| 17 | + |
| 18 | +<command-delivers> |
| 19 | +Either a PR ready for merge resolving the issue, or a well-explained triage decision closing it. |
| 20 | +</command-delivers> |
| 21 | + |
| 22 | +## Usage |
| 23 | + |
| 24 | +``` |
| 25 | +/do-issue # Auto-detect from branch name |
| 26 | + # Patterns: do-issue-123, fix-issue-123, issue-123, fix-123 |
| 27 | +/do-issue 123 # Explicit issue number |
| 28 | +``` |
| 29 | + |
| 30 | +<branch-detection> |
| 31 | +If no issue number provided, extract from current branch name using `git branch --show-current`. |
| 32 | + |
| 33 | +Match patterns in order (extract first capture group): |
| 34 | +- `do-issue-(\d+)` |
| 35 | +- `fix-issue-(\d+)` |
| 36 | +- `issue-(\d+)` |
| 37 | +- `fix-(\d+)` |
| 38 | + |
| 39 | +If no match or not on a branch, prompt user for issue number. Validate it's a positive integer before proceeding. |
| 40 | +</branch-detection> |
| 41 | + |
| 42 | +## GitHub Interaction |
| 43 | + |
| 44 | +Use `gh` CLI for all GitHub operations. Use reactions to communicate progress: 👀 when |
| 45 | +analyzing, 🚀 when starting work, ❤️ on helpful user comments. |
| 46 | + |
| 47 | +## Workflow |
| 48 | + |
| 49 | +<fetch-and-analyze> |
| 50 | +Fetch the issue with `gh`. Check for existing PRs, assignees, and state. Extract the |
| 51 | +core request, user impact, and requirements. Add 👀 reaction. |
| 52 | +</fetch-and-analyze> |
| 53 | + |
| 54 | +<triage> |
| 55 | +Decide autonomously: Fix, Won't Fix, Need More Info, or Invalid. |
| 56 | + |
| 57 | +Show your decision and rationale briefly. Be professional and thoughtful - these are |
| 58 | +real users contributing to the project. |
| 59 | + |
| 60 | +For Won't Fix, Need Info, or Invalid: update the issue with explanation and close if |
| 61 | +appropriate. Done. |
| 62 | + |
| 63 | +For Fix: continue to implementation. </triage> |
| 64 | + |
| 65 | +<prepare> |
| 66 | +When proceeding with a fix: add 🚀 reaction, add in-progress label if available, and comment with your implementation approach (2-3 bullets). Note: AI assistants cannot assign issues to themselves via the GitHub API. |
| 67 | +</prepare> |
| 68 | + |
| 69 | +<implement> |
| 70 | +Use /autotask to implement the fix. Ensure the PR description includes "Fixes #{number}" |
| 71 | +so GitHub auto-links and closes the issue when merged. |
| 72 | +</implement> |
| 73 | + |
| 74 | +<polish> |
| 75 | +Use /address-pr-comments to handle bot feedback autonomously. |
| 76 | + |
| 77 | +This gets the PR to "ready to merge" state without human intervention for bot-related |
| 78 | +feedback. </polish> |
| 79 | + |
| 80 | +<finalize> |
| 81 | +Comment on the issue with the PR link. Add ❤️ to helpful user comments. The issue |
| 82 | +auto-closes when the PR merges due to the "Fixes #" keyword. |
| 83 | +</finalize> |
| 84 | + |
| 85 | +## Progress Tracking |
| 86 | + |
| 87 | +Use TodoWrite to track workflow phases. Create todos at the start, update status as you |
| 88 | +progress. The goal is transparency and ensuring you complete all phases. |
| 89 | + |
| 90 | +## Edge Cases |
| 91 | + |
| 92 | +If assigned to someone else, ask before taking over. If a PR already exists, skip if |
| 93 | +active or ask if stale (7+ days). If closed, ask before reopening. |
| 94 | + |
| 95 | +## Completion Criteria |
| 96 | + |
| 97 | +You're done when: |
| 98 | + |
| 99 | +- Issue is triaged with clear decision documented |
| 100 | +- If fixing: PR is created, bot feedback addressed, and PR is ready to merge |
| 101 | +- If not fixing: Issue is updated with explanation |
| 102 | +- Issue is properly linked to PR (if fixing) |
| 103 | +- All todos are marked completed |
| 104 | + |
| 105 | +Don't stop mid-workflow. The todos help ensure you complete all phases. |
| 106 | + |
| 107 | +## Error Recovery |
| 108 | + |
| 109 | +If /autotask or /address-pr-comments fail, evaluate recoverability. Transient errors |
| 110 | +(API failures, missing dependencies): retry with additional context. Fundamental |
| 111 | +blockers (architectural issues, unclear requirements): comment on the issue explaining |
| 112 | +the blocker and ask for guidance. Never silently abandon the workflow. |
| 113 | + |
| 114 | +## Key Principles |
| 115 | + |
| 116 | +Autonomous but transparent: make decisions independently, document them clearly. |
| 117 | +Professional communication: users took time to file issues, treat them with respect. |
| 118 | +Bias toward action: move quickly to implementation or explain thoughtfully why not. |
| 119 | +Complete the cycle: deliver the PR or close with explanation, never leave half-done. |
| 120 | + |
| 121 | +## Integration Points |
| 122 | + |
| 123 | +Uses existing commands: |
| 124 | + |
| 125 | +- `/autotask` - Implementation and PR creation |
| 126 | +- `/address-pr-comments` - Bot feedback handling |
| 127 | + |
| 128 | +Follows existing rules: |
| 129 | + |
| 130 | +- `@rules/git-commit-message.mdc` - Commit formatting (via /autotask) |
0 commit comments