oma-brainstorm

ブレインストーミング — 設計優先のアイデア検討

実施タイミング

目標

計画や実装に進む前に、ユーザーの意図、制約、代替アプローチを検討し、承認済みの設計を後続の計画に引き継げるように保存します。

意図のシグネチャ

• ユーザーがアイデアを持っている、ブレインストーミングをしたい、アプローチを比較したい、コンセプトを検討したい、または計画の前に設計したいと述べています。
• 実装やタスク計画に進むには、依頼がまだ曖昧です。

使用する場面

• 計画前に新機能のアイデアを検討する
• アプローチを決める前に、ユーザーの意図や制約を把握する
• トレードオフを踏まえて複数の設計アプローチを比較する
• ユーザーが「アイデアがあります」や「何かを設計しましょう」と言ったとき
• 複雑または曖昧な依頼について /plan を呼び出す前

使用しない場面

• 要件がすでに明確で、十分に定義されている場合 → oma-pm を直接使用します
• 実際のコードを実装する場合 → 専門エージェントに委任します
• コードレビューを行う場合 → oma-qa を使用します
• 既存の問題をデバッグする場合 → oma-debug を使用します

想定される入力

• 初期段階のアイデア、曖昧な目標、製品コンセプト、設計上の質問、または一連の制約
• アイデアをコードベースや製品の方向性に適合させる必要がある場合の、既存プロジェクトのコンテキスト
• ユーザーの好みと承認ゲート

想定される出力

• 明確化された意図と制約
• 実行可能なアプローチを、文章による概要（シナリオ、仕組み、残存リスク）として提示し、代替案が意思決定に役立つ場合は比較と推奨も添えます
• セクションごとに承認された設計ドキュメント
• ブラインドレビューの課題一覧（Tier 1 は解決済み、Tier 2/3 は解決済み、または明示的に保留）
• 計画に引き継ぐ前に保存された設計成果物

依存関係

• 共通コンテキストの読み込み、推論テンプレート、明確化プロトコル、品質原則、スキルの振り分け
• 矛盾に基づくアプローチの種出しに使用できる、任意の resources/triz-lite.md
• 重大な設計におけるブラインドレビューのエスカレーション経路向けの、エージェントごとのレビュアーへの振り分け（例：qa-reviewer、architecture-reviewer）
• 設計承認後のタスク分解に用いる後続の PM ワークフロー

制御フローの機能

• 曖昧さ、ユーザーの回答、アプローチの比較、承認ゲートに応じて分岐します
• 技術面または UX 面の矛盾によって異なるアプローチを検討できない場合、任意の TRIZ-lite 分岐を使用します
• 質問は一度に 1 つずつ行います
• 保存前にブラインドレビューを実施します。重大な設計では、新しいコンテキストを持つレビュアーのサブエージェントを振り分ける場合があります（このスキルでサブエージェントを起動する唯一の経路です）
• 実装やタスク計画に進む前に停止します

構造的なフロー

開始

1. 依頼が実装可能な段階ではなく、探索的なものであることを確認します。
2. 制約を把握するために十分なプロジェクトのコンテキストを読み込みます。
3. 解決策ではなく、意図と制約から始めます。

シーン

1. PREPARE：コンテキストを調査し、設計上の問いを定めます。
2. ACQUIRE：明確化のための質問を一度に 1 つずつ行います。
3. REASON：代替案が意思決定に役立つ場合は、トレードオフを踏まえて実行可能なアプローチを比較します。選択肢が 1 つだけの場合は、それを決定づける制約を説明します。
4. VERIFY：既存の設計上の決定を再利用し、重要な未決事項だけを解決したうえで、保存前にブラインドレビューを実施します（独立した観点から、互いのフィードバックを見ずに批評します）。
5. FINALIZE：設計を保存し、適切な場合は計画に移行します。

遷移

• 要件が明確になり、実装に進める状態になった場合は、PM による計画に移行します。
• ユーザーがアプローチを却下した場合は、詳細設計に進む前に修正します。
• 早い段階で実装を求められた場合は、設計が承認されるまで保留します。
• アプローチが 1 つの軸を調整するだけのものに収束した場合は、resources/triz-lite.md を読み込んで再度種出しし、文章による概要をあらためて提示します。

失敗と回復

