ticket-writer

Lead with a one-sentence business outcome, then describe the problem with real data, list constraints, and write 3-7 testable acceptance criteria. Avoid prescribing solutions or listing files to change — the ticket defines what and why, not how.

Write each criterion as a declarative rule from the user's perspective that is yes/no checkable, illustrated with one concrete example. Replace vague phrases like "works correctly" with concrete thresholds, status codes, and payload shapes.

A bug report needs deterministic numbered reproduction steps, expected versus actual behavior, environment details (version, SHA, timestamps, entity IDs), evidence like logs or traces, and acceptance criteria including a regression test.

Yes, the ticket structure is tracker-agnostic and works with Jira, Linear, GitHub Issues, Shortcut, and Asana. Output defaults to Markdown and adapts syntax to the named tracker while keeping the structure identical.

Use a spike when the work is a time-boxed investigation whose output is knowledge or a decision, not code. Spikes name the question being answered, set a hard time cap, and define done as a recommendation document rather than a behavior change.

Requester-supplied estimates anchor the team and erode trust, since estimates belong to the people doing the work. The ticket should leave the estimate blank until the team weighs in at Ready time.