|
| 1 | +--- |
| 2 | +name: take-issue |
| 3 | +description: Take a GitHub issue and implement it following the project workflow |
| 4 | +user_invocable: true |
| 5 | +arguments: |
| 6 | + - name: issue |
| 7 | + description: "GitHub issue number to implement" |
| 8 | + required: true |
| 9 | +--- |
| 10 | + |
| 11 | +# Take Issue Workflow |
| 12 | + |
| 13 | +You are implementing a GitHub issue for the bombfork/internet-exploder project. Follow this process exactly. |
| 14 | + |
| 15 | +## Phase 1: Read the issue |
| 16 | + |
| 17 | +Fetch the issue details: |
| 18 | +```bash |
| 19 | +gh issue view {{ issue }} --repo bombfork/internet-exploder |
| 20 | +``` |
| 21 | + |
| 22 | +## Phase 2: Check for open children |
| 23 | + |
| 24 | +Check if this issue has open sub-issues: |
| 25 | +```bash |
| 26 | +gh api graphql -f query='query { |
| 27 | + repository(owner: "bombfork", name: "internet-exploder") { |
| 28 | + issue(number: {{ issue }}) { |
| 29 | + subIssues(first: 50, filter: {states: [OPEN]}) { |
| 30 | + nodes { number title } |
| 31 | + } |
| 32 | + } |
| 33 | + } |
| 34 | +}' --jq '.data.repository.issue.subIssues.nodes' |
| 35 | +``` |
| 36 | + |
| 37 | +**If there are open children: STOP.** Tell the user this issue has open sub-issues that must be completed first, and list them. Do not proceed. |
| 38 | + |
| 39 | +## Phase 3: Check parent and siblings |
| 40 | + |
| 41 | +Only if there are NO open children, continue. |
| 42 | + |
| 43 | +Get the parent issue: |
| 44 | +```bash |
| 45 | +gh api graphql -f query='query { |
| 46 | + repository(owner: "bombfork", name: "internet-exploder") { |
| 47 | + issue(number: {{ issue }}) { |
| 48 | + parentIssue { number title } |
| 49 | + } |
| 50 | + } |
| 51 | +}' --jq '.data.repository.issue.parentIssue' |
| 52 | +``` |
| 53 | + |
| 54 | +If there is a parent, read it and its children (siblings of our issue): |
| 55 | +```bash |
| 56 | +# Read the parent issue |
| 57 | +gh issue view <PARENT_NUMBER> --repo bombfork/internet-exploder |
| 58 | + |
| 59 | +# Get all sibling issues with their state |
| 60 | +gh api graphql -f query='query { |
| 61 | + repository(owner: "bombfork", name: "internet-exploder") { |
| 62 | + issue(number: <PARENT_NUMBER>) { |
| 63 | + subIssues(first: 50) { |
| 64 | + nodes { number title state } |
| 65 | + } |
| 66 | + } |
| 67 | + } |
| 68 | +}' --jq '.data.repository.issue.subIssues.nodes' |
| 69 | +``` |
| 70 | + |
| 71 | +Assess whether issue #{{ issue }} is the right one to implement next, considering: |
| 72 | +- Dependencies between sibling issues (some must be done before others) |
| 73 | +- Whether prerequisite siblings are already closed |
| 74 | +- The implementation order described in the parent issue |
| 75 | + |
| 76 | +**If there is a better candidate**: tell the user which issue should be implemented first and why. Ask whether they want to stop or keep going with #{{ issue }} anyway. If they want to stop, end here. |
| 77 | + |
| 78 | +## Phase 4: Read comments and implement |
| 79 | + |
| 80 | +Read any comments on the issue: |
| 81 | +```bash |
| 82 | +gh api repos/bombfork/internet-exploder/issues/{{ issue }}/comments --jq '.[].body' |
| 83 | +``` |
| 84 | + |
| 85 | +Now implement the issue: |
| 86 | +- Work on the `main` branch directly (no feature branches) |
| 87 | +- Create one or more commits as you go |
| 88 | +- Each commit message follows conventional commit format referencing the issue: `feat(scope): description #{{ issue }}` |
| 89 | +- Never bypass pre-commit hooks |
| 90 | +- Never force push |
| 91 | +- Run `mise run check` to verify everything passes before considering the issue done |
| 92 | + |
| 93 | +Work through all the implementation items and acceptance criteria listed in the issue. |
| 94 | + |
| 95 | +## Phase 5: Review and confirm |
| 96 | + |
| 97 | +When all acceptance criteria are met: |
| 98 | + |
| 99 | +1. Review all non-pushed commits: |
| 100 | +```bash |
| 101 | +git log origin/main..HEAD --oneline |
| 102 | +git diff origin/main..HEAD --stat |
| 103 | +``` |
| 104 | + |
| 105 | +2. Show the user a summary of what was implemented and the commits made. |
| 106 | + |
| 107 | +3. Ask the user if they are satisfied with the implementation. |
| 108 | + |
| 109 | +4. If satisfied, propose to push and close the issue. |
| 110 | + |
| 111 | +## Phase 6: Push, close, and prepare next |
| 112 | + |
| 113 | +Only if the user agreed to push and close: |
| 114 | + |
| 115 | +1. Identify the probable next sibling issue to implement: |
| 116 | + - Look at the open siblings from Phase 3 |
| 117 | + - Consider the implementation order |
| 118 | + - Pick the next one whose prerequisites are now met |
| 119 | + |
| 120 | +2. Assess if the current implementation impacts the definition of the next issue: |
| 121 | + - Did you discover something during implementation that changes what the next issue should do? |
| 122 | + - Did you make an architectural decision that the next issue should know about? |
| 123 | + - Did you add/change APIs that the next issue depends on? |
| 124 | + |
| 125 | + If so, add a comment to the next issue with the relevant information: |
| 126 | + ```bash |
| 127 | + gh issue comment <NEXT_ISSUE> --repo bombfork/internet-exploder --body "..." |
| 128 | + ``` |
| 129 | + |
| 130 | +3. Push the code: |
| 131 | +```bash |
| 132 | +git push origin main |
| 133 | +``` |
| 134 | + |
| 135 | +4. Close the issue: |
| 136 | +```bash |
| 137 | +gh issue close {{ issue }} --repo bombfork/internet-exploder |
| 138 | +``` |
| 139 | + |
| 140 | +5. Tell the user the issue is closed and suggest the next issue to take. |
0 commit comments