yds-gh-issue-drafterlisted

# GitHub Issue Drafter ## Overview The quality of everything downstream — the plan, the reviews, the implementation, the CI verification — is capped by the quality of the Issue that starts it. A rough, one-line Issue forces every later step to guess at the author's intent. This skill takes the user's rough intent (the *What*) and, without slowing them down, proposes the three things a hand-written Issue almost always omits: a machine-checkable **Done definition**, an explicit **Out of scope**, and optional **Design constraints**. The user approves or edits the proposal, then the skill creates a structured GitHub Issue tagged with a marker that `yds-gh-issue-planner` recognizes. **Scope boundary:** this skill only drafts and files the Issue. It does not investigate code, propose a response plan, or implement anything. Hand off to `yds-gh-issue-planner` once the Issue exists. ## When NOT to expand If the user's input already contains a clear Done definition and scope (e.g. they pasted a fully-formed Issue, or a `yds-report-to-issues` output), do not re-interrogate them — just confirm and file. The goal is to fill gaps, not to add ceremony to Issues that are already well-formed. ## Workflow ### Step 1: Capture the rough intent Take the user's input as the raw *What*. Do **not** ask them to rewrite it or expand it themselves — capturing intent cheaply is the whole point. If the input is a single line, that is fine. If repository context is unclear, establish it: ```bas