• ユーザーが質問に答えられない場合は、前提を提示して確認を求めます。
• スコープが拡大した場合は、設計を小さなセクションに分割します。
• 代替案が 1 つに収束した場合は、その原因となっている実際の制約を特定します。TRIZ-lite は、その制約が技術面または UX 面の矛盾である場合にのみ使用します。

終了条件

• 成功：承認済みの設計が存在し、計画に進む準備ができています。
• 部分的な成功：未解決の質問と前提が明示されています。

論理操作

アクション

アクション	SSL プリミティブ	根拠
コンテキストとアイデアを読み取る	READ	ユーザーのプロンプトとプロジェクトのコンテキスト
対象を絞った質問をする	REQUEST	明確化フェーズ
アプローチを比較する	COMPARE	トレードオフの比較表
推奨事項を推論する	INFER	推奨オプション
オプションの選択を記録する	CALL_TOOL	実際のアプローチ、比較の根拠、設計／オプションの改訂。アクティブな OMA ワークフロー内で、一致する instanceId と検証ツールの --instance を使用
設計の決定権を解決する	VALIDATE	既存の指示、委任された選択、または未解決の重要な設計上の選択に対する明示的な回答
ブラインドレビューを実施する	VALIDATE	独立した視点からの批評、段階別の課題一覧、Tier 1 の解決
設計成果物を作成する	WRITE	docs/decisions/ と、そこにリンクされた調整サマリー
計画へ移行する	NOTIFY	引き継ぎサマリー

ツールと手段

• コンテキストの読み込み、推論テンプレート、明確化プロトコル
• 矛盾の洗い出しに使う、任意の TRIZ-lite リソース
• 調整サマリー用のプロジェクトメモリと、採用するアプローチの提案を保存する docs/decisions/

標準的なワークフロー経路

1. Ask one clarifying question at a time.
2. (Optional) If technical/UX contradiction or same-axis approaches only → resources/triz-lite.md.
3. Present viable alternatives as prose briefs and compare them when useful; do not invent extra options to meet a count; reuse an existing selection or delegated choice and resolve only an open material choice. In an active OMA workflow, record the actual approach, rationale, evidence, and design/option revision with `brainstorm.option-selection`; verify the matching --instance (workflow Step 3 owns the commands).
4. Design section by section within existing authorization, then blind review: independent lenses suited to the uncertainty and stakes critique the design; resolve Tier 1 issues (fresh-context reviewer subagents for high-stakes designs).
5. Save the approved approach to `docs/decisions/{NNN}-{name}.md` and update `docs/decisions/index.md` before handing off to planning. Keep this directory versioned. Read `docs/plans/designs/` and `docs/design-docs/` only as legacy fallback until migration; `design` names UI work.

リソースの範囲

範囲	リソースの対象
MEMORY	ユーザーの意図、前提、決定
CODEBASE	関連する場合の既存プロジェクトのコンテキスト
LOCAL_FS	承認済みの設計成果物。設計ドキュメント内の TRIZ-lite 付録は任意

前提条件

• ユーザーがまだ検討中であるか、依頼が曖昧です。
• エージェントは実装前に明確化の質問をできます。

効果と副作用

• 設計上の決定と、永続化された設計ドキュメントを作成します。
• 後続の計画に影響しますが、コードは実装しません。

ガードレール

