--- name: piv-slice-epic description: Slice an epic (with its architecture decisions) into PIV-sized tickets with a dependency graph, then create them in your tracker (Jira via the Atlassian MCP, or GitHub/Linear/local). Accepts the epic and its architecture as one doc or as an epic plus a separate linked architecture page. Turns a large strategic doc into the discrete units of work that the PIV loop consumes. argument-hint: "[epic + its linked architecture page (paths or Confluence/Jira URLs); a PRD for greenfield]" --- # /piv-slice-epic — Slice an Epic into PIV-Sized Tickets The bridge between a strategic doc and the PIV loop. The epic doc is the destination; the PIV loop is the unit of motion; **tickets are the bridge.** `/piv-slice-epic` does the slicing. ## Input - `$ARGUMENTS` — the **epic** to slice **and its architecture decisions**. These arrive as **one doc or two**: - a single architected epic that carries its own `## Architecture` section, **or** - an **epic plus a separate, linked architecture page** (the common case when the architecture lives beside the epic — e.g. a Confluence epic page and its linked architecture page, both passed as URLs). **Read both.** - greenfield: a PRD stands in for the epic. When the inputs are tracker references (Confluence/Jira URLs or keys), fetch them from the source via the Atlassian MCP. **This is the load-bearing input:** the architecture names the seams, data model, and missing pieces the slices must respect. - **Not prime-dependent.** A primed session helps, but isn't required. If the codebase surface isn't loaded, this skill orients itself (Step 2) before slicing. ## Process ### Step 1 — Read the sources Read the epic fully (goal, user stories, acceptance criteria, out-of-scope) **and its architecture decisions, whether they are an `## Architecture` section on the epic or a separate linked page** (the approach, stack, data model, missing pieces, spikes). If the architecture is a separate page, fetch and read it too. The slicing has to respect those calls. ### Step 2 — Orient on the code surface (if not already primed) Slicing needs enough codebase awareness to judge what's independent vs dependent — file overlap, shared seams. If the session is already oriented, skip this. Otherwise **explore it yourself — don't depend on a prior `/prime-codebase`**: starting from the architecture's named seams, data model, and missing pieces, read the relevant files/dirs (e.g. the adapter interface, the orchestrator, the ingestion pipeline) to see what exists, what's reused, and where new code lands. Just enough to slice confidently — not a full re-derivation. ### Step 3 — Decompose into PIV-sized slices Break the epic into tickets. **Scope these for AI, not for a human backlog** — an agent loop carries far more than a traditional ticket: a small-to-medium implementation *phase*, ~8–10 subtasks, often **500–1500 lines of change (20–50% tests)**. A small epic might even be a single ticket. A well-sized ticket: - Is **one testable concern** — easy to **test, review, and prove** on its own. - Is one coherent unit — a vertical slice of behavior, not a horizontal layer. - Has clear acceptance criteria of its own. - Is small enough that **one focused loop can one-shot it without context rot** — not so large the agent loses the thread and returns diminish. Split by **dependency**, by **concern**, or as a **slim end-to-end slice** (prove the whole flow thinly, then fatten it next loop) — whatever makes each ticket easiest to prove. If a slice is too big to test or review in one honest pass, split it further. The *planning detail* stays high regardless — it's the *scope* that's larger. ### Step 4 — Slice for parallelizability Map dependencies between tickets. **Independent tickets** — ones that don't touch the same files or rely on each other's output — can run in **parallel worktrees** (see `/worktree-create`). Mark which tickets are independent and which form a dependency chain. Slicing along vertical-slice-architecture seams maximizes independence. **Plan just-in-time:** a dependent ticket waits until its dependency is *implemented*, not just sliced — building the dependency informs the dependent's plan, so planning it early plans against a guess. Independent tickets can be planned and run in parallel; dependent ones wait their turn. ### Step 5 — Write the ticket breakdown Write the tickets to your tracker (Jira via the Atlassian MCP, Linear, GitHub Issues, Archon's tasks) — or to a local `docs/tickets/.md` if you're solo or have no tracker. Either way, **every ticket carries its own context** — that's what lets a loop pick it up later without re-reading the whole epic: ``` # Ticket Breakdown — ## Epic summary — goal in 2-3 lines ## Tickets ### TICKET-1 — - Scope / acceptance criteria — one testable concern - Per-ticket context: the doc sections, guides, and seams this ticket needs (e.g. "source-adapter guide · seam: adapter interface · AC #2 + #4 from the epic") - Files touched (estimate) · rough size (~500–1500 lines, incl. tests) - Depends on: <none / TICKET-x> ### TICKET-2 — ... ## Dependency graph <text or mermaid graph showing the order + parallel groups> ## Suggested execution order Wave 1 (parallel): TICKET-1, TICKET-3 Wave 2: TICKET-2 (after TICKET-1 is implemented) ``` ## Output A ticket breakdown in your tracker (or `docs/tickets/<epic-slug>.md`). Each ticket then enters its own PIV loop — straight to `/piv-plan-implementation` if it's well-scoped (it primes what it needs), or `/prime-codebase` first if it needs more codebase orientation. **Priming is optional**; the per-ticket context above is what makes that possible. ## Notes - Issue management is **tool-agnostic**: Jira (via Atlassian MCP), Linear, Notion, GitHub Issues, Archon's tasks — or just a folder of markdown files if you're solo. The tracker doesn't matter; the goal is to **split the work just enough that each loop has the highest chance of one-shot success, so you can automate the loop.** - Greenfield: the same slicing applies to MVP phases instead of epic tickets.