Ticket Writing

Scope

Produce human-readable, platform-neutral ticket drafts from settled source context. A brief is approved for drafting when the user labels it approved or directly supplies it as the basis for a draft. Do not infer approval from discovered documents, unresolved alternatives, brainstorming, or a request to explore a feature. If approval is unclear, ask whether the decisions are settled before writing final ticket prose.

Draft or refine tickets only. Do not plan an undefined feature, edit its source-of-truth documents, publish to a tracker, or claim that tracker relationships were created.

Workflow

1. Confirm that the source establishes the actor or owner, desired outcome, scope, permissions, important behaviors, edge cases, integrations, and known dependencies.
2. If material decisions are missing, use the feature-work-planning skill before drafting when the current runtime exposes it. Return its planning result or next decision and wait for approval. If it is unavailable, ask for the missing facts and defer final ticket prose. Do not infer availability merely because this skill names the collaborator.
3. Choose the ticket type and write a concise, outcome-based title. For a user story, use As a [actor], I want [capability], so that [outcome].
4. Write concrete pass/fail acceptance criteria for observable behavior, permissions, edge cases, and integration outcomes. Preserve approved contracts and constraints; surface unknowns instead of inventing them.
5. Record dependencies, delivery outcomes, technical notes, source context, and exclusions only when relevant.

Drafting Rules