pdd

プロンプト駆動開発

概要

大まかなアイデアを、詳細な設計と実装計画にまとめます。このプロセスは反復的に進めます。要件の明確化、調査、設計、計画を行い、必要に応じて各フェーズを行き来します。

重要な注意事項

以下のルールは、すべてのステップに適用されます。

• ユーザー主導のフロー： ユーザーが明示的に確認するまで、次のステップに進んではいけません。各移行時に、次に何をしたいかユーザーに尋ねてください。
• 反復的な進行： ユーザーはいつでも、要件の明確化と調査の間を行き来できます。フェーズの移行時には、常にこの選択肢を提示してください。
• 進行に合わせて記録： 質問、回答、調査結果はリアルタイムでプロジェクトファイルに追記してください。最後にまとめて書き込んではいけません。
• Mermaid 図： 調査ドキュメントと設計ドキュメントには、アーキテクチャ、データフロー、コンポーネント間の関係を示す図を含めてください。
• 出典： 外部資料に基づく内容を調査ドキュメントに記載する場合は、参考資料とリンクを引用してください。
• 計画のみ： この SOP では計画用の成果物を作成します。コードの実装、コンテナの実行、スクリプトの実行、実装作業の開始は絶対に行ってはいけません。ユーザーが実装を希望する場合は、ralph run を案内してください。

パラメーター

• rough_idea（必須）：具体化する最初のコンセプトまたはアイデア
• project_dir（任意、デフォルト：specs/{task_name}/）：すべての成果物のベースディレクトリです。{task_name} はアイデアから kebab-case 形式で導出します（例：「build a rate limiter」→ rate-limiter）。Ralph の仕様駆動型パイプラインに沿ったものです。

制約：

• すべての必須パラメーターを、最初に一度のプロンプトですべて尋ねなければなりません
• 複数の入力方法に対応しなければなりません：直接入力、ファイルパス、URL
• 大まかなアイデアから task_name を kebab-case 形式で導出しなければなりません
• 既存のプロジェクトディレクトリを上書きしてはいけません。すでに内容がある場合は、新しいパスを尋ねてください

ステップ

1. プロジェクト構成の作成

ディレクトリと初期ファイルを作成します。

• {project_dir}/rough-idea.md — 提供された大まかなアイデア
• {project_dir}/requirements.md — 質疑応答の記録（初期状態では空）
• {project_dir}/research/ — 調査メモ用のディレクトリ

この構成が Ralph の仕様駆動型プリセットに取り込まれることをユーザーに伝えてください。

ゲート： ユーザーがプロジェクト構成を問題ないと確認するまで、ステップ 2 に進んではいけません。

2. 初期プロセスの計画

希望する開始地点をユーザーに尋ねてください。

• 要件の明確化（デフォルト）
• 特定のトピックに関する予備調査
• 最初に追加の背景情報を提供する

ゲート： ユーザーが選択するまで待ってから進んでください。ユーザーが明示的に指示しない限り、要件の明確化や調査を自動的に開始してはいけません。

3. 要件の明確化

アイデアを詳細な仕様にまとめられるよう、質問を通じてユーザーを導いてください。

制約：

• 一度に尋ねる質問は必ず 1 つだけにしてください。複数の質問を列挙してはいけません
• 回答を事前に記入したり、質疑応答をまとめて requirements.md に書き込んだりしてはいけません
• 質問ごとに、以下のサイクルに従わなければなりません。
  1. 質問を作成し、requirements.md に追記する
  2. ユーザーに提示し、回答が完了するまで待つ
  3. 回答を requirements.md に追記する
  4. 次の質問に進む
• 次に進む前に、要件の明確化が完了したかユーザーに尋ねなければなりません

エッジケース、ユーザーエクスペリエンス、技術的な制約、成功基準を確認してください。ユーザーが迷っている場合は、選択肢を提案してください。

ゲート： ユーザーが要件の明確化の完了を明示的に確認するまで、調査または設計に進んではいけません。追加情報があれば役立つ質問が出てきた場合は、調査を行う選択肢を必ず提示してください。

4. 調査

設計に役立てるため、技術、ライブラリ、既存コードを調査します。

制約：

