create-bug-issuelisted

# create-bug-issue File a single `kind:bug` issue capturing **only the symptom** (Zone A). This is deliberately the lightest of the three issue-creation skills — it has no tasks, no acceptance criteria, and no linked branch, because a bug's *spec* is produced later by the read-only analyze step (`workflow-engineer-analyze-bug`), which reproduces the symptom, root-causes it, and posts a `# Bug Analysis` comment for a human to approve. This skill's job is to capture a clean, reproducible symptom so that analyze can do its work. Sibling skills: `create-feature-issues` (decompose a PRD into many slices) and `create-enhancement-issue` (one feature-shaped enhancement). All three set `kind:*` at creation. ## When to activate - The user types `/create-bug-issue`, or phrases like "file / report a bug", "create a bug issue for <x>", "something's broken: <symptom>". Do NOT activate to diagnose or fix a bug (the analyze step + `fix-bug.mjs`, both driven by `/ship`, own that), or to file an enhancement / feature. ## Input The symptom information the user has — error text, screenshots, steps, where it happened. If the request is just "file a bug" with no detail, ask for the essentials (what's broken, how to reproduce, what you expected) before drafting. ## Workflow ### Step 0 — Resolve the repo `gh repo view --json nameWithOwner --jq .nameWithOwner`. If not a GitHub repo, surface and stop. ### Step 1 — Gather the symptom (do not invent) Fill `operation-git/templates/bug-issue.m