ticket-breakdown

Provide the capability area and change slug; the Skill reads the change brief, specification, constraints, dependency map, and technical design, then writes one TICKET-NNN.md per ticket plus a backlog.md with ordering and a summary table.

At minimum it needs a change brief and a specification with numbered REQ and NFR IDs. Constraints, dependency map, and technical design are optional; if missing, the gap is noted in the backlog's Source Context and breakdown proceeds.

Acceptance criteria must be observable and verifiable, not aspirational. For example, 'search returns results ranked by relevance score, highest first' is testable, while 'search works well' is not. NFRs must name their verification method.

Yes. Re-running loads the existing ticket directory, keeps all IDs append-only, adds new tickets above the current maximum, marks obsolete undelivered tickets as Withdrawn, and regenerates backlog.md. Delivered ticket files are never rewritten.

The Depends On field resolves ticket IDs only within the same change and area directory. A qualified reference to another area's ticket is misread as a local ticket number. Express cross-area predecessors through the dependency map's DEP- ID and Prior Art instead.

Do not use it to implement a ticket (that is delivery) or to order whole capability areas against each other (that is dependency mapping). It also cannot run without an approved specification and an open change brief.