現在の状況

• 設計対象: $ARGUMENTS

タスク

以下の手順で設計ドキュメントを作成してください：

1. 設計対象の確認: $ARGUMENTS の内容を確認し、設計すべきスコープを把握する。設計対象が不明確な場合はユーザーに確認を取る。

2. 目的（Why）の明確化: この設計・実装が必要な理由を明確にする。以下のいずれかの形式で言語化できるようにする：

   • 「（対象者）が（困っている状態）を解消するため」
   • 「（対象者）が（嬉しい状態）になるため」

   目的が明確でない場合は、必ずユーザーに質問して確認を取ること。設計ドキュメントの冒頭に「目的」セクションとして記載する。

3. 関連コード・ドキュメントの調査: 設計に必要な既存コードやドキュメントを読み込み、現状を理解する。以下のドキュメントがあれば参照する:

   • CLAUDE.md: プロジェクト固有のルール
   • docs/ 配下: アーキテクチャ、設計規約、品質ルール等
   • プロジェクト固有の設計ドキュメント

4. 曖昧な点の確認（該当する場合のみ）: 調査の結果、ユーザーの指示に複数の解釈が可能な部分が見つかった場合は、選択肢付きの質問で確認する。明確な場合はこのステップをスキップしてよい。

   [要ユーザー確認] マーカーの使用: 設計ドキュメント作成時、実装着手時（Planner 実行時）にユーザーの判断が必要な項目には [要ユーザー確認] マーカーを付ける。Planner はこのマーカーがある項目を見つけたら、必ず質問キューでユーザーに確認する。

   マーカーを付けるべき項目:

   • 複数の選択肢があり、ユーザーの好みや要件で決まるもの（例: 対応フォーマット、UI パターン）
   • 仕様が未決定で、ユーザーに決めてもらう必要があるもの
   • 技術選定でトレードオフがあり、ユーザーの判断が必要なもの

   マーカーを付けないもの:

   • 仕様が明確に記述されている項目
   • プロジェクトの規約や既存パターンから自明に決まるもの

5. 環境変数の洗い出し: 設計内容に外部サービス連携が含まれる場合、必要な環境変数を洗い出す。

   • 設計対象が依存する外部サービス（API、DB、認証等）を列挙する
   • 各サービスに必要な環境変数を一覧にする（例: ANTHROPIC_API_KEY, SLACK_BOT_TOKEN）
   • ユーザーに確認する: 「以下の環境変数が必要です。現時点で用意できるものはどれですか？」
   • 用意できるもの -> .env に記載してもらう
   • 用意できないもの -> 設計ドキュメントに「Stub 実装で動作する前提」と明記する
   • 洗い出した環境変数の一覧は設計ドキュメントに「必要な環境変数」セクションとして記載する

6. スコープ確認: 設計内容に以下が含まれる場合、ファイル作成前にユーザーの確認を取る。

   • ページの作成を伴うとき: 作成するページの一覧を URL パス付きで提示し、OK か確認する
   • テーブルの作成・更新を伴うとき: 変更するテーブルの一覧を提示し、OK か確認する

7. ファイル作成: 設計ドキュメントを作成する。

   • 日時は TZ=Asia/Tokyo date +%Y%m%d_%H%M で取得する
   • ディレクトリ: docs/tasks/YYYYMMDD_HHMM_{日本語の作業内容}/
   • ファイル名: design.md
   • 例: docs/tasks/20250815_1430_ユーザー認証システム設計/design.md

8. 整合性チェック: 作成したドキュメントがプロジェクトのアーキテクチャルールと矛盾していないかダブルチェックする。矛盾があれば修正する。

9. 完了報告: 作成した設計ドキュメントのパスを報告し、ユーザーのレビューを待つ。そのまま実装に進んではならない。

10. コミット: ユーザーから OK が出たら、設計ドキュメントをコミットする。

注意事項

設計ドキュメントには以下の内容を含めないこと：

• 具体的な実装コード: 設計書はアーキテクチャや仕様を記述するものであり、実装コードは含めない（ただし特殊なハック実装についてのコード片などは OK）
• 今後の展望: ユーザーが明示的に言及していない将来的な拡張や改善案は記載しない
• 工数見積・所要期間: 「○週間かかる」「工数は○人日」などの時間的な見積もりは記載しない