speclisted

抽象的なアイデアを詳細な仕様書に変換する。 ## /spec と /plan の役割分担 | 観点 | /spec | /plan | |------|-------|-------| | 入力 | 曖昧なアイデア、抽象的なプロンプト | 明確な仕様、定義されたタスク | | 焦点 | **何を**作るか（要件・制約） | **どう**作るか（実装戦略・ファイル） | | 出力 | 仕様書（`docs/specs/*.md`）/ GitHub Issue | 実装プラン（`docs/plans/active/*.md`） | | リサーチ | コードベース探索、ウェブ検索、ベストプラクティス | 影響ファイル、リスク分析 | | ユーザー対話 | 反復的なブレインストーミング（発散）+ 明確化（収束） | フロー選択 + 重要分岐の解決（収束） | ## ゴール - 曖昧なリクエストを実装可能な仕様書に変換する - 疎な入力でも反復的なブレインストーミングで拡張する - コードベース分析とリサーチを通じて要件を発見する - ターゲットとなる質問でユーザーとの対話を通じ残留する曖昧性を解消する - コンテキストロスに耐えるバージョン管理された仕様書を作成する ## ステップ 1. **リクエストを理解する**（内部処理、ユーザー対話なし）：ユーザーの入力を読む。明確な点と曖昧な点をリスト化する。このステップでは `AskUserQuestion` を呼び出さない。 2. **ブレインストーミングでアイデアを拡張**：入力が疎な場合（例：1行の文）、以下の軸を順番に探索するために `AskUserQuestion` を繰り返し使用する： - 目的と背景（なぜ重要か、解決すべき問題） - ターゲットユーザーと使用シナリオ - 代替アプローチ（他の解決方法とトレードオフ） - 成功基準（「完了」の状態） - スコープ境界と���先度（明示的に除外するもの、MVPスコープ） - 既知の制約（技術、時間、チーム） - リポジトリが答えを持っている場合は質問を省く。 3. **コードベースの探索**：リクエストに関連する既存コード・パターン・影響範囲を調査する。 4. **ベストプラクティスのリサーチ**：問題ドメインの業界標準、一般的なアプローチ、参考実装を調査する。 5. **残留する要件の明確化**：ブレインストーミングとリサーチの後に残った曖昧性を `AskUserQuestion` で解消する（収束フェーズ）。 6. **仕様書の下書き**（メモリ内—まだファイルに書かない）：要件・制約・トレードオフ・受け入れ基準を含む完全な仕様書を作成する。 7. **ユーザーによる最終レビュー**：ファイル作成前にユーザーに承認を求める。 - `AskUserQuestion` で確認： 1. **承認** — 仕様書を確定する 2. **修正が必要** — フィードバックを反映してから確定する 8. **出力選択**：`AskUserQuestion` で聞く： 1. **Issue のみ** — GitHub Issue を作成し、仕様書ファイルは残さない 2. **仕様書ファイルを保存** — `docs/specs/<date>-<slug>.md` を書いて PR を作成 3. **仕様書を保存して /plan へ** — 仕様書を書いてから