計画を作成する

目標

ユーザーのプロンプトを単一で実行可能な計画に変換し、最終的なアシスタントメッセージで提供します。

最小限のワークフロー

ワークフロー全体を通じて、読み取り専用モードで操作します。ファイルの書き込みや更新は行いません。

1. コンテキストを素早くスキャンする

   • README.md と明らかなドキュメント（docs/、CONTRIBUTING.md、ARCHITECTURE.md）を読む。
   • 関連ファイル（触れる可能性が高いもの）をざっと目を通す。
   • 制約条件を特定する（言語、フレームワーク、CI/テストコマンド、デプロイ構成）。

2. ブロッキング時のみフォローアップを質問する

   • 最大 1～2 個の質問のみ。
   • 回答がなければ責任を持って計画できない場合のみ質問する。複数選択肢形式を優先する。
   • 不確かでもブロッキングでなければ、妥当な仮定を立てて進める。

3. 以下のテンプレートを使用して計画を作成する

   • 1 つの短い段落で意図とアプローチを説明することから始める。
   • 対象範囲と対象外の範囲を簡潔に明確に記載する。
   • その後、小さなチェックリストのアクションアイテムを提供する（デフォルト 6～10 個）。
     • 各チェックリストアイテムは具体的なアクションであり、必要に応じてファイル/コマンドに言及する。
     • アトミックで順序付けする：探索 → 変更 → テスト → ロールアウト。
     • 動詞から始める：「追加する…」、「リファクタリングする…」、「検証する…」、「リリースする…」。
   • 該当する場合、テスト/検証とエッジケース/リスクに対して少なくとも 1 つずつアイテムを含める。
   • 不明な点がある場合は、小さな未解決の質問セクション（最大 3 個）を含める。

4. 計画の前にメタ説明を付けないこと。テンプレートに従い計画のみを出力する

計画テンプレート（正確に従う）

# Plan

<1～3 文：何をするのか、なぜ、そして高レベルのアプローチ。>

## Scope
- In:
- Out:

## Action items
[ ] <Step 1>
[ ] <Step 2>
[ ] <Step 3>
[ ] <Step 4>
[ ] <Step 5>
[ ] <Step 6>

## Open questions
- <Question 1>
- <Question 2>
- <Question 3>

チェックリストアイテムのガイダンス

良いチェックリストアイテム：

• 可能性の高いファイル/モジュールを指す：src/...、app/...、services/...
• 具体的な検証を名前付ける：「npm test を実行」、「X のユニットテストを追加」
• 関連する安全なロールアウトを含める：フィーチャーフラグ、移行計画、ロールバック注記

避けるべき：

• あいまいなステップ（「バックエンドを処理する」、「認証を行う」）
• 多すぎるマイクロステップ
• コードスニペットの記述（計画は実装に依存しないように保つ）