report-tusk-issuelisted

# Report Tusk Issue Skill File a well-formed GitHub issue against the **tusk repo itself** without leaving the workflow. Use this whenever the user (or you) notice a tusk bug, CLI limitation, skill rough-edge, or missing feature mid-session — i.e. a gap in tusk, not in the user's own project. > Don't use this skill for issues against the *consumer* project's code — those go through whatever issue tracker that project uses. This skill is hard-wired to file against the tusk distribution's repo (`gioe/tusk`). This skill complements `/retro`'s LR-2 routing — retro still files tusk-issues at end-of-task. This skill is the fast path for noticing a gap *outside* a retro, or during a long task where waiting for retro would lose fidelity. ## Step 1: Gather Inputs from the User Invoked with an optional one-liner (e.g. `/report-tusk-issue tusk lint rule 14 trips on multi-line skip-lint comments`) or no argument. Prompt the user for the standard `tusk report-issue` fields. Pre-fill from any one-liner argument, but always confirm before drafting: 1. **Title** (required) — short, imperative. If the user passed a one-liner, treat it as the proposed title and confirm: > Use this as the title? `<one-liner>` (**yes** / edit) 2. **Behavior observed** (required) — what happened, including any error message or unexpected output. Verbatim from the user; don't paraphrase. 3. **Steps to reproduce** (optional) — numbered steps. If the user can't supply them (e.g. it's a UX gap rather than a bu