spec-plan

spec-plan

計画のあらゆる側面についてユーザーに徹底的に質問し、共通認識に達するまで掘り下げます。設計ツリーの各分岐をたどり、決定間の依存関係を一つずつ解決します。

使用する場合

• ユーザーが計画や設計のストレステストをしたい場合
• ユーザーが「厳しく質問して」や「穴を指摘して」と言った場合
• issue-to-prd を実行する前：spec-plan で曖昧さを解消し、issue-to-prd で出力を整理します
• 連動する決定事項が多く、順番に解決する必要がある複雑な機能の場合

使用しない場合

• 要件がすでに明確に文書化されている場合 — そのまま issue-to-prd に進みます
• ユーザーが深いインタビューではなく、手短な意見だけを求めている場合
• 実装がすでに進行中の場合

ワークフロー

1. 既存のコンテキストを読む

計画が GitHub の Issue に由来する場合：

gh issue view ISSUE_NUMBER --repo ORG/REPO --json body,title,comments

コメントもすべて読みます — 既存の質問と回答は、すでに解決済みの分岐として扱います。すでに回答済みの内容を再度質問しないでください。

Issue がない場合は、プロジェクトのコンテキストを読みます：

cat project-instructions.md  # or equivalent project instructions file
cat README.md

2. インタビュー — 一度に一つの質問

設計ツリーの各分岐について：

• 質問を一つする
• 理由を添えて、推奨する回答を提示する
• ユーザーの返答を待つ
• 回答を反映し、次の分岐へ進む

警告： 一度に質問するのは一つだけです。これは issue-to-prd のように Q1〜Qn をまとめて提示する形式ではありません。次の分岐に進む前に、一つひとつを深く掘り下げてください。

コードベースを調べれば回答できる質問の場合は、質問する代わりにコードベースを調査します。

3. 依存関係を解決する

決定事項が互いに依存する場合は、依存関係を先に解決します：

• 他の決定を妨げている決定事項を特定する
• まずその阻害要因について質問する
• その後、依存する決定事項に進む

4. issue-to-prd への引き継ぎ（任意）

すべての分岐を解決したら、次を提案します：

All branches resolved. Want me to run issue-to-prd to structure this into a PRD?

ユーザーが同意した場合、このインタビューで得た共通認識を入力として使います。issue-to-prd は明確さの評価を省略し、直接ドラフト作成に進めます。

重要なルール

• 一度に質問するのは一つだけ — 広さより深さを重視します
• 必ず推奨する回答を提示する — 質問するだけでなく、提案します
• 解決済みの質問を再度しない — まず Issue のコメントを読みます
• 質問する前にコードを調べる — コードベースに回答がある場合は、それを活用します
• 会話が中断したところから始める — これまでの議論を尊重します