1. 設計の承認前に実装や計画を行わない — ブレインストーミングで作成するのは設計ドキュメントであり、コードやタスク計画ではありません
2. 質問は一度に一つ — 明確化と承認の質問は、まず利用可能な非同期質問ツールを使い、../_shared/core/clarification-protocol.md に従って行います。利用可能な質問ツールが許可されている場合はそれに切り替え、なければプレーンテキストを使います。回答を待つ間も独立して進められる作業を続け、返答がないことや事前選択されたオプションから承認を推測してはいけません。
3. 実行可能なアプローチを比較する — 意思決定に役立つ場合は2つか3つの案を提示し、残る案がそれより少ない場合は制約を説明します。実際の目標、労力、可逆性、リスクに基づいて推奨します。名称だけを理由に、より大規模な構造変更を優先してはいけません。
4. 実行可能なアプローチを文章で説明する — 想定される状況、仕組み、残存リスク、労力を明示します。意思決定に役立つ場合は比較表を使い、その後に推奨案を示します。制約により選択肢が一つしかない場合は、その根拠を説明し、存在しない代替案を作り出してはいけません
5. 設計を段階ごとに進める — 設計を段階的に提示します。既存の決定や委任された決定権を活用し、共有の実行ポリシーに従って、未解決の重要な選択についてのみ質問します
6. 保存前にブラインドレビューを行う — 設計がごく小規模（ファイル1〜2個、リスクが低い）でない限り必須です。各視点から独立して批評し、アーキテクチャ上重要な設計、変更の取り消しが難しい設計、またはセキュリティ／コンプライアンスに関わる設計では、先入観のないコンテキストでレビュアーのサブエージェントを使用します
7. YAGNI — 過剰に設計せず、明示された目標に必要なものだけを設計します
8. TRIZ-lite は任意 — 技術上／UX 上の矛盾、または同一軸上で選択肢が収束する場合に限って使用します。厳選された原則から最大3〜5個までとし、根拠のないスコア付け、完全な TRIZ／ARIZ、従来型のマトリクスは使用しません。洗い出した原則は Step 3 の概要に反映し、ユーザーの承認に代わるものではありません
9. 選択したアプローチを保存してから移行する — /plan に引き継ぐ前に、docs/decisions/ に保存します。実行ごとの批評と result-*.md レポートは .agents/results/ に保存します。ドキュメントを docs/ に移す場合は、移行元のレポートに移行先を記載します

実行フェーズ

ブレインストーミングのワークフローを、次の手順に従って進めます。

1. フェーズ 1 - コンテキスト：既存のコードベースを調査し、プロジェクトの全体像を把握します
2. フェーズ 2 - 質問：意図と制約を把握するため、確認の質問を一度に1つずつ行います
3. フェーズ 3 - アプローチ：実際に矛盾がある場合は、必要に応じて TRIZ-lite を使って案を出します。実行可能なアプローチを文章で比較し、明示された制約、労力、可逆性、リスクに基づいて推奨します
4. フェーズ 4 - 設計：既存の承認範囲を維持し、未解決の重要な選択肢のみを解決しながら、詳細な設計をセクションごとに提示します
5. フェーズ 5 - ブラインドレビュー：設計の不確実性と重要度に応じた独立したレビュアーの観点を用い、指摘事項を Tier 1/2/3 にまとめ、保存前に Tier 1 の問題を解決します。重要度の高い設計では、新しいコンテキストのレビュアーサブエージェントにエスカレーションします。ごく小規模な設計（1～2ファイル、低リスク）の場合に限り、省略します
6. フェーズ 6 - ドキュメント作成：承認されたアプローチを docs/decisions/{NNN}-{name}.md に保存し、インデックスを更新して、プロジェクトメモリにリンク付きの調整サマリーを記録します
7. フェーズ 7 - 移行：タスクの分解を /plan に引き継ぎます

よくある落とし穴

• 解決策に飛びつく：「何を」「なぜ」を十分に理解する前に、「どのように」を尋ねる
• 質問を一度に詰め込みすぎる：質問を並べ立ててユーザーを圧倒する
• 単一アプローチへの偏り：拘束力のある制約を説明せずに、実行可能な代替案を省く
• 選択肢をマトリックスだけで示す：シナリオや仕組みを文章で説明せずにトレードオフ表だけを提示し、ユーザーが選べない状態にする
• 同じ軸の「代替案」：間隔／TTL／デバウンスなど、同じ調整項目の強度違いを3つの異なるアプローチとして提示する
• あらゆることに TRIZ を使う：実際の矛盾がないのに triz-lite を読み込み、選択肢を改善せずに手順だけ増やす
• 過剰な設計：明示されたニーズではなく、仮定上の将来要件に備えて設計する
• 設計権限を捏造する：エージェントの推奨を、ユーザーの権限に属する未解決の選択肢への承認として扱う。または、すでに承認されている選択を再度尋ねる
• ブラインドレビューを省略する：重要な設計を独立した批評のラウンドなしに保存する、または、エスカレーション先のレビュアーへのプロンプトに設計者のコンテキストを漏らす

参考資料

• TRIZ-lite（ステップ 3 での案出しに任意で使用）：resources/triz-lite.md
• コンテキストの読み込み：../_shared/core/context-loading.md
• 確認プロトコル：../_shared/core/clarification-protocol.md
• 品質原則：../_shared/core/quality-principles.md
• スキルとエージェントの対応付け：../_shared/core/skill-routing.md