vibe-brainstorm

Vibe Brainstorm

曖昧なクリエイティブな依頼を、アイデア、期待される動作、今後に引き継ぐ方向性やチェックリストに変換します。これは実装前の読み取り専用フェーズです。信頼できるプロキシが、後続の要件定義や計画に使う入力を選ぶ場合がありますが、ユーザーによる確認や実装の許可ではありません。

使用方法とモード

アイデア、代替案、インタラクションの動作、または規約に依存する実装を求められた場合に、このスキルを使います。機械的な編集、具体的な計画がある直接的なバグ修正、承認済みの実行、レビュー、保存済みの要件成果物には使いません。

状況	モード
diverge を明示している場合、またはアイデアのみを求めている場合	diverge
自律的な対応、または規約の確認を求めている場合	conventions
full を明示している場合、またはクリエイティブな目標を示して明示的に呼び出している場合	full

作業範囲を定めるためにアイデア出し、規約の根拠付け、選択のすべてが必要な場合を除き、自律的に full を選ばないでください。選ぶ場合は、その理由を説明してください。

視点と委任

デフォルトでは、個別の視点をローカルで用います。独立した作業や専門的なコンテキストが大きく役立ち、ホストが許可している場合にのみ委任してください。見出しや洗練された文章を根拠に、委任したと主張してはいけません。引用可能なホストの記録がある場合にのみ confirmed とし、それ以外の場合は unproven または利用不可と伝えてください。

委任するプロンプトでは、非公開の推論ではなく、簡潔な候補、トレードオフ、リスク、確認事項を求めてください。ユーザーが指定したスクリプトによるオーケストレーションの仕組みがあれば、その範囲を定めたスケジュールを計画するには十分です。スクリプトによる実行が可能であれば、アイデア生成、批評、展開、根拠付け、選択を網羅できますが、最終確認はチャットで行います。現在のホストが、ユーザー指定の実行を実際に呼び出すことも記録することもできない場合、コーディネーターが生成したブレインストーミング結果で代替しないでください。代わりに、計画した各段階、役割ごとの能力レベルの根拠、必要な実行・タスクの証拠、実行後に会話で確認する境界を提示してください。通常の視点収集では、独立性そのものが必要な場合を除き、コーディネーターが導き出したローカルな視点を示してください。独立性が必要な場合は、その制約を伝えてください。コーディネーターが導き出したローカルな視点は、このモード自体の作業であり、委任やフォールバックの許可は必要ありません。

モデルの選択

委任する作業単位ごとに、固定の名前で決めつけず、能力とコンテキストへの適合性に基づいてモデルを選択してください。

• ホストが許可しており、ユーザーがモデルを指定していない場合にのみ選択してください。
• 範囲が限定された曖昧さの少ない検索、抽出、機械的な確認に限り、より安価または高速なティアを使ってください。統合、敵対的なレビューやセキュリティレビュー、人間に関わるリスクの推論、最終的な推奨には、最適な能力を備えたティアを使ってください。ユーザーが最大限の性能を求めている場合も同様です。
• ユーザーによる上書き、能力の低下、コストまたは性能の制約、監査対象となる外部実行がある場合に限り、選択内容を記録してください。

クリエイティブな統合、規約に関するトレードオフ、選択、最終的な推奨には、より高い能力を備えたモデルが必要です。安価なティアが適するのは、範囲を限定した確認のみです。オーケストレーションのスケジュールでは、各役割に必要な能力とコンテキストを説明してください。このブロックに記載された記録条件に該当する場合を除き、ティアやモデルの名前は挙げず、挙げる場合は該当する条件も明記してください。

モード

diverge

Practical、Unconventional、Challenging の方向性を生成します。それぞれについて、適合性、トレードオフ、実装リスクを示してください。規約の根拠付け、順位付け、選択、推奨、実装の開始、方向性の実装の申し出は行わないでください。

conventions

