# To Tickets > Use when the user explicitly asks to turn an approved specification, plan, or settled contract into agent-sized implementation tickets with requirement coverage and blocking edges. Drafts first; publishes only with separate authority. - Skill: `saikaaco/to-tickets` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add saikaaco/to-tickets` - Raw SKILL.md: https://api.skillmd.com/api/skills/saikaaco/to-tickets/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - License: MIT - Author: SaikaAco (https://skillmd.com/u/saikaaco) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/saikaaco/to-tickets --- # Traceable To-Tickets ## Lineage This is an MIT-licensed Hermes adaptation of Matt Pocock's public [`to-tickets`](https://github.com/mattpocock/skills/tree/main/skills/engineering/to-tickets). The complete upstream notice is preserved in [`references/third-party-notices.md`](references/third-party-notices.md). Compile one exact, user-accepted source snapshot into an agent-sized delivery graph. Initial invocation authorizes a chat draft only. `DRAFT_READY` means an honest reviewable draft exists; it does not mean grounding is complete or authorize publication or implementation. Pending pre-publication grounding, graph rechecks, or fresh approval may coexist with `DRAFT_READY` when accepted facts already determine the safe draft shape. Use `BLOCKED` when missing facts prevent an honest draft or materially change its graph, sizing, sequencing, or safety. For decision-only decomposition, do not block merely because later implementation details remain unknown. ## Source and grounding Accept one exact source snapshot with identifiable scope, owner, requirements, decision/evidence handles, constraints, negatives/exceptions, out-of-scope boundaries, observable acceptance, and required evidence. Do not infer acceptance or current truth from an old conversation, a similarly named file, or mere draft existence. Keep `source_snapshot` exactly equal to the accepted version, revision, fingerprint, or message handle. Put drift history or missing-revision explanations in `lineage`, `blockers`, or a separate drift field; never append those explanations to the snapshot value. Before slicing, inspect only current repository and record evidence needed to validate implementation-facing claims: active project/tracker policy, governing decisions and vocabulary, relevant interfaces, seams, behavior and tests, plus source negatives, exceptions, and acceptance methods. Prior exploration does not validate a specific claim. A direction to reuse an unnamed “existing seam” does not itself verify that seam. Verify every claim that determines ticket size, blocker edges, blast radius, or acceptance. For an actual ticket bundle, do not claim `DRAFT_READY` or grounding passed when unavailable evidence would require route-changing guesswork. Never invent a seam, cohort, owner, dependency, acceptance boundary, or implementation fact. Exact files belong to later Plan work, but uncertainty that changes graph, sizing, sequencing, coverage, or safety blocks drafting. Name the missing evidence and required regeneration checks rather than emitting placeholder tickets. ## Compile the graph ### Ordinary work Prefer narrow **vertical slices**. Each ticket must: - deliver one observable end-to-end behavior across every required layer; - fit one fresh implementation context and leave the repository green; - own source-derived positive and negative acceptance plus evidence across every applicable behavior class: validation/failure, authorization, retry and idempotency, atomicity and rollback, audit, confidentiality/metadata, and temporal or compatibility transitions; - preserve source semantics exactly: never strengthen, relax, or redefine an exception, grace period, compatibility window, security boundary, or non-goal; - be independently demonstrable, with no hidden half-feature or follow-up needed to satisfy the behavior it claims; - preserve atomic requirements together: do not split required audit, security, idempotency, rollback, or failure behavior from the operation whose safe completion depends on it. For each applicable behavior, make cross-effects explicit: - authorization failure, expiry, revocation, or a nonexistent handle causes no protected mutation, no success audit, and no protected metadata or secret disclosure unless the source explicitly permits an effect; - same-key retry duplicates none of the source-required persisted effects, including primary records, audit records, events, or handles; - temporal and grace behavior is verified before, during, at the boundary, and after transition without redefining the source contract. Split large work by independently usable behavior, not schema/API/UI or other horizontal layers. A separate infrastructure or preparation ticket is allowed only when independently verifiable and a genuine blocker. Preserve unrelated parallelism; never add edges for review order or convenience. ### Wide migrations When the source establishes a wide mechanical change, use **expand → independently green migration batches → contract**: 1. add a backward-compatible expansion and mixed-version contract evidence; 2. migrate explicitly bounded, owned, independently testable cohorts in parallel where safe; 3. remove the old contract only after every cohort is verified migrated. If intermediate batches cannot be independently green, name the integration boundary and add final integration verification instead of claiming each batch is releasable. Missing cohort membership, ownership, transition semantics, conflict behavior, or contraction evidence that changes sizing or safety is `BLOCKED`, not a placeholder ticket. ### Coverage and graph checks Use stable draft IDs and only real blockers. Reject missing, self, or cyclic edges and compute the true frontier. `frontier` is stage-specific: a `DRAFT_READY` bundle may show structural start nodes for review but creates no implementation authority; `BLOCKED` and `RECONCILE_REQUIRED` bundles always use `frontier: []`. Never expose a blocked, unknown-body, or reconciliation-pending ticket as actionable. Cycle-check completeness concerns the intended ticket-ID/blocker-edge set, not ticket bodies, acceptance, or source mappings. If all intended IDs and edges are known, run the check even when grounding or coverage remains blocked. If that ID/edge set is unavailable or incomplete, set `cycle_check: not_run`; never claim `passed` for an unaudited graph. Prove both directions: every current requirement/constraint maps to tickets or an explicit owner-accepted disposition, and every ticket maps to source requirements, decisions/evidence, and acceptance. Omission, orphan scope, silent expansion, or self-accepted disposition is `BLOCKED`. ## Canonical schemas Every ticket uses this contract: ```yaml id: status: DRAFT | READY | BLOCKED | PUBLISHED parent: source_snapshot: owner: source_requirements: [] source_decisions_evidence: [] blocked_by: [] delivers: acceptance_criteria: [] verification_evidence: [] constraints: [] exclusions: [] authorization: ``` The bundle uses this contract: ```yaml schema: to-tickets-bundle-v1 state: DRAFT_READY | PUBLISHED | BLOCKED | RECONCILE_REQUIRED source: source_snapshot: source_owner: lineage: ticket graph> tickets: [] frontier: [] coverage: requirement_to_tickets: ticket_to_source: dispositions: uncovered_requirements: [] orphan_tickets: [] cycle_check: passed | failed | not_run grounding_status: passed | blocked publication: backend: none | local | tracker approval_binding: none | persistence: none | partial | confirmed published_handles: [] readback_verified: false ``` Additional presentation fields are allowed, but these meanings and types must not be silently replaced by an ad-hoc schema. ## Authority, drift, and recovery - Publication requires later approval bound to the exact reviewed graph and one named backend. A configured tracker, old access, source approval, draft request, or generic “go ahead” is not publication authority. - Graph approval and backend authorization are separate. Naming or approving a backend does not invalidate approval of an unchanged graph; source or graph changes do. - `RECONCILE_REQUIRED` preserves the exact approval binding for an unchanged graph. Uncertain, partial, or unverified persistence alone never clears that graph approval. - An approved ticket ID whose source mapping is temporarily unavailable remains approved-but-unresolved, not an orphan. Keep `orphan_tickets: []` unless evidence proves a ticket lacks source authority; represent unknown mappings as blocked or unknown coverage instead. - Source drift invalidates coverage and approval. Graph mutation requires affected grounding, bidirectional coverage, cycle/frontier checks, and new exact publication approval. - Create blockers first where handles are needed, then bodies and real edges; read back bodies, edges, labels, and handles before claiming `PUBLISHED` or applying `ready-for-agent` to verified approved child tickets. - On uncertain or partial writes, preserve known handles, search stable idempotency keys before retry, never recreate blindly, and return `RECONCILE_REQUIRED` until reconciled. - Never plan implementation, dispatch agents, create Kanban, implement, commit, deploy, complete tickets, or modify/close/label the parent specification. A ticket graph never creates implementation authority. - A request for exact files, code, tests, or commands for one existing ticket routes to Plan, not To-Tickets.