アイデアのブレインストーミングから設計へ

概要

自然な協調対話を通じてアイデアを完全な形の設計と仕様に変えます。

まず現在のプロジェクトコンテキストを理解し、適応型バッチ質問を使ってアイデアを洗練します。何を構築するか理解できたら設計を提示し、ユーザーの承認を得ます。

アンチパターン：「こんな簡単なものに設計は不要」

すべてのプロジェクトはこのプロセスを経由します。TODOリスト、単一機能のユーティリティ、設定変更など、すべてです。「簡単な」プロジェクトこそ、検証されていない前提が最も多くの無駄な作業を生み出します。設計は短くてもかまいません（本当に単純なプロジェクトなら数文で十分）が、必ず提示し、承認を得る必要があります。

チェックリスト

以下の各項目に対してタスクを作成し、順番に完了させなければなりません：

プロジェクトコンテキストの探索 — ファイル、ドキュメント、最近のコミットを確認
明確化質問をする — 適応型バッチ：関連する質問をグループ化してラウンドトリップを削減；フォローアップには対象を絞った単一質問
2〜3のアプローチを提案 — トレードオフとあなたの推奨案を含める
設計を提示 — 複雑さに応じてセクションを分割、各セクションごとにユーザーの承認を得る
設計文書を書く — docs/plans/YYYY-MM-DD-<topic>-design.md に保存しコミット
実装へ移行 — writing-plansスキルを呼び出して実装計画を作成

プロセスフロー

digraph brainstorming {
    "プロジェクトコンテキストの探索" [shape=box];
    "明確化質問をする" [shape=box];
    "2〜3のアプローチを提案" [shape=box];
    "設計セクションを提示" [shape=box];
    "ユーザーが設計を承認？" [shape=diamond];
    "設計文書を書く" [shape=box];
    "writing-plansスキルを呼び出す" [shape=doublecircle];

    "プロジェクトコンテキストの探索" -> "明確化質問をする";
    "明確化質問をする" -> "2〜3のアプローチを提案";
    "2〜3のアプローチを提案" -> "設計セクションを提示";
    "設計セクションを提示" -> "ユーザーが設計を承認？";
    "ユーザーが設計を承認？" -> "設計セクションを提示" [label="いいえ、修正"];
    "ユーザーが設計を承認？" -> "設計文書を書く" [label="はい"];
    "設計文書を書く" -> "writing-plansスキルを呼び出す";
}

終端状態は writing-plans の呼び出しです。 frontend-design、mcp-builder、その他の実装スキルを呼び出してはいけません。ブレインストーミング後に呼び出す唯一のスキルは writing-plans です。

プロセス

アイデアの理解：

最初に現在のプロジェクト状態を確認する（ファイル、ドキュメント、最近のコミット）
適応型バッチ質問を行う — 関連する質問をグループ化してラウンドトリップを削減：
- 最初のバッチ： 目的、制約、スコープ、技術選択をカバー
- フォローアップ： 興味深い回答やあいまいな回答に基づく、対象を絞った単一質問
<host: claude-code>
- 可能な場合は選択肢（多肢選択）を使う（AskUserQuestion は質問ごとに2〜4の選択肢をサポート）
- AskUserQuestion は1フォームあたり最大4質問までサポート — これを使ってラウンドトリップを削減する
<host: codex, opencode, cursor>
- 選択肢を番号付きリストで提示し、ユーザーに該当する番号で回答するよう依頼する
- 会話の過負荷を避けるため、1ターンあたり3質問までにグループ化する
理解に集中する：目的、制約、成功基準

アプローチの探索：

トレードオフを含む2〜3の異なるアプローチを提案する
推奨案とその理由を会話形式で提示する
推奨案を最初に提示し、その理由を説明する

設計の提示：

何を構築するか理解できたと思ったら、設計を提示する
各セクションの複雑さに応じて規模を調整する：単純なら数文、微妙なら200〜300語まで
各セクションの後に「ここまでで問題ないか」と確認する
カバーする内容：アーキテクチャ、コンポーネント、データフロー、エラーハンドリング、テスト
何か意味が通らない場合は、戻って明確化する準備をする

設計専用モード

ユーザーが実行を伴わない設計探索を希望する場合、--design-only をブレインストーミングに渡します。

--design-only 下での動作：

完全なブレインストーミングフローを実行する（コンテキスト探索 → 質問 → アプローチ → 設計 → 設計文書作成 → コミット）
writing-plans を呼び出す際に、--design-only フラグを伝播させる。
writing-plans はこのフラグを尊重する：アライメントチェック PASS → 停止（実行はディスパッチされない）。アライメント FAIL の場合、writing-plans は通常の FAIL 処理に従って修正と再チェックを行い、その後停止する — やはり実行はディスパッチされない。持続的な FAIL（最大2回の修正サイクル後）の場合、未解決のドリフトサマリーとともにユーザーにエスカレーションする — いずれにしても実行はディスパッチされない。
パイプラインは docs/plans/ にコミットされた設計文書＋計画で終了する。

デフォルト（フラグなし）： ブレインストーミング → writing-plans → アライメントチェック → サブエージェント駆動開発 → …（自律的な実装へのハンドオフ）。

設計後

ドキュメント：

検証済みの設計を docs/plans/YYYY-MM-DD-<topic>-design.md に書き込む
利用可能な場合は elements-of-style:writing-clearly-and-concisely スキルを使用する
設計文書を git にコミットする

自律ハンドオフ：

これがユーザーの最後の操作ポイントです — 以降のすべては自律的に実行されます
writing-plans スキルを自律コンテキスト付きで呼び出す：設計は承認済み、これ以上のユーザー入力は不要
writing-plans スキルは、可能な場合（Claude Code）は Claude の Plan Mode を優先し、他の環境では組み込みの計画プロセスにフォールバックします
ここからのパイプライン：writing-plans → アライメントチェック → チーム実行 → PR作成 → PR監視
他のスキルは呼び出さないでください。writing-plans が次のステップです。writing-plans が残りの自律パイプラインを処理します。

主要原則

適応型質問バッチ — 関連質問をグループ化してラウンドトリップを削減；フォローアップには対象を絞った単一質問
多肢選択を優先 — 可能な場合は自由記述より回答が容易
YAGNI を厳守 — すべての設計から不要機能を徹底的に排除
代替案を探索 — 決定前に必ず2〜3のアプローチを提案
段階的検証 — 設計を提示し、承認を得てから次に進む
柔軟であること — 意味が通らない場合は戻って明確化する
設計承認＝自律性ハンドオフ — 設計承認後、パイプラインはユーザー入力なしで実行される

ブレインストーミングから設計へ