| name | issue |
| description | GitHub issue management with multi-account support. Creates, lists, views, and closes issues with correct labels and conventions per project. Use when user says "create issue", "file bug", "issue for X", "list issues", "open issues", "triage", or "close issue".
|
GitHub Issue Management
Manage GitHub issues across multiple accounts. Always use GitHub Issues, never
ISSUES.md files.
Step 1: Detect Project and Switch Account
Determine which project from context (cwd, user mention). If ambiguous, ask.
| Project | Account alias | Repo |
|---|
| project-a | gh-project-a | auto-detect from cwd |
| project-b | gh-project-b | org/repo-name |
| personal | gh-personal | auto-detect from cwd |
Check current account first:
gh auth status
Switch to correct account before any gh command.
Step 2: Execute the Right Command
Create Issue
gh issue create --title "..." --label "LABELS" --body "BODY"
For projects with strict labeling: ALWAYS include required labels.
Ask the user for priority if not provided.
For repos you're not in the directory of:
gh issue create --repo org/repo-name --title "..." --body "..."
List Issues
gh issue list --state open
gh issue list --label "P0" --state open
gh issue list --label "P0,frontend" --state open
View Issue
gh issue view 123
Close Issue
Always close with a comment explaining the resolution:
gh issue close 123 --comment "Fixed in commit abc123. Verified on live site."
Label Conventions
Example: Priority + Area labeling
| Type | Labels |
|---|
| Priority | P0 (critical), P1 (high), P2 (medium), P3 (low) |
| Area | frontend, backend, pipeline |
Always include one from each group. If user doesn't specify priority, ask.
Issue Body Format
For bug reports:
**Steps to reproduce:**
1.
2.
**Expected:**
**Actual:**
**Context:** [URL, env, user account if relevant]
For feature requests:
**Problem:**
**Proposed solution:**
**Acceptance criteria:**
- [ ]
Keep bodies concise. No filler. Facts only.
Rules
- NEVER use ISSUES.md files. GitHub Issues only.
- ALWAYS verify the active account matches the project before any write operation.
- When closing an issue: ALWAYS include a comment with the fix reference.
- If the project cannot be determined from context, ask before proceeding.
