| name | cuga-github-issues |
| description | Create GitHub issues for cuga-agent (bugs, features, epics, designs, and related work) against origin using gh, with epic → feature → issue hierarchy and GraphQL sub-issue linking. Use when the user says create new issues, report a bug, file a bug, feature request, new feature, create an epic, GitHub issue, sub-issue, or parent epic. |
CUGA GitHub issues
File issues against origin upstream with gh. Read companions as needed:
Shared rules
- Use upstream
origin (not a fork-only default). Pass --repo owner/name when needed.
- Run
gh label list for that repo. Only use label names that exist. Never invent labels.
- No promotional footers (“Made with Cursor”, etc.).
- Hierarchy depth is only: Epic → Feature → Issue. Never nest under a leaf issue. Never Feature → Feature. Never deeper than three levels.
- When parented: put
Part of #<number>. at the top of the body, create the issue, then link with GraphQL addSubIssue. Body text alone is not enough. Verify parent afterward.
- Do not use unsupported
gh issue edit --set-parent.
Detect intent
If unclear, ask once which kind they want.
Hierarchy placement
Find epics
List open epics (type: epic and titles with [Epic] / [EPIC]). See github_commands.md.
Find features under an epic
List sub-issues of the candidate epic; prefer children whose titles start with [Feature] (or other feature-family prefixes) when attaching a leaf.
Match rules
- 0 matches: Tell the user none fit. Ask them to name an existing parent or create one first. Do not invent a parent.
- 1 clear match: Confirm number + title, then proceed.
- 2+ matches: Present
#N — title with one-line why each might fit. Do not pick for the user.
Create epic
- No parent search.
- Title:
[Epic] … (or [Epic]: … if matching existing style in the repo).
- Labels: include
type: epic plus other applicable existing labels.
- Prefer REST create with
type=Epic (see companion).
- Body: summary of the workstream and what child features will cover. Use feature-request sections where useful (templates.md).
Create feature-family
Non-bug work that is not itself an epic ([Feature], [Design], [Refactor], [Performance], [Security], [Docs], [Test], [Chore], [Question], …).
- Parent Epic is required. Do not create with no parent.
- Confirm epic via placement rules above.
- Labels: always
--label needs-triage plus other applicable existing labels (e.g. enhancement).
- Title prefix from the table in templates.md.
- Body sections from
feature_request.yml (templates.md).
- Create,
addSubIssue under the epic, verify.
Create leaf under feature
Use when the user wants a sub-issue of an existing feature (bug/chore/task scoped to that feature).
- Resolve parent Feature (must already be under an Epic — depth stays ≤ 3).
- If the feature has no epic parent, stop and fix hierarchy with the user before filing.
- Body/labels/title per bug or feature-family templates as appropriate.
- Create,
addSubIssue under the Feature, verify.
Create bug
- Labels:
--label bug plus other applicable existing labels (template also uses needs-triage when present in the repo).
- Title prefix:
[Bug]: …
- Body sections from
bug_report.yml (templates.md).
- Placement:
- Small self-contained bug (narrow repro, no design change, not part of a larger workstream): may proceed without a parent. Say so explicitly when filing.
- Otherwise: search for a fitting Feature under an Epic, then for a fitting Epic.
- If a Feature fits: confirm, parent under that Feature.
- If no Feature fits (non-trivial bug): ask the user to choose:
- Attach under an existing or new Feature (under an Epic)
- Attach directly under an Epic (depth 2)
- File with no parent (state that in the issue)
- Do not invent a Feature. Do not auto-pick among 2+ candidates.
- Create, link if parented, verify.
Done checklist
