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](../../../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](../../../docs/authoring/github-issues.md) — title shape, the Situation section, the type labels. - [github-issues-bug-report.md](../../../docs/authoring/github-issues-bug-report.md) - [github-issues-feature-request.md](../../../docs/authoring/github-issues-feature-request.md) - [github-issues-task-spec.md](../../../docs/authoring/github-issues-task-spec.md) Prose in the title and body follows [docs/authoring/WRITING.md](../../../docs/authoring/WRITING.md). Situation uses the terms in [docs/concepts/](../../../docs/concepts/index.md), 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...