Draft To Ticket

What A Good Ticket Should Contain

A backlog-ready ticket should usually include:

• Title
• Summary
• Why
• Scope
• Acceptance Criteria
• Definition Of Done
• Notes or assumptions when useful

Rewriting Rules

• Prefer implementation-oriented language over brainstorming language.
• Replace “improve”, “fix”, or “support” by itself with a precise outcome.
• Reference real files, routes, modules, workflows, or UI surfaces when they can be identified safely.
• State why the work matters, not just what to change.
• Keep one coherent unit of work per ticket.
• Preserve numbering or ordering hints from the original draft when they matter.
• Do not invent large new product requirements that are not implied by the draft.

Splitting Guidance

Split the draft into multiple tickets when:

• it mixes foundation work and feature work
• it spans several subsystems with weak coupling
• it has no clear acceptance boundary
• it would likely produce a large unreviewable change
• it contains multiple independent outcomes

When splitting:

• keep the tickets dependency-aware
• put enabling architecture work first
• make each child ticket independently actionable
• preserve traceability back to the source draft

Ticket Quality Bar

Before finishing, check that the rewritten ticket:

• has a specific title
• describes the problem in concrete terms
• names the likely scope of work
• has acceptance criteria that can be checked
• has a definition of done that matches the intended outcome
• is small enough to execute safely in one pass, or is explicitly split

Output Style

For filesystem-backed backlogd tickets, prefer sections like:

• ## Summary
• ## Why
• ## Scope
• ## Acceptance Criteria
• ## Definition Of Done
• ## Notes

If the user wants the ticket written to disk, place it in the appropriate drafts/ or backlog/ folder and match the repository's existing numbering and formatting.