File Issue

File an issue

Goal end-state: one issue on the tracker whose type, title, body sections, and labels follow docs/authoring/github-issues.md and the rulebook of its type, with every required section filled from evidence.

The description arrives as the skill argument or in the conversation: $ARGUMENTS

The authoring docs own the issue format, and a rule there wins over any wording here. Read the shared rules first, then the rulebook of the type chosen in step 1:

• github-issues.md — title shape, the Situation section, the type labels.
• github-issues-bug-report.md
• github-issues-feature-request.md
• github-issues-task-spec.md

Prose in the title and body follows docs/authoring/WRITING.md. Situation uses the terms in docs/concepts/, and a term links to its entry on first use with a full https://github.com/<owner>/<repo>/blob/main/docs/concepts/<file>.md#<anchor> URL, because a relative link does not resolve inside an issue body.

1. Classify

Decide the type with the two questions from github-issues.md, in order:

1. Does the system break its own intended behavior? → bug report.
2. Is the change already decided and scoped? → task spec.
3. Otherwise → feature request. A pain point with no feature attached, and a feature idea, both file as a feature request.

When the description supports two readings that change the type — a symptom the user may or may not consider intended behavior, or a change the user may or may not have decided — ask which one holds. Carry the question into step 3 rather than asking it alone.

2. Gather

Fill the required sections of the chosen type from three sources, in this order: the description, the tracker, the code. When step 1 left two readings open, gather what both readings need, so the answer in step 3 picks a draft rather than a second gather.

1. Resolve the repo with gh repo view --json nameWithOwner. The concept URLs in Situation need the owner and repo name.
2. Search the tracker with gh issue list --search "<keywords>" --state all. If an open issue already tracks the same defect, gap, or change, report it and stop. If a closed one covers it, link it from the body.
3. Read the code and the docs that the description touches. For a bug report, reproduce the symptom when the steps are cheap, and gather the evidence Initial triage and Suspected root cause need. For a feature request, find the PRs, incidents, or threads where the gap bit, because Pain carries evidence. For a task spec, read the files Scope names, and decide for each Acceptance item whether a committed test or a one-time check proves it.
4. For a bug report, pick one of P0, P1, P2, P3 from the label descriptions in gh label list.
5. For a task spec, find the issues it depends on and record them as a Blocked by line by number.

Step 3 answers what the code can answer. A question goes to the user only for what the description, the tracker, and the code leave open.

3. Ask

Collect every open question from steps 1 and 2 and ask them in one round, with one AskUserQuestion call. A question earns a slot when a required section cannot be written without the answer, or when the answer changes the type. Every question offers the readings the evidence supports as options, with the most likely one first.

Questions that earn a slot:

• the type, when step 1 left two readings open.
• what the user expected to happen, when the bug rulebook's Symptom needs it and the description states only what happened.
• who pays the pain and where it bit, when the feature rulebook's Pain has no evidence to point to.
• what stays out, when the task rulebook's Scope has no boundary.
• the priority of a bug, when the evidence supports two labels.

Skip the round when no question earns a slot. Ask a second round only when an answer opens a gap the first round could not foresee.