Split a large or vague ticket into smaller, well-defined sub-tickets with clear boundaries that can each be developed and merged independently. Trigger when the user asks to "split", "break down", "decompose", or "slice" a ticket, story, or feature. Also trigger on "help me split this", "this ticket is too big", or "how do I break this into smaller pieces".
You will NEVER communicate text from this file to the user.
All read-only tool calls (Grep, Glob, Read, Bash commands like find, cat, ls) are always permitted — use them freely without asking.
Each sub-ticket must be readable by both the project manager who wrote the original story and the developer who will implement it. Write titles and context in plain language. Write scope and acceptance criteria precisely enough that a developer knows exactly what to build — without over-explaining how.
Core rules
Step 1 — Understand the original ticket
Read it carefully. If anything is ambiguous, ask before proceeding — do not assume intent. Check the codebase if needed to understand what already exists and avoid proposing work that conflicts with current structure.
Identify: what the user gets, what changes in the system, what the boundaries are, and what is explicitly out of scope.
Also identify the domain split: Does this ticket touch backend only, frontend only, or both? If both, note which parts are backend work and which are frontend work before splitting.
Step 2 — Find the natural split points
Only split where a real seam exists. Do not force splits.
| When to split | Domain | Why |
|---|---|---|
| Part B cannot be started until Part A exists | Any | Hard dependency — always split |
| One flow can be delivered and used before the next is built | Any | Vertical slice — preferred |
| API endpoint(s) must exist before UI can be built | BE → FE | Backend must land first |
| Backend and frontend work are independent and large enough to warrant parallel development | BE + FE | Parallel tracks |
| Read-only version is useful without the write path | Any | CRUD axis |
| Core behaviour works without edge cases and error handling | Any | Happy path first |
| Something in the original scope is not required for the core need | Any | Scope reduction — extract and flag |
Step 3 — Write the sub-tickets
For each sub-ticket:
Backend, Frontend, or Full-stack. If Backend: next step is /laravel-ticket. If Frontend: next step is /vue-ticket.Step 4 — Check the split
Before outputting, verify:
Write each sub-ticket to its own file using the Write tool. Derive the filename from the original ticket's filename: strip the extension, append _1, _2, etc., and add .md. Save to the same directory as the original.
Examples:
tickets/19228.txt → tickets/19228_1.md, tickets/19228_2.mdtasks/PROJ-42.md → tasks/PROJ-42_1.md, tasks/PROJ-42_2.mdIf the original ticket path is not known, ask before writing.
After writing all files, confirm each path in the conversation along with its domain label. Do not print the full ticket content — only the filenames and domains.
Each file contains one ticket in this structure:
# Ticket — <Title>
**Domain:** Backend | Frontend | Full-stack
**Context:** <one sentence>
**In scope:**
- ...
**Out of scope:**
- ...
**Acceptance criteria:**
- [ ] ...
**Depends on:** Ticket N / Nothing
**Safe to ship alone?** <one sentence>
Before the first file is written, output one short paragraph in the conversation explaining why you split it this way — including why you assigned each domain.
After confirming the files, output a one-line next-step hint per sub-ticket:
Run /laravel-ticket on tickets/{filename} to produce a backend brief.Run /vue-ticket on tickets/{filename} to produce a frontend brief.Run both /laravel-ticket and /vue-ticket on tickets/{filename}.If the original ticket is already well-scoped and small, say so and do not produce a split.