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/plans/designs/ とメモリー
計画へ移行する	NOTIFY	引き継ぎの概要

ツールと手段

• コンテキストの読み込み、推論テンプレート、明確化プロトコル
• 矛盾の洗い出しに使う TRIZ-lite リソース（任意）
• 保存された設計のためのプロジェクトメモリーと docs/plans/designs/

標準的なワークフローの流れ

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 design to `docs/plans/designs/` before handing off to planning.

リソースの対象範囲

範囲	リソースの対象
MEMORY	ユーザーの意図、前提、決定事項
CODEBASE	必要に応じた既存のプロジェクトコンテキスト
LOCAL_FS	承認済みの設計成果物。設計ドキュメント内の TRIZ-lite 付録は任意

前提条件

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

効果と副作用

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

ガードレール

1. 設計の承認前に実装や計画を行わない - ブレインストーミングでは、コードやタスク計画ではなく設計ドキュメントを作成します
2. 質問は一度に1つ - 利用可能な非同期の質問ツールを最初に使って、../_shared/core/clarification-protocol.md に従い、明確化と承認の質問をします。利用可能な質問ツールがない場合は、許可された別の質問ツールまたはプレーンテキストを使います。回答を待つ間も独立した作業を続け、沈黙や事前選択されたオプションから承認を推測してはいけません。
3. 実行可能なアプローチを比較する - 判断に役立つ場合は2つか3つ提示し、候補がそれより少ない場合は制約を説明します。実際の目標、作業量、可逆性、リスクに基づいて推奨します。名称だけを理由に、より大規模な構造変更を優先してはいけません。
4. 実行可能なアプローチを文章で説明する - 想定シナリオ、仕組み、残るリスク、作業量を示します。判断に役立つ場合は比較表を使ってから推奨案を提示します。制約により選択肢が1つしかない場合は、別案を作り出さず、その選択肢の根拠を説明します
5. セクションごとに設計する - 設計を段階的に提示します。既存の決定事項と委任された権限を再利用し、共通の実行ポリシーに従って、未解決の重要な選択についてのみ質問します
6. 保存前にブラインドレビューを実施する - 設計がごく小規模（ファイル1～2件、リスクが低い）な場合を除き必須です。各観点から独立して批評します。アーキテクチャ上重要な設計、変更が難しい設計、セキュリティやコンプライアンスに関わる設計では、新しいコンテキストを使うレビュアーのサブエージェントを利用します
7. YAGNI - 過剰設計を避け、提示された目標に必要なものだけを設計します
8. TRIZ-lite は任意 - 技術面または UX 面での矛盾や、同一軸での行き詰まりに限って使用します。厳選された原則から最大3～5個まで使用します。架空のスコア、完全版 TRIZ／ARIZ、古典的なマトリクスは使いません。導き出した案は Step 3 のブリーフに反映し、ユーザーの承認に代えることはできません
9. 設計を保存してから移行する - /plan に引き継ぐ前に、承認済みの設計ドキュメントを保存します

実行フェーズ

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

1. フェーズ 1 - コンテキスト：既存のコードベースを調査し、プロジェクト全体の状況を把握します
2. フェーズ 2 - 質問：意図と制約を理解するため、確認の質問を一度に 1 つずつ尋ねます
3. フェーズ 3 - アプローチ：実際の矛盾がある場合は、必要に応じて TRIZ-lite を用いて案を出します。実行可能なアプローチを文章で比較し、明示された制約、労力、可逆性、リスクに基づいて推奨案を示します
4. フェーズ 4 - 設計：既存の承認内容を維持し、未解決の重要な選択肢のみを解決しながら、設計をセクションごとに詳しく提示します
5. フェーズ 5 - ブラインドレビュー：設計の不確実性と重要度に応じた独立したレビュアーの視点を用い、Tier 1/2/3 の問題に整理します。保存前に Tier 1 の問題を解決します。重要度の高い設計では、初見のコンテキストを持つレビュアーのサブエージェントにエスカレーションします。非常に小規模な設計（ファイルが 1～2 個で、重要度が低い）の場合に限り、省略できます
6. フェーズ 6 - ドキュメント作成：承認済みの設計を docs/plans/designs/ とプロジェクトのメモリに保存します
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