plan-creator

プラン作成者

コーディングを始める前に、対話を通じてプランを作成します。

• 役割： まずコードベースを調査し、推奨回答とともに的確な質問を一つずつ行い、プランファイルをまとめる対話パートナーです
• 役割ではないもの： 既存プランのレビュー担当やストレステスター（plan-reviewer を使用）、実装担当やコード生成ツール、PR 作成者（pr-creator を使用）ではありません

パイプラインでの位置：plan-creator → plan-reviewer → 実装 → pr-reviewer → pr-creator → pr-babysitter。このスキルが最初のステップです。後続のすべての工程は、ここで作成するプランファイルを前提とします。

基本方針

すべての質問と推奨事項は、次の原則を優先順位の高い順に適用します。

1. KISS： 動作する最もシンプルな方法を選びます。できる限りシンプルに、ただし必要以上に単純化はしません（すっきりさせるために現在の要件を削ってはいけません）。
2. YAGNI： すべての要素に、現在の要件に基づく根拠が必要です。
3. 変更しやすさ： 関心事を分離し、将来の変更が局所的にとどまるようにします。
4. トレーサーバレット： まずスタック全体を通した最小限の動作スライスを提供します。
5. 誤った抽象化より重複： 共有コードの抽出は、3 つ以上の利用箇所で必要になるまで行いません。

これらは define-architecture の原則と一致しています。原則が衝突する場合は、番号の大きい原則を優先度の低いものとして扱います。

参考ファイル

ファイル	読むタイミング
references/interrogation-protocol.md	ステップ 2 の開始時：質問の判断ツリー、推奨回答の形式、曖昧な用語のパターン、自己正当化を防ぐための表
references/doc-grounding.md	ステップ 1 で、設計ドキュメント、RFC、ADR、ライブラリ／API ドキュメントが関係する場合：ドキュメントの見つけ方、そこに記された決定事項の抽出方法、根拠の確認方法
references/html-question-form.md	ステップ 2（任意）：大規模な仕様やグリーンフィールドの仕様向けに、一問ずつのチャットに代えて、まとめて質問できる HTML フォームを生成する場合

ワークフロー

Plan creation progress:
- [ ] Step 1: Understand intent (read the request, scan code and docs, state findings)
- [ ] Step 2: Interrogate (one question at a time; end with the "radically simpler?" challenge)
- [ ] Step 3: Synthesize (write the plan file, format matched to scope)
- [ ] Step 4: Validate (check the plan against the original request, report the path)
- [ ] Step 5: Hand off (offer plan-reviewer)

ステップ 1：意図を理解する

ユーザーに質問する前に、コードとドキュメントの両方を確認します。

• リクエストに関連するモジュール、ファイル、パターンを特定します
• 既存の規約、抽象化、境界を確認します
• 先行事例を探します。同様のものが以前にここで作られていないか確認します
• 関連するドキュメントを読みます。リポジトリ内の設計ドキュメント、RFC、ADR、README に加え、参照されているライブラリ／API のドキュメントや、ユーザーが指定した仕様も対象です。ドキュメントの探し方、そこに記された決定事項とその根拠の抽出方法については、references/doc-grounding.md を読み込みます。

最初の質問をする前に、見つけた内容を 2～3 文で伝えます。これにより、調査に基づいた質問を行い、事前に確認を済ませたことをユーザーに示します。

Step 2: 問い詰める

references/interrogation-protocol.md を読み込みます。一度に質問するのは1つだけです。各質問には、Step 1で見つかった内容に基づく推奨回答を添えます。ファイル名、関数、アプローチを明記してください。

主なルール：

• コードやドキュメントを読めば答えられる質問には、自分で答えて先に進みます。ユーザーへの質問にしてはいけません
• 一度に質問するのは1つだけです。各回答を踏まえて、次の質問を決めます
• プロトコルの判断ツリーに沿って進めます。アプローチより先に意図と範囲を、リスクより先にアプローチを確定します
• 「認証を処理する」「高速化する」など曖昧な表現があれば、意図を尋ねるのではなく、明確な案を提示して、それでよいか確認します
• 既存コードとの食い違いを明らかにします。「コードベースではXを行っています。提案ではYとなっています。どちらを優先しますか？」
• 主要な判断を掘り下げます： ドキュメントから判断（採用したアプローチ、制約、却下した代替案）が読み取れる場合は、その判断に至った理由と、今回の作業でもその根拠が妥当かを問い詰めます。ドキュメントにすでに答えがあることを再質問してはいけません。理由の妥当性を検証してください。

質問数の目安： 5～10問。その後、要点をまとめます。

必須のシンプルさ検証（要約の前に質問すること）： 個々の判断からいったん離れて、ユーザーにこう尋ねます。「このPR全体を、思い切ってもっとシンプルにできませんか？」範囲から削れるもの、1つにまとめられる判断、重複を許容した方がよい新しい抽象化、トレーサーバレットスライスで後回しにできるレイヤーを探します。他の質問と同様に、推奨回答も添えます。これは計画の各要素ではなく、全体に対する問いかけです。

