plan-work

作業の計画

目標

次の条件を満たす計画を作成します。

• リポジトリの実態に基づいている（調査）
• 判断とリスクが明確である（分析）
• 不明点がゼロになるまで実装手順に進まない（事前のQ&A）

確認する情報（不足している場合）

• 成果・受け入れ基準（「完了」の定義）。
• 制約：期間、後方互換性、パフォーマンス、セキュリティ、データ移行。
• 対象環境：ローカル／ステージング／本番。機能フラグや段階的なロールアウト要件の有無。
• 対象外（行わないこと）。

ワークフロー（調査 -> 分析 -> Q&A -> 実装）

1. 調査（現状）
   • まずリポジトリのガイドを読みます：AGENTS.md、README.md、docs/（必要な場合のみ）。
   • エントリーポイントと担当領域（バックエンド／フロントエンド／インフラ）を特定します。
   • 関連するコードパスやパターンを探します：
     • シンボル、エンドポイント、設定キー、エラー文字列を rg で検索
     • 判断に迷う場合は、履歴と意図を git log -p／git blame で確認
   • 計画が外部の動作（フレームワーク／ライブラリ／ツール）に依存する場合は、公式ドキュメント、リリースノート、または context7 を参照し、バージョンや前提条件を明記します。
   • 調査結果をファイルパス付きの簡潔な箇条書きにまとめます。
2. 分析（変更内容と理由）
   • 要件と前提条件を改めて述べます。
   • 選択肢（1～3個）とトレードオフを列挙し、1つを選んで理由を説明します。
   • リスクやエッジケース、およびそれらをカバーするテストを特定します。
   • 未解決の質問をまとめます。
3. Q&A ゲート（省略不可）
   • 未解決の質問がある場合は質問し、そこで止めます。
   • ユーザーが回答するか、前提条件を明示的に受け入れるまでは、実装手順を提案しません。
   • 最初の段階では、作業の分岐を大きく絞り込める質問を1～5個します。
   • 質問全体を1～5個に制限しません。適切な実装計画に必要な情報がすべて明確になるまで、引き続き質問します。
   • 回答しやすい形式にします。番号付きで簡潔にし、可能な場合は選択式にします。
   • 推奨案と簡単に回答できる方法（例：「defaults」と返信）を提示します。
     • 選択肢の中で、どれかをデフォルトとして示さないでください。必要な場合は、別途注記します。
   • 役立つ場合は、回答しやすい「よくわからない」という選択肢を用意します。
   • 大きなメリットやデメリットがある選択肢には、簡潔な補足を角括弧で加えてもかまいません。
   • 回答しやすくなる場合は、「必須事項」と「任意事項」を分けます。
   • 簡潔に回答できる形式（例：「1b 2a 3c」）にし、選択内容を平易な言葉で言い換えます。
   • 必須の回答が揃うまで、作業を始めずに待ちます：
     • 不明点に依存するコマンドの実行、ファイルの編集、計画の作成は行いません。
     • 方針を決めない範囲であれば、リスクの低い調査（読み取り専用、変更を伴わない作業）は可能です。
   • 回答を得た後、要件を1～3文で言い換えて（制約と成功基準を含めて）、その後に進めます。
4. 実装計画（Q&A の後のみ）
   • 妥当な順序で小さな手順に分けます。
   • 変更する可能性が高いファイルやディレクトリを記載します。
   • 変更を検証するために実行するテスト（ユニット／統合／ビルド）を記載します。
   • 複数のモジュールにまたがる変更の場合は、調整手順（契約の変更、クライアントの再生成、バージョニング）を含めます。

Q&A テンプレート（機能計画向け・簡易版）

開始する前に、次の点を確認させてください：（1）質問（2）質問（3）質問。 これは最初の質問です。適切な実装計画に必要な情報がすべて明確になるまで、追加の質問を続けます。

確認必須 1) a) b) c) 2) a) b) c) 3) C a) b) c) d)

確認任意 4) a) b) c)

次の形式で返信してください：「1a 2b 3c 4a」（または、こちらに選択案の提案と確認を任せる場合は「propose」）。

成果物

references/plan-template.md を使って記入します。