ブレインストーミング (brainstorm)
あいまいな問題を構造化された候補ADRと計画アイテムのセットに変換します。このスキルは生成専用であり、読み取り/提案のみです — ADRや計画ファイルを直接書き込むことは決してありません。承認されると、各候補を new-adr スキルと new-plan スキルに引き渡します。
ステップ 0 — 前提条件とコンテキスト
- リポジトリがブートストラップされていることを確認する（または、出力を新しい bootstrap スキルの実行のシードとして使用できることに注意する）。
- ADRの形状とライフサイクルについて
CONVENTIONS.mdを読み、INDEX.mdと既存のADRをざっと確認して、候補が既存のものと重複したり矛盾したりしないようにし、依存関係が実際のADRを指すようにする。
ステップ 0.5 — 評価（最初に実行）
分解を開始する前に、共有評価プロトコルを実行します。
-
最初に提供された回答を再利用します。 リクエストまたはこのセッションですでに提供されている該当する選択肢（深さを含む）は、回答済みとして扱います。再度質問することなく要約します。デフォルトが明示的な選択肢に代わることは決してありません。すべての重要な選択肢が提供されている場合は、先に進みます。重要な選択肢が欠落しているか競合している場合にのみ質問します。リポジトリの設定だけでは、現在の回答や実行許可にはなりません。
-
未解決の選択肢のための深さセレクター。 深さが提供されておらず、選択肢が残っている場合は、この評価をどの程度の深さで行うかを尋ねます。express（簡易） — すべての選択肢は推奨されるデフォルト値を採用します。導出可能なデフォルトがない質問（自由記述の必須項目）のみが引き続き尋ねられます。guided（ガイド付き） — 以下の高影響とマークされた質問と、自由記述の必須項目のみ。full（詳細） — 以下のすべての質問。リポジトリの
CONVENTIONS.mdにAssessment depth:が記録されている場合は、質問時に推奨オプションとして事前選択します。記録された深さが黙って適用されることは決してありません。それ以外の場合は、リクエストがほとんどまたはまったくコンテキストなしで到着した場合は full を推奨し、すでに完全に指定されている場合は express を推奨します。どの質問でも、オペレーターは「ここからデフォルト」または「より深く」と答えることができます。その指示にすぐに従います。 -
以下の質問を1つずつ、それぞれに推奨オプションと1行の理由を付けて尋ねます。各回答を待ちます。
-
構造化選択（単一選択または複数選択）を使用します。ホストが構造化された単一選択/複数選択の質問ツールを公開している場合は、それを使用して推奨オプションをマークします。それ以外の場合は、プレーンテキストでオプションA/B/Cを一覧表示し、推奨するものを指定します。自由記述は、列挙可能なセットが不可能な場合（目標の記述など）にのみ使用します。
-
オペレーターが決定します。 回答なしで質問を先に進めたり、コンテキストなしで呼び出された場合に範囲を推測したりしないでください。
質問（リクエストですでに回答されているものはスキップ）：
- 目標 / 問題 — 自由記述（避けられない自由回答。すべての深さで質問）まだ与えられていない場合。
- 成果物 — 候補ADRのみ、またはADR + 計画アイテム。推奨: ADR + 計画アイテム。
- 分解の深さ — クイック（主要な候補）または詳細（完全な分解）。推奨: 最初にクイック、必要に応じて拡張。
このスキルの質問には高影響とマークされたものはありません。guided 実行は express と同様に動作します。
このスキルは、あなたが概要を承認するまで何も書き込みません。
ステップ 1 — 問題を理解する
目標/機能/問題が与えられていない場合は尋ねます。スコープの境界、制約、およびこのリポジトリに関連する規制/品質上の懸念事項を探ります。目標が明確になるまで分解を開始しないでください。
ステップ 2 — 分解する
候補リストを作成します。各候補ADRについて：
- 提案番号（次の利用可能な連続番号）、作業タイトル、形状（リポジトリが区別する場合、機能 vs 技術）。
- 1行のスコープ — それが捉える単一の決定。
- 他の候補または既存ADRへの依存関係。
1つのADRに1つの決定。 候補が複数の決定を束ねている場合は、分割してその理由を説明します。候補が実際には改訂が必要な既存のADRである場合は、新しい番号を提案する代わりにその旨を伝えます。
ステップ 3 — 作業を順序付ける
依存関係エッジを尊重した計画の順序（どの plan/todo/ アイテムを、どの順序で）を提案します。並列化可能な作業に注意します（agent-wave スキルへの有用な入力）。
ステップ 4 — レビューと引き渡し
完全なセットをレビュー可能な概要（候補 + 依存関係 + 順序）として提示します。編集を受け付けます。まだ何も書き込みません。 ユーザーが承認したら、各候補に対して new-adr スキルを、キューされた各アイテムに対して new-plan スキルを呼び出して作成します。または、承認された概要をそれらのスキルに引き渡します。
ガードレール：問題が漠然としていて、要件を発明せずに分解できない場合は、推測のADRを作成するのではなく、その旨を伝えてもっと情報を求めます。
合意されたオプションと残っている決定に名前を付けます。議論だけでは成果物は作成されません。
クロージングレポート
ブロック、失敗、停止を含むすべての実行の最後に、厳密に Status at a glance という見出しのセクションを付け、以下の3つのラベルを含めます。
- この実行: 実際に試行されたアクションとその結果のみ。各検証ゲートの正確な出力と終了コード（タイムアウトや中断を含む）を引用します。
- 全体: 実装済み、部分的に検証済み、検証済み、ブロック、失敗、不明のいずれか。サブステップのパスは全体のパスではありません。不完全または欠落している証拠が成功になることは決してありません。
- 未完了: 残っているすべてのアクション、未解決の調査結果、検証、クリーンアップ、または必要な入力。タスク全体が検証可能に完了している場合のみ None と記述します。予算が終了したために作業を省略することは決してありません。
ルーチンの進捗メッセージにはブロックは必要ありません。最終結果は簡潔に保ち、PR上で準備された作業と、出荷が確認された作業を区別します。