write-ticketlisted

# Write Ticket A ticket is the guardrail around an outcome. It says what must be true when the work is done and which decisions are too expensive to get wrong, and it leaves the implementation to whoever picks it up. | Deliverable | Skill | |----------------------------------------------------|----------------| | A ticket in the tracker | `write-ticket` | | An implementation or decomposition plan outside it | `write-plan` | Both can be warranted for one piece of work. The ticket carries the outcome, the plan carries the sequencing. ## Process 1. Determine the type: story, bug, task, or investigation 2. Read the matching reference and follow its panel structure and field rules exactly, without borrowing another type's structure 3. Apply the [shared principles](#shared-principles) regardless of type, in preference to how existing tickets in the tracker happen to be written 4. Check the draft against the type's field rules and the shared principles before finishing ## Shared principles ### Outcome-focused, not implementation Keep in the ticket: - The desired outcome, in terms of what success looks like - Business rules and edge cases that define correctness - Decisions that are expensive to reverse later, and the architectural constraints they impose - Which components or entry points are in play - Test scenarios, expressed as outcomes Leave out anything that could change without changin