to-tickets

Original：🇺🇸 English
Translated

Break a plan, spec, or the current conversation into tracer-bullet tickets with blocking edges, published to the project tracker. Use when splitting approved work into issues.

60installs
Sourcefrankify-app/skills
Added on

NPX Install

npx skill4agent add frankify-app/skills to-tickets

Tags

Translated version includes tags in frontmatter
project-trackingticket-managementwork-splittingspec-reproducibilityissue-workflow

SKILL.md Content

View Translation Comparison →

To Tickets

Break plan/spec/conversation into tickets — tracer-bullet vertical slices, each declaring tickets that block it. Publish per consumer repo's tracker conventions (AGENTS.md).

Reproducibility invariant

Full issue set, replayed in dependency order — features and bugfixes alike — must build roughly same application, regardless of who or what implements.
Issue stream = buildable spec. Every rule below serves this.

Self-containedness

Every outcome-shaping decision lives in issue itself, or durable docs it references — ADRs (
writing-adrs
), glossary terms (
docs/glossary/
). Never conversation context, tribal knowledge, implementer discretion.
Litmus test: two independent implementers could build meaningfully different things → ticket underspecified. Add decision to ticket, or record as ADR/glossary term + reference.

Bugfixes = spec corrections

Never patch instruction ("change Y to X in file Z"). State correction to spec stream:
  • Issue N implied X; implementation did Y; X correct. — or
  • Issue N specified Y; Y wrong; X′ now correct.
Replay then builds X directly, not bug + patch. Bugfix reveals spec-level decision → ADR + reference from issue.

Reconciliation on completion

Ticket not finished until it reflects what was built. Before close: fold deviations, mid-session scope, decisions back into issue (or its ADR/glossary refs). Else replay builds first draft, not final state. 
documenting-decisions
after-task step performs this.

Grilling gate

Tickets are load-bearing. No grilling session (
docs/glossary/grilling-session.md
) in context → stop, ask user: "No grilling session found — really skip?" Proceed only on explicit confirmation; note skip in parent issue/PR.

Process

1. Gather context

Work from conversation context. User passes reference (spec path, issue number/URL) → fetch, read full body + comments.

2. Explore codebase (optional)

Understand current code state. Titles/descriptions use glossary vocabulary (
uvx disambiguate <term>
); respect ADRs in touched area.
Look for prefactoring opportunities. "Make the change easy, then make the easy change."

3. Draft vertical slices

Break work into tracer bullet tickets:
  • Each slice: narrow but COMPLETE path through every layer (schema, API, UI, tests) — vertical, NOT horizontal slice of one layer
  • Completed slice demoable/verifiable alone
  • Sized to one fresh context window
  • Prefactoring first
Each ticket declares blocking edges — tickets that must complete first. No blockers → start immediately.
Apply litmus test to every draft: drafting decisions (interfaces, naming, sequencing trade-offs) go into ticket body, ADR, or glossary term — mark per 
documenting-decisions
.
Wide refactors: exception to vertical slicing. One mechanical change (rename column, retype shared symbol), blast radius spans codebase — single edit breaks thousands of call sites, no slice lands green. Sequence as expand–contract. Expand: new form beside old, nothing breaks. Migrate: call sites in batches sized by blast radius (per package/directory), each batch own ticket blocked by expand — CI stays green, old form still exists. Contract: delete old form once no caller remains, blocked by every batch. Batches can't stay green alone → keep sequence, share integration branch, all block final integrate-and-verify ticket — green promised only there.

4. Quiz user

Numbered list. Per ticket:
  • Title: short name
  • Blocked by: gating tickets, if any
  • What it delivers: end-to-end behaviour made to work
Ask:
  • Granularity right? (too coarse/fine)
  • Blocking edges correct — only genuine gates?
  • Merge or split any?
  • Any ticket failing litmus test — decision still only in conversation?
Iterate until approved.

5. Publish

One issue per ticket, dependency order (blockers first) → edges reference real issue numbers. Native blocking relation where tracker has one, else "Blocked by" section. Apply 
ready-for-agent
label unless told otherwise — tickets agent-grabbable by construction.
Work the frontier: any ticket with all blockers done. Linear chain → top to bottom.
Do NOT close/modify parent issue.
Issue template:
markdown
## Parent

Reference to parent issue (omit if source wasn't an issue).

## What to build

End-to-end behaviour, user's perspective — not layer-by-layer implementation.

## Decisions

Every outcome-shaping decision, stated or referenced (ADR/glossary). Bugfix: spec-correction statement. Omit only if genuinely none.

## Acceptance criteria

- [ ] Criterion 1
- [ ] Criterion 2

## Blocked by

- Reference per blocking ticket, or "None — can start immediately".
Ticket prose: as short as possible, caveman mode preferred (
caveman
skill) — precision and understandability must not suffer.
No file paths/code snippets — stale fast. Exception: prototype snippet encoding a decision more precisely than prose (state machine, reducer, schema, type shape) → inline, note prototype origin, trim to decision-rich parts.
Work frontier one ticket at a time, clearing context between tickets.