# To Tickets > Explicitly turn one settled source into the smallest useful dependency-ordered implementation ticket graph and publish it to the configured tracker. Return one bounded item to Implement without creating a graph. - Skill: `stevennitesh/to-tickets-2` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add stevennitesh/to-tickets-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/stevennitesh/to-tickets-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: stevennitesh (https://skillmd.com/u/stevennitesh) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/stevennitesh/to-tickets-2 --- # To Tickets Create one implementation graph for work that genuinely benefits from several durable tickets. Preserve settled decisions, design the delivery boundaries, and publish safely. ## Admit Accept one identified settled source, including a verified parent specification, settled conversation or packet, or verified audit candidate. Read its decision-bearing pointers. If an implementation-shaping decision, acceptance fact, or authority is missing or contradictory, return the exact gap and owner without changing tracker state. If the settled source itself establishes one bounded outcome and proof path with no durable dependency, authority, or ownership handoff, return the exact item and recommend `$implement`. Create nothing. Once a graph is warranted, read `docs/agents/issue-tracker.md` and `docs/agents/triage-labels.md`. Require configured inspect and read-back routes before examining existing state; leave mutation routes and authority for publication. For an explicit repair, inspect the existing graph and repair only verified graph facts while the source remains settled. A caller with campaign claims retains them throughout repair. Foreign, ambiguous, or partially owned state returns the observed conflict without mutation. ## Trace Read the repository instructions and only the domain, engineering, and current code needed to preserve the source and find useful delivery boundaries. Trace the current behavior owner, representative callers, accepted interfaces, and nearest credible proof. Do not make a missing product or architecture decision. Use the trace to shape one coherent repository-native graph. If slicing still depends on one bounded consequential implementation-architecture choice within the settled source, return that question, relevant evidence, and re-entry condition, and recommend unstarted `$codebase-design`. Re-enter only with the original source plus an accepted result that preserves its commitments; otherwise return to the source owner. Continue directly to Slice when no such choice remains. Inspect the intended parent and existing children before drafting. Reuse only one exact semantic graph, including its relationships and readiness. Refetch and accept such a graph unchanged; skip Slice, Approve, and Publish, then use the common return selection. Create only from verified absence. Divergent, duplicate, or unknown state requires explicit repair authority or an exact conflict return. ## Slice Create the fewest cohesive tickets that each deliver one meaningful, independently checkable outcome in one bounded fresh `$implement` run. Prefer vertical behavior slices when they make the delivery clearer, but do not force every layer into every ticket. Use a technical stage only when a real dependency, migration, compatibility, atomicity, rollback, authority, or ownership boundary makes separate completion useful. A preparatory ticket must name what it unlocks and have its own proof. When early feedback on a named risk changes how later work should proceed, use the first ticket as a tracer bullet through the real path. Name the observable signal and the later work it informs. Otherwise omit the learning role. Account once for every source commitment that changes delivery. Give each one an owning ticket. Repeat only its source-named distinguishing acceptance in a consuming ticket whose change can independently violate it. Each ticket contains only what a fresh implementer must not have to invent: - one outcome and observable acceptance; - the source identity, fixed decisions, scope, and consequential non-goals; - true blockers, or `none`; - material compatibility, migration, trust, authority, or recovery constraints. A source pointer does not replace ticket acceptance. Carry the source-named semantic input, observable result, and distinguishing case into its owning ticket. When a plausible wrong rule can satisfy the ordinary happy case, use the smallest case where their results differ. Do not replace a named field, state, issue scope, time meaning, placement, source identity, or evidence qualifier with a broader category. When independently selected inputs can interfere, include the smallest mixed case that proves their required isolation. For responsive placement or time conversion, name the governing rule, observation boundary, semantic input, and observable result. Preserve a source calendar date without inventing an instant conversion. When a consuming ticket accepts a predecessor owned by another ticket, make that producer a blocker. Acceptance passes the actual predecessor result, or the persisted form actually produced from it, through the lowest ordinary caller. If the result can succeed or be rejected, exercise both states and each public transformation that could discard a source-named meaning, including evidence, issues, availability, or identity. If the graph splits an introduced or materially changed caller-visible path, designate the earliest dependency-complete consuming ticket as its representative vertical slice. A named risk may also give that slice the tracer-bullet learning role. When the source distinguishes deterministic fixture proof from a production-shaped, live, or measured claim, the owning ticket preserves the required evidence class, its safe-input or preserved-artifact condition, and any accepted residual gap. When accepted behavior depends on several stopping criteria, include the smallest case where they disagree and name the criterion that controls the result. A deployment or installation ticket names the exact managed target and target-specific read-back; general command success does not prove that target changed. Add stable repository or proof pointers only when they materially narrow the work or preserve a settled decision. Do not freeze live file lists, commands, test ownership, implementation technique, or worker-return fields into every ticket. State each fact once and omit inapplicable sections. Add a blocking edge only when the dependent consumes a required predecessor outcome. Ordering preference, possible file overlap, and live serialization are not blockers. A new graph must be non-empty and acyclic, cover the settled source without duplication, and expose at least one unblocked agent ticket. A required human-only permission or decision is not an agent ticket; if it gates any ticket, return that exact prerequisite instead of publishing agent-ready work. `$parallel-implement` owns live concurrency and integration. ## Approve Present the exact numbered titles and bodies, parent, order, blockers, readiness changes, and each item's existing identity plus `reuse` or `create` or `update` disposition. Ask whether to publish that exact graph. After a material revision, present the revised graph for approval. Skip the checkpoint only when the user already approved these exact effects or explicitly waived preview, then freeze them. ## Publish Require every configured mutation route needed by the frozen effects, including item update, create, relationship, and readiness routes as applicable, plus authority for those exact effects. If setup is missing or incompatible, leave state unchanged, recommend `$repo-bootstrap`, and stop. Immediately before the first mutation, refetch the parent and children; any drift from the approved preflight returns a conflict without mutation. Publish through the configured tracker in blocker-first order. Create planned missing items non-ready and bind each new identity through immediate read-back. Give each child the source's settled category role when one exists. Otherwise use `bug` only for a settled defect and `enhancement` for planned new or changed behavior. Non-ready means no readiness state role; do not misuse `needs-triage` or `needs-info` for a known dependency. During repair, reuse an unchanged active item only when its claim remains with the caller; mutate none of its body, readiness, or claim. Before updating any other existing item, remove `ready-for-agent` and `ready-for-human` and read that state back, preserve any caller-held assignee, then apply and read back its approved title and body changes. Attach and verify parent and blocking relationships. After every title, body, and relationship matches the approved graph, apply and read back `ready-for-agent` only for approved agent tickets whose blockers are resolved. Leave blocked tickets without a readiness role, then refetch the graph and derive its actionable frontier. Use only the configured relationship mutation and read-back route. On the first failed, partial, or indeterminate effect, stop further mutation, refetch the affected graph, report what is observed and the safest configured recovery, and never retry an uncertain create blindly. Return the verified ordered ticket pointers, blocking edges, first actionable or caller-held resumable ticket, remaining uncertainty that does not invalidate the source or readiness, and one unstarted recommendation. For a repair with retained caller claims, return the resumable work to that caller. Otherwise, recommend `$parallel-implement` only when the user explicitly requested delivery of the whole parent graph; recommend `$implement` with the first actionable ticket. Invoke neither. Complete when the skill returns either the unchanged bounded item, an exact source, setup, conflict, or recovery result supported by observed state, or an approved or exact-reuse graph in which every delivery-changing commitment has an owner and each ticket that can violate one carries its source-named trigger, distinguishing acceptance, actual predecessor and evidence boundary when applicable, whose bodies, relationships, readiness, managed-target effects, and actionable frontier were read back, with no implementation started.