agile-epic

エピック

このスキルを使って、インテーク、ロードマップ、または大規模な取り組みを、ストーリーに分解し、ロードマップと受け入れ条件を備えた構造化されたエピックに変換します。

スラッシュ経由で受け取った初期コンテキスト：$ARGUMENTS

$ARGUMENTS に値が含まれている場合（例：インテークのパス、説明、取り組みの名前）は、それを出発点として使用します。 空の場合は、どの取り組みを構造化するか尋ねます。

言語

成果物はユーザーの言語で作成します。正しい文法を使い、必要な発音区別符号や言語固有の文字を適用します。ユーザーの言語が不明な場合は、出力を生成する前に確認します。テンプレートは英語です。見出しと内容を適切な言語に翻訳してください。

プロジェクトルート

このスキルは、エージェントの現在の作業ディレクトリではなく、プロジェクトルート（作業を行うリポジトリ）からの相対パスで成果物を書き込みます。

• プロジェクト内から呼び出された場合は、このスキルに記載された相対パスを使用します。
• 別のディレクトリ（例：隣接するリポジトリ、またはプロジェクトが別の場所にある場合）から呼び出された場合は、すべての成果物パスの先頭に <project-root>/ を付けます。
• プロジェクトルートが曖昧な場合は、書き込みの前にハーネスの質問ツールを使ってユーザーに確認します。

プロンプト

CLAUDE.md / AGENTS.md のプロジェクト全体の規約（「Skill Prompting Conventions」）に従います。以下の判断ポイントでは、ハーネスの構造化質問ツール（Claude Code の AskUserQuestion、Codex の ask_user_question、または OpenCode の question）を使用します。

判断ポイント	構造化質問にする理由	推奨される選択肢
ユーザー指定のパスが規約と異なる場合の保存先	元に戻すのが難しい書き込み	規約に従う・ユーザー指定のパスを使用・確認する
ロードマップの図の種類	テンプレートの適合性に影響する	Mermaid フローチャート・Mermaid ガントチャート
/agile-story で最初に詳細化するストーリー	次のスキルへの分岐を決める	依存関係の先頭・選択する

自由形式のプロンプト（構造化質問ツールを使わないもの）：

• ストーリー名（kebab-case）
• エピックのタイトルと成果の表現

一時停止なしモード：ユーザーがスキル実行中の確認を明示的に無効にしている場合は、すべての構造化プロンプトを「未解決の質問」（または同等の項目）に記載し、処理を止めずに進めます。

目的

• 大規模な取り組みを、規模に見合った実行可能なストーリーに分解する
• 依存関係と順序を含むストーリーバックログを構成する
• エピックのロードマップ（フェーズ、後続作業を可能にする要素、中間検証）を定義する
• 各ストーリーを個別に計画・実行できるようにする
• 個々のタスク計画に取って代わるのではなく、実行の指針となる成果物を作成する

使用する場面

• /agile-intake または /agile-roadmap で大規模な取り組みが特定された後
• 複数のストーリーを連携させる必要がある場合
• 成果物間に依存関係があり、順序付けが必要な場合
• 成果物の提供順を導くロードマップが必要な場合
• 単純な /agile-story よりも充実した構成が必要な中規模から大規模の作業

使用しない場面

• 作業が小規模で局所的な場合 — /agile-story を直接使用します
• 問題がまだ記録されていない場合 — まず /agile-intake を使用します
• 戦略的な方向性が必要な場合 — まず /agile-roadmap を使用します
• 既存の成果物を検証する必要がある場合 — /agile-refinement を使用します

プロセス

1. コンテキストを分析する

インテーク、ロードマップ、または提供された資料を読みます。以下を特定します。