動作を要約し、その後、必須の期待動作、任意の好み、不明点を分けたチェックリストを作成します。利用できる場合は、関連するローカル、提供済み、公式、またはドメインの情報源を根拠とし、各情報源がどの項目の根拠になっているかを示します。アクセスできない情報源と推論には、その旨を明記します。 必須とは、それが欠けると目標、実際の慣例、アクセシビリティ／安全性への期待、データ契約、または一般的なユーザーの期待に反するものを指します。 最も安価な実装方法を選ぶのではなく、重要な UX 上のトレードオフを明らかにします。チェックリストは AI が選んだ入力として次に引き継ぎます。ユーザーへの確認のために停止するのは、要求された動作またはスコープを追加、削除、変更する場合に限ります。依頼から暗黙に示される動作を明記することは、そのような変更には当たりません。

full

3 つの方向性を生成し、慣例のチェックリストを実施し、実現可能な候補を検討したうえで、次の基準で絞り込みます。必須条件に違反するものを却下し（該当する条件名を挙げるか、違反がないと明記します）、残った候補を創造性、適合性、実用性で順位付けします。方向性と、価値のある次点候補があれば推奨します。珍しいという理由だけで、型破りなアイデアを却下しないでください。ユーザーへの確認のために停止します。代理選択された方向性は、後続の要件定義や計画のための AI が選んだ入力にすぎません。

出力と境界

効果と書き込みの境界

フェーズで宣言された効果クラスと境界が許す範囲を超えて、何も書き込まないでください。

• フェーズ本文で宣言されている効果クラスを適用します。このパッケージでさらに狭い制限が定められている場合は、そちらを優先します。
• 読み取り専用：チャットで報告します。ファイルの編集、状態を変更するコマンドの実行、ステージング、コミット、タグ付け、プッシュ、バージョン変更、データ削除、サービスの起動は一切行いません。ファイルへの書き込みは、ユーザーが保存する成果物を明示的に求めた場合に限ります。
• 成果物のみ：フェーズが担当する成果物と、本文で宣言された補助パス（確認済みの計画への反映や意思決定記録など）だけを作成または更新し、作業ツリーに残します。
• 成果物のみのフェーズでは、実行可能な動作を実装したり、実装としてコードやテストを編集したり、別フェーズの成果物を作成したり、リリース作業を行ったり、成果物を同一ターンの実装権限として扱ったりしてはいけません。
• 状態変更あり：宣言されたスコープ内でのみ、最小の検証可能な単位で編集とコマンド実行を行います。ユーザーが選択しない限り、その他のパス、既存の変更、実行時状態、外部状態には手を加えません。
• これらの制限は、シェルコマンド（リダイレクト、sed -i、tee、mv、cp、rm、git checkout --）にもファイルツールにも適用されます。書き込みを拒否された場合は境界による停止として報告し、別のツールで再試行してはいけません。
• 取り消し不能な操作や外部に影響する操作は、それぞれ個別に同意を得てから行います。

ユーザーが保存する成果物を明示的に求めない限り、結果はチャットにとどめます。

応答の形式

モードと委任の状態を報告し、ローカルで作成した結果には「コーディネーター由来」と明記します。生成した場合はチェックリストと候補を示し、選択内容またはスキップした段階を記載します。正確なチェックリストまたは方向性を示し、それがユーザーの確認待ちなのか、AI が選んだ入力として次に引き継がれるのかを明記します。 結論、根拠、トレードオフ、未解決の質問を要約し、非公開の推論は含めません。

永続的な記録

確定した決定または保留中の所見を次に引き継ぐ場合に限り、その前に references/durable-records.md を読みます。このフェーズでは決定記録も所見記録も作成しません。後続の書き込みフェーズで記録されるまでは、このフェーズのパケットは永続化されません。

引き継ぎ

full の方向性をユーザーが選ぶ場合、または代理選択を行う場合、ならびにチェックリストによって要求された動作またはスコープを追加、削除、変更する場合のユーザー確認を待つ場合は、そこで停止します。それ以外の conventions のチェックリストは、待たずに AI が選んだ入力として引き継ぎます。 結果は引き継ぎ用パケットとして渡します。ユーザーの確認なしに実装、編集、ステージング、コミットを行ったり、承認済みとして扱ったりしてはいけません。