• 必ずユーザーに調査計画を提案し、ユーザーからの提案を取り入れてください
• 調査結果は {project_dir}/research/ に、トピックごとに別ファイルで必ず記録してください
• 調査結果を共有し、方向性を確認するため、定期的にユーザーに進捗を確認してください
• 次に進む前に、主な調査結果を必ず要約してください

ゲート： ユーザーが調査は十分だと確認するまで、イテレーションチェックポイントに進んではいけません。調査で新たな疑問が見つかった場合は、要件の確認に戻ることを必ず提案してください。

5. イテレーションチェックポイント

要件と調査の現状を要約してから、ユーザーに以下を確認します。

• 設計に進みますか？
• 要件の確認に戻りますか？
• 追加調査を行いますか？

ゲート： ユーザーが明示的に確認するまで、設計に進んではいけません。必要に応じて、要件の確認と調査の間を何度でも行き来できるようにしてください。

6. 詳細設計の作成

{project_dir}/design.md を、以下のセクションを含む単独で完結したドキュメントとして作成します。

• 概要
• 詳細要件（requirements.md から統合）
• アーキテクチャ概要
• コンポーネントとインターフェース
• データモデル
• エラー処理
• 受け入れ基準（機械検証可能な Given-When-Then 形式）
• テスト戦略
• 付録（技術選定、調査結果、代替案）

制約：

• 他のファイルを読まなくても理解できる、単独で完結した設計書を必ず作成してください
• requirements.md の要件をすべて必ず統合してください
• 調査結果をまとめた付録（技術選定、代替案、制約事項）を必ず含めてください
• 設計をユーザーとレビューし、フィードバックを反映して必ず改善してください

ゲート： ユーザーが設計を明示的に承認するまで、実装計画に進んではいけません。設計レビューで不備が見つかった場合は、要件または調査に戻ることを必ず提案してください。

7. 実装計画の作成

{project_dir}/plan.md を、段階的に進める番号付きの実装手順として作成します。

基本方針： 各手順は前の手順を土台とし、デモ可能な動作機能を完成させ、TDD のプラクティスに従うものとします。孤立したコードを残さず、各手順の最後に統合します。中核となるエンドツーエンドの機能は、できるだけ早い段階で利用可能にします。

制約：

• 各手順を追跡するチェックリストを plan.md の冒頭に必ず記載してください
• 「Step N:」形式とし、各手順に目的、実装のガイダンス、テスト要件、統合に関する注意事項、デモの説明を含めてください
• 設計の詳細を重複させずに、設計の全項目を計画で網羅してください

ゲート： ユーザーが実装計画をレビューして承認するまで、要約に進んではいけません。

8. 要約と結果の提示

すべての成果物、簡単な概要、推奨する次のステップを記載した {project_dir}/summary.md を作成します。この要約を会話でも提示します。

9. Ralph との連携を提案

「Ralph が自律的に実装するための PROMPT.md を作成しますか？」と尋ねます。

はいの場合は、以下を含む簡潔な PROMPT.md（100 行未満）を作成します。

• 目的の説明
• 主な要件
• 受け入れ基準（Given-When-Then）
• specs/{task_name}/ への参照

適切なコマンドを提案します。

• 完全なパイプライン：ralph run --config presets/pdd-to-code-assist.yml
• シンプルなフロー：ralph run -c ralph.yml -H builtin:code-assist

いいえの場合は、その旨を受け入れてセッションを終了します。

ゲート： ralph run を実行したり、実装を開始したりしてはいけません。この SOP はここで終了します。実装は、ユーザー自身が別途開始する手順です。

例

入力：「社内ツールにテンプレート管理機能を作りたいです。テンプレートの作成、編集、共有、カスタムフィールドを使ったドキュメントの生成が必要です。」

出力： specs/template-management/ ディレクトリに、rough-idea.md、requirements.md、research/、design.md、plan.md、summary.md を作成します。さらに、自律実装用の PROMPT.md も任意で作成します。

トラブルシューティング

要件の検討が停滞している場合： 別の観点に切り替える、例を提示する、または調査に切り替えて意思決定を進めることを提案してください。

調査の制約： 不足している情報を記録し、入手可能な情報で代替案を提案し、ユーザーに追加のコンテキストを尋ねてください。進行を妨げないようにしてください。

設計が複雑な場合： 小さなコンポーネントに分割し、まずコア機能に集中し、段階的な実装を提案し、要件に立ち返って優先順位を見直してください。