to-tickets

Decompose an approved spec into ordered, sized tickets with dependencies and agent-ready briefs.

15|3|Updated Jul 9, 2026
One-click install
npx skills add https://github.com/kiurakku/cursor-kit-for-ai --skill to-tickets-kiurakku
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: to-tickets
Source: https://github.com/kiurakku/cursor-kit-for-ai/tree/main/plugins/engineering/skills/to-tickets
Command: npx skills add https://github.com/kiurakku/cursor-kit-for-ai --skill to-tickets-kiurakku

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Turning an approved specification into actionable work is error-prone: tickets end up oversized, dependencies are missed, and agents or developers start blocked because briefs lack scope, API shapes, or verification steps. This Skill converts a spec into an ordered backlog of right-sized tickets that can be executed sequentially without re-reading the entire spec. ## Core Features & Use Cases - Ticket decomposition with sizing: Splits a spec into vertical slices sized S/M/L, with a mandatory split plan for any L ticket touching unrelated subsystems. - Dependency mapping and ordering: Enforces the schema → domain → API → UI ordering rule, detects circular dependencies, and produces an execution-order table with labels. - Agent-ready briefs: Generates a self-contained markdown block per ticket covering objective, spec references, scope, test seams, verification commands, and definition of done. - Use Case: After approving a coupons feature spec, run this Skill to produce tickets T-101 (migration), T-102 (API), T-103 (UI) with dependencies, labels like migration and agent-ready, and paste-ready issue bodies. ## Quick Start Break the approved coupons spec into ordered, sized tickets with dependencies and agent-ready briefs for each one.

Frequently Asked Questions about to-tickets

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I break a feature spec into tickets?▼

Identify vertical slices aligned to acceptance criteria, map dependencies (data model before API, API before UI), then size each ticket S, M, or L. Output an ordered backlog table plus a self-contained brief per ticket with scope and verification steps.

How to split a large ticket that is too big for one PR?▼

Split by sub-criteria for large acceptance criteria, by layer (migration, API, UI) for full-stack features, or by feature flag for staged rollouts. Any L-sized ticket touching unrelated subsystems requires a mandatory split plan.

What should an agent-ready ticket brief include?▼

An agent-ready brief includes a one-sentence objective, spec references with acceptance criteria IDs, in/out scope boundaries, implementation notes, proposed test seams, verification commands, and a definition of done checklist.

How do I handle dependencies between tickets?▼

Follow the ordering rule: schema/migration, then domain logic, then API, then client/UI, then docs. A ticket must never depend on a later ticket; circular dependencies are resolved by merging tickets or inserting a spike.

When should I not split a large ticket?▼

Avoid splitting when a single atomic deploy is genuinely required, such as a risky cross-service migration that cannot ship in parts. Document the reasoning explicitly when keeping an L-sized ticket intact.