Back to Details

piv-slice-epic

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/piv-slice-epic — Slice an Epic into PIV-Sized Tickets

/piv-slice-epic — 将史诗故事（Epic）拆分为PIV规模的工单

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.
这是战略文档与PIV循环之间的桥梁。史诗文档是目标，PIV循环是行动单元，工单则是连接两者的桥梁。
/piv-slice-epic
负责完成拆分工作。

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.
  • $ARGUMENTS
    — 待拆分的史诗故事及其架构决策。输入可以是单个文档或两个文档：
    • 包含
      ## Architecture
      章节的独立架构化史诗文档，或
    • 史诗文档加上关联的独立架构页面（当架构文档与史诗文档分开存放时的常见情况——例如Confluence上的史诗页面及其关联的架构页面，两者均以URL形式传入）。需读取这两个文档。
    • 全新项目场景：可用PRD（产品需求文档）替代史诗文档。 当输入为跟踪工具引用（Confluence/Jira URL或密钥）时，将通过Atlassian MCP从源端获取内容。这是核心输入：架构定义了拆分必须遵循的边界、数据模型和缺失模块。
  • 无需预先初始化。已初始化的会话会有所帮助，但并非必需。如果尚未加载代码库信息，该技能会在拆分前先完成定位（步骤2）。

Process

流程

Step 1 — Read the sources

步骤1 — 读取源文档

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.
完整读取史诗文档（目标、用户故事、验收标准、范围外内容）及其架构决策，无论架构决策是在史诗文档的
## Architecture
章节中，还是在关联的独立页面中（包括实现方案、技术栈、数据模型、缺失模块、探索任务）。如果架构是独立页面，需获取并读取该页面内容。拆分工作必须遵循这些架构决策。

Step 2 — Orient on the code surface (if not already primed)

步骤2 — 定位代码库（若未预先初始化）

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.
拆分工作需要足够的代码库认知，以判断哪些内容是独立的、哪些存在依赖——比如文件重叠、共享边界。如果会话已完成定位，则跳过此步骤。否则自行探索代码库——无需依赖之前的
/prime-codebase
：从架构定义的边界、数据模型和缺失模块入手，读取相关文件/目录（例如适配器接口、编排器、数据摄入管道），了解现有内容、可复用部分以及新代码的部署位置。只需获取足够支撑拆分的信息即可——无需完全重新推导。

Step 3 — Decompose into PIV-sized slices

步骤3 — 分解为PIV规模的工单

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.
将史诗故事拆分为工单。这些工单是为AI设计的，而非传统的人工待办事项——Agent循环处理的内容远多于传统工单：一个中小型的实现阶段，包含约8-10个子任务，通常涉及500-1500行代码变更（其中20-50%为测试代码）。小型史诗故事甚至可以作为单个工单处理。一个规模合适的工单需满足：
  • 是可独立测试的关注点——易于单独进行测试、评审和验证。
  • 是一个连贯的单元——行为的垂直切片，而非水平分层。
  • 拥有清晰的独立验收标准。
  • 规模足够小，确保一个专注的循环可以一次性完成，不会出现上下文丢失——规模过大则会导致Agent失去主线，工作效率下降。
可按依赖关系、关注点或精简端到端切片（先验证完整流程的核心逻辑，再在下一个循环中完善细节）进行拆分——无论采用哪种方式，都要确保每个工单最易于验证。如果一个切片无法在一次完整的测试或评审中完成，则需进一步拆分。无论规模大小，规划的细节度都要保持较高水平——区别仅在于范围。

Step 4 — Slice for parallelizability

步骤4 — 为并行处理进行拆分

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.
梳理工单之间的依赖关系。独立工单——即不涉及相同文件或不依赖其他工单输出的工单——可在并行工作树中运行（参见
/worktree-create
）。标记哪些工单是独立的，哪些构成依赖链。沿垂直切片架构的边界进行拆分可最大化并行性。
按需规划：依赖工单需等待其前置依赖工单完成实现后再启动，而不是仅完成拆分即可——实现前置依赖的过程会为依赖工单的规划提供信息，提前规划依赖工单相当于基于猜测进行规划。独立工单可并行规划和执行；依赖工单则需等待轮到自己时再处理。

Step 5 — Write the ticket breakdown

步骤5 — 编写工单拆分文档

Write the tickets to your tracker (Jira via the Atlassian MCP, Linear, GitHub Issues, Archon's tasks) — or to a local 
docs/tickets/<epic-slug>.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:
undefined
将工单写入你的跟踪工具（通过Atlassian MCP集成Jira，或使用Linear、GitHub Issues、Archon任务）——如果你是独立开发者或没有跟踪工具，也可写入本地
docs/tickets/<epic-slug>.md
文件。无论采用哪种方式，每个工单都需包含自身的上下文信息——这样后续循环处理工单时无需重新读取整个史诗文档：
undefined

Ticket Breakdown — <epic name>

工单拆分 — <史诗名称>

Epic summary — goal in 2-3 lines

史诗摘要 — 用2-3行描述目标

Tickets

工单列表

TICKET-1 — <title>

  • 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 — ...

TICKET-1 — <标题>

  • 范围/验收标准 — 一个可独立测试的关注点
  • 工单上下文：该工单所需的文档章节、指南和边界 （例如："源适配器指南 · 边界：适配器接口 · 史诗验收标准#2 + #4"）
  • 涉及文件（预估）· 大致规模（约500-1500行代码，含测试代码）
  • 依赖：<无 / TICKET-x>

TICKET-2 — ...

Dependency graph

依赖关系图

<text or mermaid graph showing the order + parallel groups>
<文本或Mermaid图，展示执行顺序和并行组>

Suggested execution order

建议执行顺序

Wave 1 (parallel): TICKET-1, TICKET-3 Wave 2: TICKET-2 (after TICKET-1 is implemented)
undefined
第一波（并行）：TICKET-1, TICKET-3 第二波：TICKET-2（在TICKET-1实现完成后）
undefined

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.
跟踪工具中的工单拆分文档（或
docs/tickets/<epic-slug>.md
文件）。每个工单随后将进入各自的PIV循环——如果工单范围定义清晰，可直接进入
/piv-plan-implementation
（会自动初始化所需内容）；如果需要更多代码库定位信息，则先执行
/prime-codebase
。初始化是可选的；上述工单上下文信息已足够支撑后续处理。

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.
  • 问题管理与工具无关：支持Jira（通过Atlassian MCP）、Linear、Notion、GitHub Issues、Archon任务——如果你是独立开发者，甚至可以使用Markdown文件文件夹。工具本身并不重要，目标是将工作拆分到足够细的粒度，确保每个循环都有最大的一次性成功概率，从而实现循环自动化。
  • 全新项目场景：同样的拆分逻辑适用于MVP阶段，而非仅史诗工单。