|
| 1 | +--- |
| 2 | +name: github-issue-resolve |
| 3 | +description: >- |
| 4 | + Resolves a numbered GitHub issue using the GitHub CLI (gh): fetch full |
| 5 | + context, implement the fix, then post a structured summary comment on the |
| 6 | + issue. Use when the user asks to fix, solve, or implement a GitHub issue by |
| 7 | + number; mentions gh issue view or GitHub CLI for issues; or says to comment |
| 8 | + back on the issue after fixing. |
| 9 | +--- |
| 10 | + |
| 11 | +# GitHub issue resolve (gh CLI) |
| 12 | + |
| 13 | +## When this applies |
| 14 | + |
| 15 | +Use this workflow when the user gives an issue number (e.g. “fix #57”, “solve issue 42”) and expects the work tracked on GitHub with a **comment**, not only local code changes. |
| 16 | + |
| 17 | +## Prerequisites |
| 18 | + |
| 19 | +- `gh` installed and authenticated: `gh auth status` (if it fails, run `gh auth login`). |
| 20 | +- Shell with `network` permission when calling `gh`. |
| 21 | +- Run `gh` from the **git repo root** so `gh issue view` targets the correct repository. |
| 22 | + |
| 23 | +## 1. Load the issue |
| 24 | + |
| 25 | +Always fetch the issue before coding so title, body, labels, and images/links are grounded in real data. |
| 26 | + |
| 27 | +```bash |
| 28 | +gh issue view <N> |
| 29 | +``` |
| 30 | + |
| 31 | +Useful additions: |
| 32 | + |
| 33 | +```bash |
| 34 | +gh issue view <N> --json title,body,state,labels,assignees,comments --jq . |
| 35 | +``` |
| 36 | + |
| 37 | +If discussion matters: |
| 38 | + |
| 39 | +```bash |
| 40 | +gh issue view <N> --comments |
| 41 | +``` |
| 42 | + |
| 43 | +**Images in the body**: GitHub stores them as URLs; open or fetch if the visual is required to understand the bug. |
| 44 | + |
| 45 | +## 2. Implement the fix |
| 46 | + |
| 47 | +- Follow the repo’s normal patterns (read surrounding code first; minimal diff). |
| 48 | +- Run targeted checks (e.g. `eslint` on touched files, `bun run build` if appropriate). Fix anything **introduced** by the change. |
| 49 | + |
| 50 | +## 3. Summary for GitHub (before commenting) |
| 51 | + |
| 52 | +Draft a short, professional summary the maintainer can skim: |
| 53 | + |
| 54 | +- **What** was wrong (1–2 sentences, tied to the issue). |
| 55 | +- **What changed** (bullet list of files or areas; no huge pasted code). |
| 56 | +- **How to verify** (e.g. steps or pages to open). |
| 57 | +- Optional: **Follow-ups** only if truly out of scope. |
| 58 | + |
| 59 | +Do **not** include secrets, tokens, `.env` values, or internal-only URLs in the comment. |
| 60 | + |
| 61 | +## 4. Post the comment on the issue |
| 62 | + |
| 63 | +Post the summary as an **issue comment** (does not close the issue unless the user asked to close it). |
| 64 | + |
| 65 | +**Option A — body from stdin:** |
| 66 | + |
| 67 | +```bash |
| 68 | +gh issue comment <N> --body "$(cat <<'EOF' |
| 69 | +## Summary |
| 70 | +
|
| 71 | +[your markdown here] |
| 72 | +EOF |
| 73 | +)" |
| 74 | +``` |
| 75 | + |
| 76 | +**Option B — file:** |
| 77 | + |
| 78 | +Write the body to a temp file, then: |
| 79 | + |
| 80 | +```bash |
| 81 | +gh issue comment <N> --body-file /path/to/comment.md |
| 82 | +``` |
| 83 | + |
| 84 | +Prefer markdown headings (`##`) and bullets for readability. |
| 85 | + |
| 86 | +## 5. Close the issue (only if asked) |
| 87 | + |
| 88 | +If the user explicitly wants the issue closed after the fix: |
| 89 | + |
| 90 | +```bash |
| 91 | +gh issue close <N> --comment "Fixed in [branch/PR description]. See comment above for details." |
| 92 | +``` |
| 93 | + |
| 94 | +Otherwise leave it **open** for human review or PR merge. |
| 95 | + |
| 96 | +## Checklist |
| 97 | + |
| 98 | +- [ ] Fetched issue with `gh issue view` (and JSON/comments if needed). |
| 99 | +- [ ] Implemented and validated the change locally. |
| 100 | +- [ ] Wrote a concise summary (no secrets). |
| 101 | +- [ ] Posted `gh issue comment <N>`. |
| 102 | +- [ ] Closed the issue only if the user requested it. |
0 commit comments