How do I install the To Tickets skill?

Run npx skillmds@latest add jesse-merhi/to-tickets in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the To Tickets skill do?

Turn a plan or spec into tracer-bullet Obsidian tickets with blockers and logical PR groups. It is listed under Coding & Dev Tools on SkillMD.

Is To Tickets safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: makes network calls. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with To Tickets?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is To Tickets free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published To Tickets?

jesse-merhi (@jesse-merhi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

To Tickets by jesse-merhi — Agent Skill

Name: To Tickets
Rating: 4.2 (5 reviews)
Author: jesse-merhi

File contents

To tickets

Break a plan, spec, or conversation into a set of tickets: tracer-bullet vertical slices, each declaring the tickets that block it. Publish tickets to Obsidian Issues/.

Workflow

Gather context from whatever is already in the conversation. If the user passes a spec path or Obsidian note, fetch it and read the full body.
Explore the codebase if needed. Ticket titles and descriptions should use the project's glossary vocabulary and respect ADRs or Obsidian decisions in the area you are touching.
Look for opportunities to prefactor the code to make implementation easier: make the change easy, then make the easy change.
Draft tracer-bullet tickets using ticket-design.md. Give each ticket its blocking edges. A ticket with no blockers can start immediately.
Derive PR delivery groups from the ticket graph using ticket-design.md. Preserve an approved spec shape unless the detailed blocker graph disproves it. Load gh-stack for a strict dependency chain of two or more review groups. Keep independent graph paths as standalone PRs or separate stacks.
Mark each ticket AFK or HITL.
Present the proposed breakdown as a numbered list. For each ticket, show: title, blocked by, mode, PR group/delivery, what it delivers, covered acceptance criteria, and any frontend validation state/viewport.
Ask the user whether the granularity, blocking edges, and PR grouping feel right, and whether any tickets or review groups should be merged or split.
Iterate until the user approves both the ticket graph and PR delivery map.
Publish the approved tickets to Obsidian Issues/ using note-template.md and naming.md. If write access is missing, return the Markdown bodies and proposed paths.
Do not close or modify any parent spec unless the user explicitly asks.

Context pointers

Use ticket-design.md for tracer-bullet rules, wide refactors, and blocker checks.
Use execution-contract.md for the ordered todo contract.
Use note-template.md for the ticket note body.
Use naming.md for vault-relative note paths.

---name: to-ticketsdescription: Turn a plan or spec into tracer-bullet Obsidian tickets with blockers and logical PR groups.---# To ticketsBreak a plan, spec, or conversation into a set of tickets: tracer-bulletvertical slices, each declaring the tickets that block it. Publish tickets toObsidian `Issues/`.## Workflow1. Gather context from whatever is already in the conversation. If the user passes a spec path or Obsidian note, fetch it and read the full body.2. Explore the codebase if needed. Ticket titles and descriptions should use the project's glossary vocabulary and respect ADRs or Obsidian decisions in the area you are touching.3. Look for opportunities to prefactor the code to make implementation easier: make the change easy, then make the easy change.4. Draft tracer-bullet tickets using [ticket-design.md](references/ticket-design.md). Give each ticket its blocking edges. A ticket with no blockers can start immediately.5. Derive PR delivery groups from the ticket graph using [ticket-design.md](references/ticket-design.md). Preserve an approved spec shape unless the detailed blocker graph disproves it. Load `gh-stack` for a strict dependency chain of two or more review groups. Keep independent graph paths as standalone PRs or separate stacks.6. Mark each ticket `AFK` or `HITL`.7. Present the proposed breakdown as a numbered list. For each ticket, show: title, blocked by, mode, PR group/delivery, what it delivers, covered acceptance criteria, and any frontend validation state/viewport.8. Ask the user whether the granularity, blocking edges, and PR grouping feel right, and whether any tickets or review groups should be merged or split.9. Iterate until the user approves both the ticket graph and PR delivery map.10. Publish the approved tickets to Obsidian `Issues/` using [note-template.md](references/note-template.md) and [naming.md](references/naming.md). If write access is missing, return the Markdown bodies and proposed paths.11. Do not close or modify any parent spec unless the user explicitly asks.## Context pointers- Use [ticket-design.md](references/ticket-design.md) for tracer-bullet rules, wide refactors, and blocker checks.- Use [execution-contract.md](references/execution-contract.md) for the ordered todo contract.- Use [note-template.md](references/note-template.md) for the ticket note body.- Use [naming.md](references/naming.md) for vault-relative note paths.

Frequently asked questions

To Tickets