open-ticketlisted

# Open Ticket Turn a user's rough idea into one ticket in the project's tracker. You interpret the raw input, compose a title and a body, confirm both with the user, and file the ticket. What makes this worth a deliberate operation is the body. A ticket filed here is written so that whoever later opens a thread from it can take the body as the thread's genesis narrative unchanged, instead of mining intent out of a half-specification. You write nothing to disk. The ticket in the tracker and the URL you report are the whole result; `docs/adr/` and `docs/glossary.md` are read here and never written. ## Inputs Gather the following before composing; the composition below works from what you gather here. - `docs/adr/`, read via `/consult-adrs` — the project decisions bearing on the idea. - `docs/glossary.md`, read via `/consult-glossary` — the project's fixed terms, to be used in everything you write. - The repository's convention files, found and read as `<skill_path>/references/repository-conventions.md` directs. A convention can decide the title's shape, and a title composed without it has to be rewritten. - The tracker reference matching the host of the project's git remote — for a `github.com` remote that is `<skill_path>/references/trackers/github.md`; follow it for that tracker. When the checkout has several remotes and the target repository is genuinely ambiguous, ask which one is meant; never pick one by order or by name. The idea itself comes with t