plan by agarichan/sefirot

現在の状況

設計対象: $ARGUMENTS

タスク

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

設計対象の確認: $ARGUMENTS の内容を確認し、設計すべきスコープを把握する。設計対象が不明確な場合はユーザーに確認を取る。
目的（Why）の明確化: この設計・実装が必要な理由を明確にする。以下のいずれかの形式で言語化できるようにする：
- 「（対象者）が（困っている状態）を解消するため」
- 「（対象者）が（嬉しい状態）になるため」
目的が明確でない場合は、必ずユーザーに質問して確認を取ること。設計ドキュメントの冒頭に「目的」セクションとして記載する。
関連コード・ドキュメントの調査: 設計に必要な既存コードやドキュメントを読み込み、現状を理解する。以下のドキュメントがあれば参照する:
- CLAUDE.md: プロジェクト固有のルール
- docs/ 配下: アーキテクチャ、設計規約、品質ルール等
- プロジェクト固有の設計ドキュメント
曖昧な点の確認（該当する場合のみ）: 調査の結果、ユーザーの指示に複数の解釈が可能な部分が見つかった場合は、選択肢付きの質問で確認する。明確な場合はこのステップをスキップしてよい。
環境変数の洗い出し: 設計内容に外部サービス連携が含まれる場合、必要な環境変数を洗い出す。
- 設計対象が依存する外部サービス（API、DB、認証等）を列挙する
- 各サービスに必要な環境変数を一覧にする（例: ANTHROPIC_API_KEY, SLACK_BOT_TOKEN）
- ユーザーに確認する: 「以下の環境変数が必要です。現時点で用意できるものはどれですか？」
- 用意できるもの -> .env に記載してもらう
- 用意できないもの -> 設計ドキュメントに「Stub 実装で動作する前提」と明記する
- 洗い出した環境変数の一覧は設計ドキュメントに「必要な環境変数」セクションとして記載する
スコープ確認: 設計内容に以下が含まれる場合、ファイル作成前にユーザーの確認を取る。
- ページの作成を伴うとき: 作成するページの一覧を URL パス付きで提示し、OK か確認する
- テーブルの作成・更新を伴うとき: 変更するテーブルの一覧を提示し、OK か確認する
ファイル作成: 設計ドキュメントを作成する。
- 保存場所: docs/tasks/ 以下
- ファイル名: YYYYMMDD_HHMM_{日本語の作業内容}.md
- 日時は TZ=Asia/Tokyo date +%Y%m%d_%H%M で取得する
- 例: docs/tasks/20250815_1430_ユーザー認証システム設計.md
整合性チェック: 作成したドキュメントがプロジェクトのアーキテクチャルールと矛盾していないかダブルチェックする。矛盾があれば修正する。
完了報告: 作成した設計ドキュメントのパスを報告し、ユーザーのレビューを待つ。そのまま実装に進んではならない。
コミット: ユーザーから OK が出たら、設計ドキュメントをコミットする。

注意事項

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

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