spec-to-plan

PRD を実装計画に変換する

このスキルでは、構築する必要がある内容（PRD）を、構築する方法（段階的な実装計画）に変換します。PRD をトレーサーバレット方式の垂直スライスに分解し、フェーズに整理して、結果を ./plans/ に Markdown の計画ファイルとして書き込みます。

使用するタイミング

次のような場合にこのスキルを使用します。

• PRD または同等の仕様がすでにあり、具体的な実装計画が必要な場合。
• 単に課題を並べるのではなく、フェーズ単位で考えたい場合。何を先に構築するか、何を後回しにできるか、スライスが互いにどう積み重なるかを検討します。
• 以降の作業（例：/slice-the-spec、/incremental-tdd）を、単一の永続的な計画ドキュメントをもとに進めたい場合。

要件がまだ曖昧な場合は、まず /grill-me と /spec-writer を使用してください。

ワークフロー

コンテキストがすでに明確であれば手順を簡略化してもかまいませんが、基本構成は維持してください。PRD → スライス → フェーズ → 計画ファイルの順です。

1. PRD がコンテキストに含まれていることを確認する

   • PRD が会話内またはリポジトリ内で利用できることを確認します。
   • 利用できない場合は、ユーザーに貼り付けてもらうか、ファイルパスまたは課題を指定してもらいます。
   • 目標、ユーザーストーリー、機能要件、対象外事項、制約をざっと確認します。

2. コードベースを軽く調査する

   • この機能についてコードベースをまだ調査していない場合は、主要なモジュール、統合レイヤー、アーキテクチャパターンを把握するため、簡単に確認します。
   • スライス分割に影響する制約（例：既存のルーティング、データモデル、認証、サードパーティとの境界）を記録します。

3. 長期にわたって維持されるアーキテクチャ上の決定事項を特定する

   スライス分割の前に、フェーズをまたいで変わりにくく、事前に明記しておく価値のある決定事項を特定します。

   • ルート構成／URL パターン。
   • データベーススキーマの構造と主要なテーブル。
   • 中核となるデータモデルとドメインの概念。
   • 認証／認可の方式。
   • サードパーティサービスとの境界と統合ポイント。

   これらは計画のアーキテクチャ上の決定事項セクションに記載し、すべてのフェーズから参照できるようにします。

4. 垂直スライス（トレーサーバレット）を作成する

   • PRD をトレーサーバレット方式のスライスに分解します。スキーマ、ドメイン、API、UI、テストなど、関連するすべてのレイヤーを横断する、薄くてエンドツーエンドの単位です。
   • 垂直スライスのルールを適用します。
     • 各スライスは、必要なすべてのレイヤーを通る、範囲は狭くても完全な経路を提供します。
     • 各スライスは、それ単独でデモまたは検証できます。
     • 少数の厚いスライスよりも、多数の薄いスライスを優先します。
     • 変更される可能性が高い、壊れやすい実装の詳細（ファイル名、特定の関数シグネチャなど）は含めないでください。
     • ルートパス、スキーマ構造、モデル名など、長期にわたって維持される決定事項は含めてください。

5. スライスをフェーズにまとめる

   • リスクと価値を考慮し、スライスを 2～5 個のフェーズに順序付けします。
   • 先行するフェーズでは、次のことを行います。
     • 最もリスクの高い前提を検証する。
     • すぐにデモできる成果を提供する。
     • 後続のフェーズで踏襲できるパターンを確立する。
   • 後続のフェーズでは、対象範囲の拡大、仕上げ、エッジケースやスケールへの対応を行います。

6. ユーザーに確認する

   • 提案するフェーズを番号付きリストで提示します。 各フェーズについて、次の項目を示します。
     • タイトル：短く、内容がわかる名前。
     • 対象となるユーザーストーリー：そのフェーズで実現する PRD のストーリー。
   • 次の点を尋ねます。
     • 粒度は適切ですか（粗すぎる／細かすぎる）？
     • フェーズの順序は適切ですか？
     • フェーズを統合または分割すべきですか？
   • ユーザーが内訳を承認するまで調整します。

7. 計画ファイルを作成する

   • ./plans/ が存在することを確認し、存在しない場合は作成します。
   • 機能名に基づいて計画ファイルに名前を付けます（例：./plans/weekly-admin-summary-email.md）。
   • 以下のテンプレートを使用して調整し、アーキテクチャ上の決定事項と各フェーズのセクションを記入します。

計画テンプレート

以下を標準の Markdown 構成として使用します。

# Plan: <Feature Name>
> Source PRD: <brief identifier or link>

## Architectural decisions

Durable decisions that apply across all phases:

- **Routes:** ...
- **Schema:** ...
- **Key models:** ...
- **Auth:** ...
- **Third-party services:** ...
- (add/remove items as appropriate)

## Phases

### Phase 1: <Title>

#### What to build

A concise description of this vertical slice. Describe the **end-to-end behavior**, not layer-by-layer implementation.[1]

- Which user stories this phase covers.
- Which layers it will touch (data, domain, API, UI, background jobs, etc.).[1]

#### Acceptance criteria

- Criterion 1
- Criterion 2
- Criterion 3

***

### Phase 2: <Title>

#### What to build

...

#### Acceptance criteria

- ...

動作とルール

1. 計画レベルにとどめます。詳細な実装計画や具体的なファイル編集には踏み込まないでください。それらは /tdd のような実行スキルで行う作業です。
2. リスクと価値を考慮します。初期のフェーズでは、コアアーキテクチャのリスクを軽減し、すぐにデモできるものを提供します。
3. 垂直にスライスします。「データベースをセットアップする」「UI を構築する」だけで終わり、エンドツーエンドの価値を提供しないフェーズは避けてください。
4. 意思決定を明示します。永続的なアーキテクチャ上の決定は計画のヘッダーに記載し、後続のスキルや人が再利用できるようにします。
5. 将来の自分やエージェントに向けて書きます。計画は読みやすく、ざっと目を通しやすく、別のエンジニアや AI エージェントに出発点として引き継ぎやすいものにします。