---
name: To Tickets
slug: to-tickets-4
category: Automation
description: To Tickets breaks a plan, spec, or conversation into dependency-aware tickets with clear acceptance criteria. Use it when work needs to be sliced for local planning or an issue tracker.
github: "https://github.com/stevesolun/ctx/tree/main/.agents/skills/to-tickets"
language: Python
stars: 578
forks: 71
install: "npx degit https://github.com/stevesolun/ctx/tree/main/.agents/skills/to-tickets ~/.claude/skills/to-tickets"
installs_to: ~/.claude/skills/to-tickets
source_path: .agents/skills/to-tickets/SKILL.md
collection_size: 25
category_size: 1523
collection_url: "https://dirskills.com/collections/stevesolun/ctx"
added: 2026-08-25T05:14:05.211Z
last_synced: 2026-08-25T05:14:05.211Z
canonical_url: "https://dirskills.com/skills/to-tickets-4"
---

# To Tickets

To Tickets breaks a plan, spec, or conversation into dependency-aware tickets with clear acceptance criteria. Use it when work needs to be sliced for local planning or an issue tracker.

**Install:**

```bash
npx degit https://github.com/stevesolun/ctx/tree/main/.agents/skills/to-tickets ~/.claude/skills/to-tickets
```

## README

# Create tickets

Read the source plan, spec, issue, or conversation and inspect enough of the
repository to avoid fictional boundaries. Use the project's established domain
language and preserve relevant architectural decisions.

Prefer narrow vertical slices that deliver observable behavior and can be
verified independently. Size work for the actual team and risk rather than a
fixed context-window rule. Use horizontal or mechanical slices when the change
cannot remain coherent vertically.

Model only real blocking edges. Tickets without blockers form the available
frontier and may proceed concurrently. For a broad compatibility migration,
consider an expand–migrate–contract sequence so intermediate states remain
usable.

Each ticket should communicate:

- the behavior or outcome it delivers;
- concrete acceptance criteria;
- genuine dependencies;
- relevant constraints or source references; and
- scope boundaries when adjacent work is easy to confuse.

Use the [ticket format](TICKET-FORMAT.md) when the destination has no stronger
convention. Avoid brittle line numbers and implementation recipes unless the
ticket is intentionally mechanical.

Present a draft when granularity or dependencies remain uncertain. Publish or
write tickets only when requested and authorized, following the configured
tracker's native dependency model. Do not alter a parent item or apply workflow
labels unless that action is part of the request.