• マクロレベルの問題と目的
• 影響を受ける領域
• 制約と前提条件
• 推定される範囲と複雑さ
• UI／プロダクトのフローが重要な場合、planning/<initiative>/proto/ にある既存のプロトタイプ
• ドメインの振る舞いが重要な場合、planning/<initiative>/business/*.md にある既存のビジネスルール

取り組みが UI 中心で、プロトタイプが合意済みのゲートとなっている場合は、関連するプロトタイプのルート／画面が用意されるか、ユーザーが明示的にゲートの適用を免除するまで、エピックを確定しないでください。

2. ストーリーに分解する

技術レイヤーごとではなく、価値を縦に切り分けた単位で分解します。

• 各ストーリーで、観察可能な成果を提供する必要があります
• 可能な場合は、独立したストーリーを優先します
• ストーリー間の依存関係（どのストーリーが何を可能にするか）を特定します

各ストーリーでは、次の項目を定義します。

• 名前と目的（1行）
• 見積もり規模（小、中、大）
• 依存関係（依存するストーリー）
• 該当する場合、関連するプロトタイプのルート／画面
• 該当する場合、関連するビジネスルールのID／ファイル
• 要約した受け入れ基準

3. エピックの概要を構成する

必須セクションを記入します。

• コンテキスト： 課題、AS-IS、TO-BE、対象外
• ストーリーバックログ： 各ストーリーの目的、規模、依存関係の一覧
• ロードマップ： フェーズ／スプリント、何が何を可能にするか、中間検証
• リスク： 起こり得る問題とその緩和策
• エピックの受け入れ基準： 取り組みが完了したと判断する方法

4. ロードマップを定義する

• ストーリーをフェーズ／スプリントごとにグループ化します
• 並行して進められる作業を示します
• クリティカルパスを強調します
• 中間検証（マイルストーン）を含めます

5. 協働作業を考慮する

チームに開発者が2人以上いる場合：

• 開発者が同時に作業できるよう、並行トラックまたはレーンを特定します
• トラック間のインターフェース契約（型、スキーマ、API）を定義し、作業の停滞を最小限に抑えます
• 可能な場合は、ストーリーをトラックに割り当てます
• トラック間の並行作業を可視化するため、Mermaid の gantt 図を使用します

6. ファイルを生成する

エピックでは複数のファイルを生成します。

planning/<initiative>/epics/NN-<epic-name>/
├── 00-overview.md         (the epic overview: context, backlog, roadmap, risks)
├── 01-story-name.md       (first story: context + tasks inline)
├── 02-story-name.md       (second story: context + tasks inline)
└── ...

• 00-overview.md には、エピックレベルのコンテキスト、ストーリーバックログの概要、ロードマップ、リスク、受け入れ基準を記載します。
• 各 NN-story-name.md には、ストーリーのコンテキスト、受け入れ基準、ファイル、タスク、検証をすべて1つのファイルに記載します。

NN はゼロ埋めした連番です。各エピックには、epics/ の下に個別のフォルダーを作成します。

保存先

• エピックフォルダー：planning/<initiative>/epics/NN-<epic-name>/
• イニシアチブに planning/ 内のフォルダーがない場合は、ユーザーに名前を尋ねます
• パス競合ゲート： ユーザーが上記の規約に一致しない保存先パス（例：epics/NN-<epic-name>/ の形式ではなく、planning/<initiative>/<epic-name>/）を指定した場合は、書き込み前に競合を伝えます。ユーザーが明示的に確認した場合に限り指定されたパスを使用し、確認がない場合は規約に従い、その理由をユーザーに伝えます。曖昧さを解消するには、ハーネスの質問ツール（## Prompting を参照）を使用します。

ロードマップ図

作業に適した Mermaid の種類を選びます。

• flowchart — 固定スケジュールがなく、依存関係のある進行を示すロードマップに推奨します（個人開発や長期的なイニシアチブで一般的なケースです）。
• gantt — 実際のチームスケジュール（具体的な開始日、トラックごとの稼働可能人数）がある場合に限り使用します。個人開発や期限のない作業では、gantt は見せかけの精度を生むため、代わりに flowchart を選びます。

相互参照

00-overview.md の先頭には、必ず次を含めます。

**Origin:** `planning/<initiative>/intake.md`

各ストーリーファイルには、次を含めます。

**Origin:** `planning/<initiative>/epics/NN-<epic-name>/00-overview.md`

該当する場合は、さらに次も含めます。

**Prototype refs:** `planning/<initiative>/proto` route/screen IDs
**Business rules:** `planning/<initiative>/business/*.md` rule IDs

次のステップ

エピックの最後に、次を提案します。

• 「/agile-story を使って、ストーリー1の実行計画を作成しますか？」
• 「/agile-refinement を使って、成果物を検証しますか？」

最初に詳細化するストーリーをユーザーに尋ねます。

参考テンプレート

概要の成果物のベースとして、このスキルの templates/epic.md を使用します。

ルール

• エピックで分解を直接扱うようになりました。分解のための個別のリファインメント手順はありません。/agile-refinement は検証／リントにのみ使用します。
• 技術レイヤーごとではなく、動作／提供価値（縦割りのスライス）ごとに分解します。
• バックログの各ストーリーには、明確な目的があり、個別に実行可能でなければなりません。
• ロードマップには、時系列だけでなく依存関係も示す必要があります。
• エピックの受け入れ基準は検証可能でなければなりません。
• エピックの進行に応じて、ストーリーのステータスを更新します。
• 各ストーリーファイルには、個別に計画・実行するために十分なコンテキストを記載する必要があります。

00-overview.md に必要なセクション

1. コンテキスト（問題、AS-IS、TO-BE、対象外）
2. トレーサビリティ（プロトタイプのルート／画面とビジネスルールの ID／ファイル）
3. ストーリーバックログ（目的、規模、依存関係、ステータスを含むリスト）
4. ロードマップ（フェーズ、並行作業、クリティカルパス）
5. エピックの受け入れ基準
6. リスク

NN-story-name.md に必要なセクション

1. コンテキスト（問題、目的、価値、制約）
2. トレーサビリティ（プロトタイプのルート／画面とビジネスルールの ID／ファイル）
3. ファイル（正確なパス、アクション、理由）
4. 詳細（AS-IS、TO-BE、スコープ、受け入れ基準、依存関係）
5. タスク（フェーズごとに分けた、検証可能なチェックリスト）
6. 検証（コマンド、検証項目、エビデンス）

フローとの関係

flowchart LR
    A["/agile-intake"] --> B["/agile-roadmap"]
    B --> C["/agile-epic"]
    C --> D["/agile-story"]
    D --> E[execution]
    E --> F["/agile-status"]
    F --> G["/agile-retro"]

このスキルは、インテーク／ロードマップの後、タスクレベルの実行前に使用します。成果物の検証には /agile-refinement を使用します。実行計画には /agile-story を使用します。