Split a Spec Into Demoable Tickets

What it does

The workflow reads the specification and comments alongside project vocabulary and architecture decisions. It favors tracer-bullet slices that demonstrate useful behavior across layers, rather than isolated database, API and UI chores. Necessary prefactoring comes first. A wide mechanical migration may instead need expand-and-contract batches and a final integration step. The user reviews the breakdown before tracker publication. The parent specification remains intact while child tickets become independently actionable.

When to use it

• Turn an approved feature into work that fits separate agent sessions.
• Make dependencies visible before several tickets are implemented.
• Plan a mechanical migration whose intermediate states need careful integration.

Step-by-step workflow

1. Read the full spec, discussion, glossary and relevant architecture decisions.
2. Find small demoable vertical slices and prerequisite prefactoring.
3. Write self-contained tickets with acceptance behavior and genuine blockers.
4. Review the breakdown with the user before publishing.
5. Create local ticket files or authorized tracker issues, then wire actual dependency links.

Example request

Use to-tickets on our agreed invoice-import specification. Make each ordinary ticket demonstrate an end-to-end behavior, including rejection of malformed rows and duplicate handling. Identify required prefactoring and real blockers. Explain any slice that cannot remain green until integration. Prepare a local breakdown for review first; preserve the parent spec and do not publish issues yet.

Worked example

A first slice could import one valid row through the public entry point and display its result. A later duplicate-handling slice can build on that behavior; a UI ticket should not depend on an arbitrary file-layout decision. If moving every consumer to a new importer interface is a mechanical migration, expand-and-contract batches may be clearer than pretending each batch is a complete feature. Dependencies should reference created ticket identities rather than placeholder numbers that could link to unrelated issues.

What you get

A reviewed ticket breakdown with acceptance behavior, blockers and the configured tracker representation.

How to evaluate the result

• Check slices demonstrate behavior rather than only technical layers.
• Verify blockers express real prerequisites and contain no placeholder IDs.
• Confirm every ticket preserves the spec’s exclusions and test decisions.

What you need

An agreed spec with comments, project decisions and tracker conventions. Local output uses one file per ticket under the feature’s scratch issues directory.

Setup and activation

The publisher documents plugin setup for Claude Code, Codex and Copilot, and manual Agent Skills setup for Gemini CLI and other clients. Choose one distribution method per client to avoid duplicate skills. The engineering collection expects project-specific tracker, triage-label and document-location settings from setup-matt-pocock-skills. Keep referenced companion skills and files available. This catalogue review does not install or run them; scan the exact source before any later installation. Client tools, permissions and subagent support still need separate validation.

Limits and considerations

Ticket creation is a publishing action when using an external tracker. The source requires breakdown approval and preserves the parent issue. Avoid speculative implementation file paths that become stale before work starts.

Related workflows

• Use to-spec before splitting unsettled conversations.
• Use implement for one ready ticket or implement-spec for orchestration.

License and reuse

MIT at repository level (Copyright 2026 Matt Pocock). Preserve the copyright and permission notice when redistributing substantial source material; inspect any separately licensed dependencies or assets.

Further reading

• Reviewed SKILL.md (immutable commit)
• Publisher README: setup and compatibility
• Reviewed MIT license