| name | github-issue |
| description | Unified GitHub issue workflow via the gh CLI โ fetch an issue (body, labels, comments, image/video attachments) into the session, create a new issue from a template, or update an existing one (body, labels, state, comments). Handles the 404 that plain curl/WebFetch hits on GitHub attachment URLs by downloading with an auth token, and extracts viewable frames from video attachments. Use whenever the user mentions GitHub issues โ ์ด์ ๊ฐ์ ธ์, ์ด์ ์กฐํ, ์ด์ ๋ฑ๋ก, ์ด์ ์์ฑ, ์ด์ ๋ง๋ค์ด์ค, ์ด์ ์
๋ฐ์ดํธ, ์ด์ ์์ , ์ด์ ์ฝ๋ฉํธ, ์ด์ ์์
, fetch issue N, work on issue N, create an issue, update issue N, file a bug, /github-issue. |
GitHub Issue
Operate on GitHub issues with the gh CLI. One skill, three operations โ dispatch on the user's words or the argument:
| User intent | Operation |
|---|
"์ด์ N ๊ฐ์ ธ์ / ์กฐํ / ์์
", "fetch issue N", bare /github-issue 94 | Fetch |
| "์ด์ ๋ฑ๋ก / ์์ฑ / ๋ง๋ค์ด์ค", "create issue", "file a bug" | Create |
| "์ด์ N ์์ / ์
๋ฐ์ดํธ / ์ฝ๋ฉํธ / ๋ซ์์ค", "update issue N" | Update |
If the intent is genuinely ambiguous, ask which operation โ don't guess.
Common setup
- Confirm
gh auth status works once; if not, stop and tell the user to run gh auth login.
- Default to the current repo. If the user names another repo, pass
-R <owner>/<repo> to every gh call.
Fetch
- If no issue number was given, run
gh issue list, show the open issues, and let the user pick.
gh issue view <N> --json number,title,state,labels,author,url,body,comments
- Download every attachment found in the body and comments โ plain curl/WebFetch returns 404 on GitHub attachment URLs. Follow fetching.md exactly (auth-token download, image Read, video โ ffmpeg frames).
- Summarize in the conversation: issue number/title/labels, the problem or request in one or two lines, and what the attachments show.
- If the user is picking the issue up to work on it: locate the relevant code (grep for the symbols/strings the issue points at), state an initial hypothesis and candidate approach in a sentence or two โ then stop. Do not start editing code; intake ends at understanding.
Create
-
Pick a template, in this order:
-
Fill the template from the conversation and any context the user gave. Write the issue in the language of the repo's existing issues (check a recent one if unsure). Ask only for fields you genuinely can't fill โ don't interrogate.
-
Show the complete draft (title, body, labels) and wait for the user's OK before creating. Filing an issue is outward-facing and visible to others; never skip this gate.
-
Create with a body file so markdown survives quoting:
gh issue create --title "<title>" --body-file <draft.md> --label "<labels>"
Only pass labels that already exist in the repo (gh label list) โ gh errors on unknown labels. Same rule for --add-label on update.
-
Report the created issue URL.
Update
- Fetch the current state first (
gh issue view <N> --json title,body,labels,state) โ never edit blind.
- Show what will change as before โ after (title/body diff, labels added/removed, state change) and get confirmation before applying.
- Apply with the matching command:
- body/title/labels:
gh issue edit <N> --title/--body-file/--add-label/--remove-label
- comment:
gh issue comment <N> --body-file <comment.md>
- state:
gh issue close <N> [--comment] / gh issue reopen <N>
- Report the issue URL and what changed.
Anti-patterns
- WRONG:
curl <attachment-url> or WebFetch on github.com/user-attachments/assets/... โ 404. RIGHT: download with Authorization: token $(gh auth token) per fetching.md.
- WRONG: Read a downloaded
.mp4 directly (wastes a turn, shows nothing). RIGHT: extract frames with ffmpeg and Read those.
- WRONG:
gh issue create/edit straight away with a body you never showed. RIGHT: full draft โ user confirmation โ apply.
- WRONG: free-form issue body because the template "doesn't quite fit". RIGHT: pick the closest template and drop sections that are truly N/A.