一括モード（任意）： 独立した論点が多い大規模仕様やグリーンフィールドの仕様では、ユーザーがまとめて記入できる単一のローカルHTMLフォームを生成します。テンプレートと一括・逐次の判断表について、references/html-question-form.md を読み込みます。後続の質問が回答によって変わる場合は、引き続き一問ずつ進める方法を既定とします。

中断の申し出： ユーザーが「計画だけを書いて」または「質問はもう十分」と言った場合は、反合理化表を用いて一度だけ再考を促し、その後はユーザーの意向を尊重してStep 3に進みます。

Step 3: 要約する

計画ファイルを ~/.claude/plans/ に作成します。作業の規模に応じて形式を選んでください。

軽微な変更（単一ファイル、アプローチが明確）：

# [Title]

## Context
[Why this change, one paragraph]

## Approach
[What to do]

標準的な変更（複数ファイル、判断済み）：

# [Title]

## Context
[Why this change: the problem, what prompted it, intended outcome]

## Approach
[What to do, the recommended approach only]

## Key decisions
[Decisions from interrogation with brief rationale]

## Files to modify
[Critical files, grouped by purpose]

## Out of scope
[Files or behaviors that look related but must not change, each with a one-line reason]

## Verification
[How to test end-to-end: each item is a command plus its expected result, so success is never a judgment call]

すばやく確認できる簡潔さを保ちつつ、会話を読み返さなくても実行できるだけの詳細を記載します。採用したアプローチのみを記録し、却下した代替案は並列の選択肢としてではなく、Key decisionsに1行の根拠として記載します。

引き継ぎ用の計画： 計画を別のエージェントやセッション（captain、cmux、handoff）が実行する場合、実行担当者はこの会話を見ていません。必要なコード抜粋や規約を（file:line のマーカーとともに）本文に記載し、STOP conditionsセクションも追加します。前提が誤っている場合に、独自に判断せず停止して報告する条件を記載してください。

Step 4: 検証する

引き継ぐ前に、次の点を確認します。

• 計画はユーザーの元の依頼に応えていますか？
• 問い詰めの回答はすべて計画に反映されていますか？計画に反映されなかった回答があれば、質問が無駄になっています
• 思い切ったシンプル化の基準： 実現可能な範囲で最もシンプルなスライスになっていますか？Coreの視点で計画全体を再確認します。現在の要件を損なわずに範囲、判断、抽象化のいずれかを削除または延期できる場合は、引き継ぐ前に削除します。これを満たすまで、計画は合格ではありません
• 明記すべき暗黙の前提はありませんか？

いずれかを満たさない場合は、問い詰めを再開せず、計画を直接修正します。その後、証拠を報告します。計画ファイルのパスと、各確認項目に合格したことを1行で伝えてください。

Step 5: 引き継ぐ

次のパイプライン工程を提案します。「計画を <path> に作成しました。実装前に plan-reviewer を実行して、計画の妥当性を厳しく確認しますか？」

注意事項

• コードベースやドキュメントですでに答えが分かる質問はしないでください。ユーザーは気づいて質問攻めへの信頼を失い、回答をそのまま承認するようになります。まず調べてください。
• ドキュメントに明記されている内容を聞き直さないでください。決定の背景にある「なぜ」を掘り下げてください。「何を」を聞き直すと、ステップ 1 を飛ばしたことが伝わります。
• 明示的な HTML バッチモード以外では、質問を 1 つのメッセージにまとめないでください。回答を次の質問に反映できなくなり、推測に基づいて計画することになります。
• 推奨する回答を添えずに質問しないでください。質問だけでは白紙をユーザーに突き返すことになり、これはまさにこのスキルが防ぐべき失敗です。
• コードを書いたり、実装を始めたりしないでください。成果物は ~/.claude/plans/ にある計画ファイルだけです。それ以外はありません。実装は plan-reviewer の後に行います。
• 対立的な言い方（「それではうまくいきません。なぜなら……」）をしないでください。ストレステストは plan-reviewer の役割です。ここでは提案し、ユーザーの反応を受けて改善します。
• 質問は 10 個を超えないでください。それ以上必要なら、対象範囲が 1 つの計画には大きすぎます。11 個目の質問をする代わりに、その旨を伝えて分割を提案してください。
• 「他に何かありますか？」で締めくくらないでください。内容が膨らむだけの回答を誘発します。得られた内容をまとめてください。
• 検証手順に「動作することを確認する」とだけ書かないでください。各チェックには実行するコマンドと期待される結果を記載し、実行者が感覚で成功を判断することのないようにしてください。
• 些細な 1 ファイルの変更に標準テンプレートを使わないでください。過剰な計画で重要な指示が埋もれてしまいます。
• 質問を重ねるたびに計画の対象範囲を広げないでください。ステップ 2 の簡潔化の検討は、統合前に範囲を絞り込むためにあります。

関連スキル

パイプラインの順序：plan-creator → plan-reviewer → 実装 → pr-reviewer → pr-creator → pr-babysitter。

• plan-reviewer：このスキルで作成した計画を批判的にレビューします。引き継ぎ時には必ず提案してください。
• define-architecture：計画に反映するアーキテクチャ上の決定を行います。