work-itemlisted

# Work Item Draft a work item using the shape that already dominates well-formed real tickets: bold-text section headers (not markdown `##`), a framing section chosen by the ticket's nature, and acceptance criteria written as testable, observable outcomes rather than vague statements like "works correctly." The same standard applies whether you're drafting a new ticket from scratch or fixing up an existing one that's missing a piece (most often acceptance criteria) — treat both as the same content problem. This skill defines content only — it has no opinion on which tracker or tool creates or updates the ticket. Tool selection (a Jira MCP tool, `gh issue create`, an Azure DevOps or Linear API, etc.) is a runtime decision made at the point of creation, based on whatever is connected in the current session. If invoked via `/work-item`, treat `$ARGUMENTS` as a one-line description of the work; ask follow-up questions to fill any gaps. If triggered by conversation, use the context already established rather than re-asking for things already said. ## Execution steps 1. Determine the work's nature: is it reporting a defect (something broken) or describing new/changed work? This decides the framing section — see `assets/work-item-template.md`. 2. Determine whether it's a standalone item or a child of a larger parent item — see "Applies to" below for the test. This decides whether Acceptance criteria is mandatory. 3. Draft the content following `assets/work-item-template.md`. Re