現在の状況
- 設計対象: $ARGUMENTS
タスク
以下の手順で設計ドキュメントを作成してください：
-
設計対象の確認:
$ARGUMENTSの内容を確認し、設計すべきスコープを把握する。設計対象が不明確な場合はユーザーに確認を取る。 -
目的（Why）の明確化: この設計・実装が必要な理由を明確にする。以下のいずれかの形式で言語化できるようにする：
- 「（対象者）が（困っている状態）を解消するため」
- 「（対象者）が（嬉しい状態）になるため」
目的が明確でない場合は、必ずユーザーに質問して確認を取ること。設計ドキュメントの冒頭に「目的」セクションとして記載する。
-
関連コード・ドキュメントの調査: 設計に必要な既存コードやドキュメントを読み込み、現状を理解する。以下のドキュメントがあれば参照する:
CLAUDE.md: プロジェクト固有のルールdocs/配下: アーキテクチャ、設計規約、品質ルール等- プロジェクト固有の設計ドキュメント
-
曖昧な点の確認（該当する場合のみ）: 調査の結果、ユーザーの指示に複数の解釈が可能な部分が見つかった場合は、選択肢付きの質問で確認する。明確な場合はこのステップをスキップしてよい。
[要ユーザー確認]マーカーの使用: 設計ドキュメント作成時、実装着手時（Planner 実行時）にユーザーの判断が必要な項目には[要ユーザー確認]マーカーを付ける。Planner はこのマーカーがある項目を見つけたら、必ず質問キューでユーザーに確認する。マーカーを付けるべき項目:
- 複数の選択肢があり、ユーザーの好みや要件で決まるもの（例: 対応フォーマット、UI パターン）
- 仕様が未決定で、ユーザーに決めてもらう必要があるもの
- 技術選定でトレードオフがあり、ユーザーの判断が必要なもの
マーカーを付けないもの:
- 仕様が明確に記述されている項目
- プロジェクトの規約や既存パターンから自明に決まるもの
-
環境変数の洗い出し: 設計内容に外部サービス連携が含まれる場合、必要な環境変数を洗い出す。
- 設計対象が依存する外部サービス（API、DB、認証等）を列挙する
- 各サービスに必要な環境変数を一覧にする（例:
ANTHROPIC_API_KEY,SLACK_BOT_TOKEN） - ユーザーに確認する: 「以下の環境変数が必要です。現時点で用意できるものはどれですか？」
- 用意できるもの ->
.envに記載してもらう - 用意できないもの -> 設計ドキュメントに「Stub 実装で動作する前提」と明記する
- 洗い出した環境変数の一覧は設計ドキュメントに「必要な環境変数」セクションとして記載する
-
スコープ確認: 設計内容に以下が含まれる場合、ファイル作成前にユーザーの確認を取る。
- ページの作成を伴うとき: 作成するページの一覧を URL パス付きで提示し、OK か確認する
- テーブルの作成・更新を伴うとき: 変更するテーブルの一覧を提示し、OK か確認する
-
ファイル作成: 設計ドキュメントを作成する。
- 日時は
TZ=Asia/Tokyo date +%Y%m%d_%H%Mで取得する - ディレクトリ:
docs/tasks/YYYYMMDD_HHMM_{日本語の作業内容}/ - ファイル名:
design.md - 例:
docs/tasks/20250815_1430_ユーザー認証システム設計/design.md
- 日時は
-
整合性チェック: 作成したドキュメントがプロジェクトのアーキテクチャルールと矛盾していないかダブルチェックする。矛盾があれば修正する。
-
完了報告: 作成した設計ドキュメントのパスを報告し、ユーザーのレビューを待つ。そのまま実装に進んではならない。
-
コミット: ユーザーから OK が出たら、設計ドキュメントをコミットする。
注意事項
設計ドキュメントには以下の内容を含めないこと：
- 具体的な実装コード: 設計書はアーキテクチャや仕様を記述するものであり、実装コードは含めない（ただし特殊なハック実装についてのコード片などは OK）
- 今後の展望: ユーザーが明示的に言及していない将来的な拡張や改善案は記載しない
- 工数見積・所要期間: 「○週間かかる」「工数は○人日」などの時間的な見積もりは記載しない