gh-issue

/gh-issue — file a groomed GitHub issue

Arguments: $ARGUMENTS

Parse them as:

• The first token (or quoted phrase) is the breadcrumb — a UI path (Settings > Billing > Invoice row), a route (/dashboard), a component or object name, or a file path.
• Optional model:<tier> and effort:<level> tokens may appear anywhere in the arguments. Strip them out before reading the rest. Valid tiers/levels come from the gh-issue-labels skill's taxonomy (model: sonnet | opus | fable; effort: low | medium | high | max, adjusted to the project's bound model lineup). An unrecognized value is a typo — warn the operator and file without that label rather than inventing one.
• Everything else is the description of the problem as the operator experienced it.

Example: /gh-issue "Settings > Billing > Invoice row" clicking an invoice opens a 404 model:opus effort:high

The gh-issue-filing skill is the protocol — issue anatomy, labels, duplicate etiquette all come from it. This command is the entry point; consult the skill before drafting. (Tracking work in Jira instead? Use /jira-issue.)

Steps

1. Recon the breadcrumb. Resolve it to real code: search the repo for the component/route/object it names and capture the concrete file:line pointers the skill's evidence section requires. Verify every pointer by reading it before citing — stale references are worse than none. If the breadcrumb matches multiple candidates, cite the strongest and list the runners-up in the issue body so the implementer doesn't re-derive them.

2. Check for duplicates per the skill's etiquette: search open issues for the key terms from the breadcrumb and description. If a live duplicate exists, enrich it with a comment (your recon evidence) instead of forking a new issue, and report that outcome instead. If the operator passed model:/effort:, apply those labels to the duplicate — that instruction stands regardless of which issue carries the work.

3. Draft the issue using the skill's groomed anatomy: title per the project's convention, Symptom (from the operator's description, verbatim where possible), verified file:line evidence (from step 1), Desired behavior, independently-testable Acceptance criteria, and the traceability hint if the project binds one. Infer priority from user impact and state the reasoning in one line of the body — do not stop to ask. Write the Symptom and Desired-behavior prose naturally and run the body through the humanizer skill before filing — the issue is a story a human reads; keep the verified file:line evidence and the acceptance-criteria checklist exactly as captured.