🥮 skills.mooncakes.ioexperimental

to-tickets

// Break the current conversation, a plan, specification, issue, or document into dependency-aware tracer-bullet tickets and publish them to a configured tracker or local Markdown fallback. Use when the user asks to split work into tickets, issues, vertical slices, implementation increments, or agent-sized tasks.

moon runwasm

moon runwasm Yoorkin/to-tickets@0.1.0

$ files

SKILL.md

readonly

To Tickets

Turn the source plan into tickets that deliver narrow, complete, verifiable behavior. Represent prerequisite relationships explicitly so agents can work the unblocked frontier safely.

Do not publish until the user approves the proposed breakdown.

Gather context

Start from the current conversation.
If the user provides a spec path, issue number, URL, or other reference, fetch and read its full body, comments, and relevant linked decisions.
Inspect the codebase when needed to understand existing architecture, testing seams, domain vocabulary, and likely prefactoring.
Use canonical terms from the project's glossary and respect applicable ADRs.
Determine the configured tracker and triage vocabulary. If no real tracker is configured, use the local Markdown fallback described below.

Draft tracer-bullet slices

Each ordinary ticket must:

cut a narrow but complete path through every relevant layer, such as schema, API, UI, and tests;
produce behavior that can be demonstrated or verified independently;
fit within one fresh agent context window;
state acceptance criteria in observable terms;
avoid becoming a horizontal “backend,” “frontend,” “tests,” or “docs” ticket.

Look for prefactoring that makes the change easy before making the easy change. Put genuinely enabling prefactors first and make later tickets depend on them; do not disguise feature work as endless cleanup.

Model blocking edges

For every ticket, identify only the tickets that genuinely gate its start. A ticket with no blockers belongs to the initial frontier.

Keep dependency edges acyclic.
Do not serialize independent tickets merely for convenience.
Order publication blockers-first so references can use stable identifiers.
The execution frontier is the set of open tickets whose blockers are complete.

Handle wide refactors

A wide refactor is a mechanical change whose blast radius makes an independently green vertical slice impossible, such as renaming a shared column or retyping a widely used symbol.

Use expand-contract instead of forcing it into a tracer bullet:

Expand: add the new form beside the old while keeping behavior green.
Migrate: move call sites in batches sized by blast radius; every batch is blocked by Expand.
Contract: remove the old form only after every migration batch completes.
If migration batches cannot remain green independently, use a shared integration branch and add a final integrate-and-verify ticket. State clearly that green is promised only at that point.

Use this exception narrowly; most feature work should remain vertical.

Obtain approval

Present the draft as a numbered list. For each ticket show:

Title
Blocked by
What it delivers
Acceptance criteria

Ask the user whether:

granularity is too coarse or too fine;
blocking edges reflect real prerequisites;
any tickets should be merged, split, reordered, or made parallel.

Revise until the user explicitly approves.

Publish

Real tracker

Create one issue per approved ticket in dependency order. Use native blocking or sub-issue relationships when supported; otherwise write explicit issue references under Blocked by. Apply the configured equivalent of ready-for-agent when it exists. Never invent labels without checking.

If the source is a parent issue, reference it but do not close or otherwise modify it unless the user separately requests that change.

Use this issue body:

## Parent

<Parent reference when one exists; otherwise omit this section.>

## What to build

<The end-to-end behavior this ticket makes work from the user's perspective.>

## Acceptance criteria

- [ ] <Observable criterion>
- [ ] <Observable criterion>

## Blocked by

- <Blocking issue reference, or “None (can start immediately)”.>

Local Markdown fallback

Write one file per ticket under:

.scratch/<feature-slug>/issues/<NN>-<slug>.md

Number from 01 in dependency order. Never combine all tickets into one file. Use:

# <NN>: <Ticket title>

**What to build:** <The end-to-end behavior this ticket makes work.>

**Blocked by:** <Numbers and titles, or “None (can start immediately)”.>

**Status:** ready-for-agent

- [ ] <Observable acceptance criterion>
- [ ] <Observable acceptance criterion>

Content constraints

Describe behavior, not layer-by-layer implementation chores.
Avoid ordinary file paths and code snippets because they become stale.
Include a short prototype excerpt only when it captures a settled decision more precisely than prose; label and trim it.
Do not duplicate the entire source spec in every ticket. Link or reference the source.

Finish

Return the created issue URLs or local file paths, summarize the dependency frontier, and identify which tickets can start immediately.

Origin

This is a self-contained adaptation of Matt Pocock's to-tickets tracer-bullet and expand-contract workflow with tracker-independent publication rules.

$ cat moon.mod

Author