git-issuelisted

Draft a clean, well-structured issue as markdown text for a code-hosting tracker (GitHub, GitLab, Jira, or similar). Use this whenever the user wants to file, write, open, or draft an issue, bug report, feature request, ticket, or task — including phrasings like "make an issue for this", "write up a bug report", "turn this into a ticket", "I need to file something for the flaky test", or when they paste an error/stack trace/PR discussion and ask for it to become an issue. Also use it when they hand you loose notes, a Slack thread, or a chat log and want a properly formatted issue out of it. Produces markdown ready to paste into the tracker's issue field, and after drafting asks whether to actually post/create the issue — posting it directly if a GitHub/GitLab connector or authenticated CLI is available, otherwise handing over a ready-to-run command.
rdlugs/ai-skills · ★ 0 · Code & Development · score 60

Install: claude install-skill rdlugs/ai-skills

# git-issue Turn a rough problem, request, or pile of notes into a clean issue that a maintainer can triage in seconds and act on without a follow-up round of questions. The output is **markdown text** the user pastes into their tracker — you are not running `gh`, `glab`, or any API. ## The mental model A good issue answers three questions fast: *what's wrong or wanted*, *how do I reproduce or understand it*, and *how do I know when it's done*. Everything below serves that. A maintainer skimming twenty issues should grasp yours from the title alone and know the next step from the body. Padding, ceremony, and restating the obvious all work against that, so keep it tight. ## Workflow 1. **Classify the issue.** Read what the user gave you and pick the type — bug, feature/enhancement, task/chore, docs, or question. If it's genuinely ambiguous, make your best guess and note it rather than stalling to ask; the user can correct a draft faster than they can answer an interview. 2. **Pull out what you already have.** Error text, stack traces, versions, repro steps, file paths, PR/commit links, the desired behavior — harvest these from whatever the user pasted. Don't make the user re-supply things that are already on screen. 3. **Flag real gaps, don't invent.** If a bug is missing its reproduction steps or a feature is missing its motivation, leave a short `> _TODO: ..._` marker in that spot rather than fabricating plausible-sounding details. A fabricated repro step is worse than