piv-slice-epic

/piv-slice-epic — エピックを PIV サイズのチケットに分割する

戦略ドキュメントと PIV ループをつなぐ橋渡しです。エピックドキュメントが目指す先であり、PIV ループが進行の単位です。チケットがその橋渡しを担います。 /piv-slice-epic はエピックを分割します。

入力

• $ARGUMENTS — 分割するエピックと、そのアーキテクチャ上の決定事項です。入力は1 つのドキュメント、または 2 つのドキュメントです。
  • ## Architecture セクションを含む、アーキテクチャ設計済みの単一のエピック、または
  • エピックと、別ページにあるリンク済みのアーキテクチャドキュメント（アーキテクチャがエピックの隣にある場合によくある形です。たとえば、Confluence のエピックページと、そこからリンクされたアーキテクチャページの両方を URL で渡します）。両方を読み込んでください。
  • グリーンフィールドの場合：エピックの代わりに PRD を使用します。 入力がトラッカーの参照（Confluence/Jira の URL またはキー）の場合は、Atlassian MCP 経由で参照元から取得してください。**これは作業の基盤となる入力です。**アーキテクチャには、各スライスが考慮すべき境界、データモデル、不足している要素が記されています。
• **prime の実行は必須ではありません。**セッションを prime しておくと役立ちますが、必須ではありません。コードベースの範囲が読み込まれていない場合は、このスキルが分割の前に自身で状況を把握します（ステップ 2）。

プロセス

ステップ 1 — 参照元を読む

エピック全体（目標、ユーザーストーリー、受け入れ条件、対象外）と、アーキテクチャ上の決定事項を読みます。決定事項は、エピック内の ## Architecture セクションにある場合も、別ページにある場合もあります。方針、スタック、データモデル、不足している要素、スパイクを確認します。アーキテクチャが別ページにある場合は、そのページも取得して読みます。分割内容は、そこで決定された事項に従う必要があります。

ステップ 2 — コードの範囲を把握する（prime 済みでない場合）

分割の際には、何が独立していて何に依存するか（ファイルの重複、共有される境界など）を判断できる程度にコードベースを把握する必要があります。セッションですでに状況を把握している場合は、このステップを省略します。そうでない場合は、**事前に /prime-codebase が実行されていることを前提にせず、自分で調べてください。**アーキテクチャで示された境界、データモデル、不足している要素を起点に、関連するファイルやディレクトリ（たとえば、アダプターのインターフェース、オーケストレーター、取り込みパイプライン）を読み、既存のもの、再利用できるもの、新しいコードを配置する場所を確認します。自信を持って分割できるだけの範囲にとどめ、全体を一から再調査する必要はありません。

ステップ 3 — PIV サイズのスライスに分解する

エピックをチケットに分割します。**人間向けのバックログではなく、AI 向けのスコープにしてください。エージェントのループで扱えるのは、従来のチケットよりはるかに大きな作業です。小〜中規模の実装フェーズで、サブタスクは約 8〜10 件、変更量は多くの場合500〜1500 行（テストが 20〜50％）**です。小さなエピックなら、チケット 1 件にまとめられる場合もあります。適切なサイズのチケットは次の条件を満たします。

• テスト可能な懸念事項が 1 つで、それ単独でテスト、レビュー、証明しやすい。
• 一貫した単位であり、振る舞いの垂直スライスになっている。水平なレイヤーではない。
• 独自の受け入れ条件が明確である。
• コンテキストの劣化なく、1 回の集中したループで一度に完了できる程度に小さい。エージェントが流れを見失い、効果が薄れるほど大きくしない。

依存関係、懸念事項、あるいはエンドツーエンドの薄いスライス（まずフロー全体を薄く実証し、次のループで厚くする）に沿って分割します。それぞれのチケットを最も実証しやすくできる方法を選んでください。1 回の誠実な作業でテストやレビューを行うには大きすぎるスライスは、さらに分割します。計画の詳細度は常に高く保ちます。大きくするのはスコープです。

ステップ 4 — 並列実行できるよう分割する

チケット間の依存関係を整理します。同じファイルを変更せず、互いの成果にも依存しない独立したチケットは、並列の worktree で実行できます（/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 のフェーズに対して同じ分割方法を適用します。