Create tickets

Read the source plan, spec, issue, or conversation and inspect enough of the repository to avoid fictional boundaries. Use the project's established domain language and preserve relevant architectural decisions.

Prefer narrow vertical slices that deliver observable behavior and can be verified independently. Size work for the actual team and risk rather than a fixed context-window rule. Use horizontal or mechanical slices when the change cannot remain coherent vertically.

Model only real blocking edges. Tickets without blockers form the available frontier and may proceed concurrently. For a broad compatibility migration, consider an expand–migrate–contract sequence so intermediate states remain usable.

Each ticket should communicate:

• the behavior or outcome it delivers;
• concrete acceptance criteria;
• genuine dependencies;
• relevant constraints or source references; and
• scope boundaries when adjacent work is easy to confuse.

Use the ticket format when the destination has no stronger convention. Avoid brittle line numbers and implementation recipes unless the ticket is intentionally mechanical.

Present a draft when granularity or dependencies remain uncertain. Publish or write tickets only when requested and authorized, following the configured tracker's native dependency model. Do not alter a parent item or apply workflow labels unless that action is part of the request.