# Piv Slice Epic > 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. - **Type:** Skill - **Install:** `agentstack add skill-coleam00-skills-piv-slice-epic` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [coleam00](https://agentstack.voostack.com/s/coleam00) - **Installs:** 0 - **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [coleam00](https://github.com/coleam00) - **Source:** https://github.com/coleam00/skills/tree/main/.claude/skills/piv-slice-epic ## Install ```sh agentstack add skill-coleam00-skills-piv-slice-epic ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # /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: ### TICKET-2 — ... ## Dependency graph ## 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/.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. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [coleam00](https://github.com/coleam00) - **Source:** [coleam00/skills](https://github.com/coleam00/skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-coleam00-skills-piv-slice-epic - Seller: https://agentstack.voostack.com/s/coleam00 - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.