dev-plan

ステップ 0：プロジェクトルートを特定する

検出スクリプトを実行します。

bash "$DISCOVER" root

$DISCOVER は、このスキルのディレクトリ内にある scripts/discover.sh の絶対パスです。

パスの安全性 — ツール呼び出しの間でシェルの状態は保持されないため、呼び出しのたびにスクリプトの完全なパスを指定してください。

• リテラルのホームディレクトリではなく $HOME を使用します（例：bash "$HOME/code/…/discover.sh"。bash "/Users/name/…/discover.sh" とはしません）。これにより、ユーザー名を誤って推測するのを防ぎます。
• ツールの出力から値をコピーします。 前のコマンドが返した値（$PROJECT_ROOT など）を再利用するときは、そのコマンドの出力からそのままコピーしてください。パスを記憶から再入力しないでください。
• 最初の呼び出しで確認します：スクリプト呼び出しが「No such file」で失敗した場合、パスが間違っています。処理を停止し、スキルの読み込みコンテキストからパスを再確認してください。
• ゼロ以外の終了コードを無視しないでください。 このスキルのスクリプトが失敗した場合は、処理を停止し、続行する前にエラーを報告してください。

出力を $PROJECT_ROOT として保存します。コマンドが失敗した場合は、ユーザーに伝えて処理を停止してください。

最優先の指示

唯一の成果物は、$PROJECT_ROOT/.dev/$FEATURE_NAME/ に作成する PRD ファイルです。 コードではなく、ドキュメントを作成してください。すべてのセッションで、必ずファイルをディスクに保存してください。

これは 3 つのスキルからなるシステム（/dev-plan → /dev-checkpoint → /dev-resume）の一部です。他のスキルは、ステータスマーカー（⬜ 未完了、✅／⏭️／⛔／⏹️ 解決済み）、フェーズゲート、ファイル変更の概要、サブ PRD へのリンクを使用して PRD ファイルを解析します。手順には ⬜ を使用してください。ほかの絵文字マーカーは未認識のステータスとして解析されます。その場合、手順は合計数には含まれますが、未完了として扱われ、status-update は上書きを拒否します。

AGENTS

このスキルでは、調査と計画に専門エージェントを使用します。

• prd-researcher（シアン）— コードベースを調査し、パターン、依存関係、参考実装を確認します
• prd-planner（グリーン）— 実装フェーズとファイル変更を設計します

エージェントの定義は、このスキルのディレクトリ内の agents/ にあります。

フェーズ 1：要件を把握する

$ARGUMENTS

このフェーズで確認する 3 つの重要な質問：

1. どのような機能を構築したいですか？（簡単な説明）
2. どのような問題を解決しますか？（ユーザーのニーズまたはビジネス要件）
3. 参考実装はありますか？（既存のコードや類似機能）

パス A — 上記に引数が指定されている場合

上記の $ARGUMENTS が空でない場合（ユーザーが機能の説明を指定した場合）：

1. 指定されたテキストから 3 つの質問すべてへの回答を推測します。
2. 理解した内容を 2～3 文で要約します。
3. フェーズ 2 に直接進みます。 確認を求めないでください。

パス B — 引数が指定されていない場合

上記の $ARGUMENTS が空の場合（ユーザーが引数なしで /dev-plan を実行した場合）：

1. 上記の 3 つの質問をします。
2. 停止します。それ以外は何も出力しないでください。ユーザーが回答するまで先に進まないでください。
3. 回答を受け取ったら、理解した内容を 2～3 文で要約します。
4. 「意図を正しく捉えていますか？確認いただければ、調査を開始します。」と尋ねます。
5. ユーザーが明示的に確認するまで、フェーズ 2 に進まないでください。

ガードレール：確認（パス B）または要約（パス A）が済んだら、調査に進んでください。ここで立ち止まらないでください。

ステップ 1.5：$FEATURE_NAME の導出と検証

ディレクトリやファイルを作成する前に、安全な機能スラッグを $FEATURE_NAME に設定します。

検証スクリプトで正規化および検証します。

bash "$VALIDATE" normalize "<candidate-name>"

$VALIDATE は、このスキルのディレクトリ内にある scripts/validate.sh の絶対パスです。ステップ 0 のパス安全性ルール（$HOME の使用、出力からのコピー）を適用してください。成功すると $FEATURE_NAME が出力されます。失敗した場合は、直ちに停止し、検証されていないパスで処理を続けないでください。

ルール：

• $ARGUMENTS をそのままファイルパスに使用しないでください。
• .dev/ のパス参照には、すべて $FEATURE_NAME を使用してください。

フェーズ 1.8：Wiki の確認（任意）

調査を始める前に、プロジェクト横断 Wiki で過去の事例を確認します。

cat "$HOME/.dev-wiki/index.md" 2>/dev/null

