piv-slice-epic

/piv-slice-epic — 将史诗拆分为适合 PIV 的工单

连接战略文档与 PIV 循环的桥梁。史诗文档是目的地；PIV 循环是行动单位；工单就是桥梁。 /piv-slice-epic 负责拆分。

输入

• $ARGUMENTS — 要拆分的史诗及其架构决策。输入可以是一份或两份文档：
  • 一份包含自身 ## Architecture 部分、已完成架构设计的史诗，或
  • 史诗加单独的关联架构页面（常见情况是架构与史诗并列存放——例如 Confluence 史诗页面及其关联的架构页面，两者都以 URL 形式提供）。两者都要读取。
  • 全新项目：用 PRD 代替史诗。 如果输入是跟踪工具引用（Confluence/Jira URL 或键），请通过 Atlassian MCP 从源获取。**这是最关键的输入：**架构会指出拆分必须遵循的边界、数据模型和缺失部分。
• 不依赖预先初始化。 已预先初始化的会话会更有帮助，但并非必需。如果尚未加载代码库概况，此技能会在拆分前自行了解代码库（步骤 2）。

流程

步骤 1 — 阅读源文档

完整阅读史诗（目标、用户故事、验收标准、范围之外的内容）及其架构决策，无论它们是史诗中的 ## Architecture 部分，还是单独的关联页面（方案、技术栈、数据模型、缺失部分、技术调研）。如果架构在单独的页面中，也要获取并阅读。拆分必须遵循这些决策。

步骤 2 — 了解代码现状（如果尚未预先初始化）

拆分时需要充分了解代码库，才能判断哪些部分相互独立、哪些存在依赖——例如文件重叠和共享边界。如果会话已经了解代码库，可跳过此步。否则，请自行探索——不要依赖之前执行过 /prime-codebase：从架构中提到的边界、数据模型和缺失部分着手，阅读相关文件或目录（例如适配器接口、编排器、数据导入管线），了解现有内容、复用部分以及新代码的落点。只需了解足以自信拆分的程度——无需从头全面梳理。

步骤 3 — 拆解为适合 PIV 的切片

将史诗拆分为工单。工单要按 AI 的需求界定范围，而不是按人工待办列表的方式——一个 Agent 循环能承载的内容远超传统工单：一个小到中型实现阶段，约 8–10 个子任务，通常涉及 500–1500 行改动（其中 20–50% 为测试）。小型史诗甚至可以只有一张工单。一张大小合适的工单：

• 只涉及一个可测试的问题——易于单独测试、评审和验证。
• 是一个连贯的单元——行为的垂直切片，而不是水平分层。
• 有明确的验收标准。
• 范围足够小，能让一个专注的循环一次完成，避免上下文退化——不能大到让 Agent 理不清脉络、收益递减。

按依赖关系、关注点或精简的端到端切片拆分（先以精简方式验证整个流程，再在下一循环中扩展）——选择最容易验证每张工单的方式。如果某个切片无法在一次扎实的检查中完成测试或评审，就继续拆分。无论范围大小，规划细节都应保持充分——变大的是范围。

步骤 4 — 拆分时考虑并行执行

梳理工单之间的依赖关系。相互独立的工单——不会修改相同文件，也不依赖彼此产出的工单——可以在并行工作树中执行（见 /worktree-create）。标明哪些工单相互独立，哪些构成依赖链。沿垂直切片架构的边界拆分，能最大限度地提高独立性。

**按需规划：**依赖工单应等到其依赖项实现完成后再规划，而不只是等到拆分完成——实现依赖项的过程会为后续工单的规划提供信息，因此过早规划只会基于猜测。独立工单可以并行规划和执行；有依赖关系的工单则应按顺序等待。

Step 5 — 编写工单拆分

将工单写入你的跟踪工具（通过 Atlassian MCP 使用 Jira、Linear、GitHub Issues、Archon 的任务），或者在你独自开发或没有跟踪工具时，写入本地的 docs/tickets/<epic-slug>.md。无论哪种方式，每张工单都要包含自身的上下文——这样，后续循环才能直接接手，而不必重新阅读整个史诗级需求：

# Ticket Breakdown — <epic name>

## Epic summary — goal in 2-3 lines
## 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 — ...
## 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)

输出

跟踪工具中的工单拆分（或 docs/tickets/<epic-slug>.md）。之后，每张工单都会进入自己的 PIV 循环——范围明确时，直接使用 /piv-plan-implementation（它会预加载所需内容）；如果需要先熟悉代码库，则先使用 /prime-codebase。预加载是可选的；上面的每张工单专属上下文正是实现这一点的关键。

注意事项

• 问题管理不受工具限制：Jira（通过 Atlassian MCP）、Linear、Notion、GitHub Issues、Archon 的任务——如果你独自开发，也可以只用一个 Markdown 文件夹。跟踪工具并不重要；目标是恰当地拆分工作，让每个循环都有最高的一次成功率，从而自动化这个循环。
• 全新项目：同样的拆分方法也适用于 MVP 阶段，而非史诗级工单。