| name | issues |
| description | Check GitHub issues and tickets for the current repo. List open issues, view details, filter by label, or search. Use when the user asks about issues, tickets, bugs, or backlog. |
/issues - Check GitHub Issues
Check open issues and tickets for the current repo using the GitHub CLI.
Usage
/issues — list all open issues
/issues <number> — view a specific issue by number
/issues <label> — filter by label (e.g., bug, security, enhancement)
/issues closed — show recently closed issues
/issues search <query> — search issues by keyword
Instructions
Step 1: Detect the repo
Use the git remote to determine the owner/repo:
gh repo view --json nameWithOwner -q '.nameWithOwner'
If this fails, tell the user they're not in a GitHub repo.
Step 2: Run the appropriate query
List open issues (default):
gh issue list --repo <owner/repo> --state open
View a specific issue:
gh issue view <number> --repo <owner/repo>
Filter by label:
gh issue list --repo <owner/repo> --state open --label "<label>"
Show recently closed:
gh issue list --repo <owner/repo> --state closed --limit 10
Search by keyword:
gh issue list --repo <owner/repo> --state open --search "<query>"
Step 3: Present results
For issue lists: Group by label and show a compact summary:
**Bugs (2):**
- #1 — Task status tags never flip from pending to running
- #2 — mDNS flaky
**Enhancements (1):**
- #3 — Phase 5: Sensitivity classification
If an issue has no labels, group it under Other.
For single issue view: Show title, status, labels, body, and any comments. If the issue references code, note the relevant files.
Step 4: Offer next steps
After presenting, briefly suggest relevant actions:
- "Want me to look into any of these?"
- "Want me to close this with a comment?" (if viewing a resolved issue)
- "Want me to create a new issue?" (if listing and something is missing)
Don't be verbose about it — one line is enough.
Key Rules
- Always use
--repo — don't assume gh will infer correctly from the working directory in all cases.
- Group by label — the default list should be scannable, not a wall of text.
- Link to the project board — if issues mention a GitHub Project, note it.
- Keep it brief — the list view is the default. Only expand when viewing a single issue.