• ファイルが存在する場合は、現在のタスクに関連する機能（類似した名前、重複する分野、再利用可能なパターン）を調べます。調査エージェントへの説明時に、関連する過去の事例に触れてください。
• ファイルが存在しない場合は、何もせずにフェーズ 2 に進みます。

この手順は情報提供のみを目的としています。Wiki がない場合でも処理を止めないでください。

フェーズ 2：調査

Task ツールを使って、焦点の異なる 2～3 個の prd-researcher エージェントを並行して起動します。

Agent 1: "Find similar implementations and patterns to reuse for [feature]. Include file:line references."
Agent 2: "Identify architecture constraints, dependencies, and integration points for [feature]."
Agent 3: "List all files that will need modification for [feature] and what changes are needed."

各エージェントには subagent_type=dev-workflow:prd-researcher を使用してください。

エージェントからの応答後

1. 調査結果を統合する — エージェントの出力をまとめ、統一された調査サマリーを作成します
2. 次の形式でサマリーを提示する：
   • 再利用するパターン — 活用できる既存のコード／アーキテクチャ（file:line の参照を含む）
   • 変更するファイル — パスと1行の説明の一覧
   • 重要な決定事項 — 確認が必要なアーキテクチャ上の選択肢を2～3個
   • 未解決の質問 — 不明な点（あれば）

約10～15行に収めてください。

停止してください。ユーザーが調査結果を確認するか、修正を提示するまで、フェーズ 3 に進まないでください。

ガードレール：調査は PRD 作成のために行います。調査は1回で終えて、執筆に進んでください。より詳しい調査を求められた場合は、もう1回だけ実施してから執筆してください。

フェーズ 3：PRD の作成

1 個の prd-planner エージェントを起動して、実装構成を設計します。

"Design implementation phases for [feature].
Research findings: [summarize key patterns and files from Phase 2].
Determine if this needs sub-PRDs (complex) or a single PRD (simple)."

subagent_type=dev-workflow:prd-planner を使用してください。

エージェントからの応答後

1. エージェントの出力を確認する — フェーズが論理的で、必要事項を網羅していることを確認します
2. アーキテクチャの方針を提案する — 推奨する構成をユーザーに提示します

停止してください。ユーザーがアーキテクチャの方針を確認するか、調整を求めるまで、ファイルを作成しないでください。

3. $PROJECT_ROOT/.dev/$FEATURE_NAME/ の下にファイルを作成します：

   • 必ず 00-master-plan.md を作成します — prd-templates.md のマスタープランテンプレートを使用します
   • 複雑な機能の場合は、01-sub-prd-[name].md などを作成します — prd-templates.md のサブ PRD テンプレートを使用します
     • 各フェーズの手順は、必ず1か所だけで管理してください。 マスタープランの Implementation Order に番号付きの ⬜ 手順を記載し（サブ PRD は手順のない説明文とする）、またはマスタープランではフェーズを手順のない範囲見出しにまとめ、サブ PRD の ## Implementation Progress 表に手順を記載します。同じ手順を両方に記載すると、サブ PRD のカウンターが機能しない重複項目になります。status-update は一方のファイルにしか書き込まないため、もう一方は更新されず、ダッシュボードに誤解を招く 0/N が表示されます。
   • 調査結果（フェーズ 2）と実装計画（エージェントの出力）を PRD に反映します

4. PRD の構造を検証する — CLI を実行して、PRD を解析できることを確認します：

   node "$CLI" feature-show --json --dir "$PROJECT_ROOT/.dev/$FEATURE_NAME"
   

ここで $CLI は、このスキルのディレクトリにある scripts/dev-workflow.cjs の絶対パスです。ステップ 0 のパス安全ルール（$HOME を使用し、出力からコピー）を適用してください。

コマンドが失敗するか、予期しないデータが返された場合は、続行する前に PRD ファイルを修正してください。

5. 作成したものを明示する — 書き込んだすべてのファイルパスを一覧にします。
6. 続きから作業できるよう、/dev-checkpoint の実行を提案します。

ガードレール：ファイルは必ず作成してください。ファイルを書き込まずにこのフェーズに到達した場合は、ほかのすべての作業を停止して PRD を作成してください。

ルール

• 調査は1回だけ行い、その後に執筆します — 調査を延々と続けないでください
• 調査結果はマスタープランの「Research Findings」セクションにまとめます（別途 findings.md は作成しません）

プライバシールール

PRD ファイルには絶対に含めないでください — 安全な代替表現を使用してください：

• ユーザー名を含む絶対パス → プロジェクトルートからの相対パスを使用します
• シークレット、API キー、トークン、認証情報 → プレースホルダー（<API_KEY>、$ENV_VAR）を使用します
• 個人情報（氏名、メールアドレス） → 一般的な参照表現を使用します