idea-genie

Idea Genie

アイデアに関する作業の標準的な起点です。根拠に基づく選択肢のポートフォリオを引き出すか、重要なアイデアに対して、互いに情報を共有しない独立した視点から異議を唱えます。どちらのモードも探索と助言を行いますが、作業の選定、スケジュール設定、追跡、実装、検証は行いません。

モード

起動フレーズ	モード	出力仕様
"idea genie", "what should we build next", "brainstorm options", "supported opportunities"	引き出し	idea-portfolio.v1
"challenge this idea", "compare independent proposals", "stress-test a one-way door"	対決	idea-challenge.v1

引き出しが最初のモードです。対決は、重要な選択に対する任意のエスカレーションで、通常は idea-portfolio.v1 または明確に定義された質問を入力として使用します。メンバーが互いのアイデアを採点する、複数メンバーによる採点付きの対決は、Council の対決モードです。計画の失敗要因を扱うのは Premortem です。

両方のバリデーターはこのスキルの scripts/ ディレクトリにあり、jq が必要です。jq がない場合は、形式に照らして各フィールドを手動で確認し、バリデーターを実行できなかったことを明記してください。

Elicit モード

以下のルールを遵守してください。

1. 観察事項には出典を付けます。 ファイルと行番号、イシュー、ドキュメント、または測定結果を示します。 出典のない内容はすべて仮定とし、別に列挙して、根拠としては決して使いません。
2. すべての候補に、それを裏付ける観察事項を引用します。 引用された根拠がなければ候補にしません。裏付けのないアイデアは仮定として列挙したままにしてもかまいません。数を満たすために候補を水増ししてはいけません。
3. 新規性を主張する前に、重複を確認します。 各候補を、製品がすでに実現していること、および今も有効な以前の決定（ADR、クローズ済みのイシュー、記録された教訓）と比較します。既存の機能ですでに対応できる要望は新規ではありません。候補を具体化するものであれば、その候補の overlaps に記録し、そうでなければ省きます。決定で却下されたアイデアを残す場合は、その理由に応える新たな根拠がある場合に限り、決定を overlaps に引用してください。
4. 候補ごとに Given／When／Then を1つだけ記載します。 通常ケースまたはエッジケースを選び、Then で引用した問題が緩和されることを示します。問題が残ったままでも成立する Then は、代理指標を狙っています。目標や症状は、まだ問題そのものではありません。その原因を引用するか、原因を仮定として列挙し、引用した症状が緩和されることを Then で示してください。
5. 順位付け、選定、スケジュール設定、作業の開始はしません。 呼び出し元または Plan が選定します。
6. 飽和したら終了します。 同等の候補は統合し、実質的に新しい根拠付き候補が加わる場合に限り、もう一度検討します。候補がゼロでも問題ありません。
7. 評価より先に生成します。 根拠から分かる構成要素に対象を分け、それぞれをディレクトリ一覧のような名前ではなく、対象自身の言葉で表現します。絞り込む前に、各要素について候補を作成します。そのうえで、ありがちな最初のアイデアを作り変えます。手順を取り除くか逆転させる、固定されたものと見なされた前提を崩す、制約を極端なところまで押し進める、別の分野が同じ問題をどう解決しているかを応用する、または後続の手順をより低コストにする方法を探します。どのプロジェクトにもそのまま当てはまる候補には、具体的な観察事項を付けるか、候補から外します。却下したアイデアごとに、その理由を dropped に1行で記録し、後の検討で再生成されないようにします。また、根拠のある候補がないままの要素もそこに列挙します。
8. 明言された関心より、実際の行動を重視します。 「ユーザーから要望があった」は、現在のユーザーの行動、すでに使っている回避策、それに伴うコスト、類似するものの導入状況に関する観察よりも弱い情報です。各候補が乗り越えるべき現状を明記します。現在、誰も問題を回避するための対処をしていない場合は、その旨を記載します。

まず、質問、制約、対象外の事項、出典を明示します。この質問に必要な出典だけを読み込み、引用してください。コンテキストを統合したストアは使いません。 名前を付けた要素（フロー、コマンド、ページ、ステージなど）の範囲内で、根拠が許すところまで検討を進めます。製品全体を作り変える候補はスコープ逸脱であり、対象を別の領域に置き換える候補は対象のすり替えです。引用した観察事項から、その要素を変えるにはそれが不可欠だと分かる場合を除き、いずれもその理由を付けて却下します。対象が指定されていない場合は、焦点を推測せず、トップレベルの各領域と最近のコミットを確認します。各候補の根拠から、その対象に注目する理由が分かるようにします。 ポートフォリオは次の形式で返します。

{
  "schema_version": "idea-portfolio.v1",
  "status": "candidates",
  "observations": [{"claim": "<what is true>", "evidence": "<cited source>"}],
  "assumptions": ["<belief no cited source supports>"],
  "candidates": [{
    "id": "I1",
    "evidence": ["<cited sources behind this candidate>"],
    "overlaps": ["<existing capability it extends or repeats>"],
    "scenario": {"given": "<state>", "when": "<event>", "then": "<observable result>"}
  }],
  "dropped": [{"idea": "<short name>", "reason": "<overlap, no evidence, or why it lost>"}],
  "termination": {"reason": "novelty-saturated", "novel_candidates_last_pass": 0}
}

overlaps は空でもかまいません。dropped は省略可能です。すべてのアイデアが重複するか、根拠を欠く場合は、status を no-new-work に設定し、candidates を空のままにして、termination.reason を all-overlap-or-unsupported に設定します。人に見せる場合は、同じフィールドを短いリストとして、候補ごとに1ブロックで表示します。ファイルが必要な場合は、.agents/scratch/ideas/<run-id>/idea-portfolio.json に書き込み、呼び出し元または Plan に渡す前に scripts/validate-output.sh を実行します。既存のビーズまたは呼び出し元の意図に選択肢を組み込めるのは Plan のみです。

対決モード

重大な選択に対する独立した課題を作成します。その結果は Plan に提供する助言のための根拠です。計画の準備が整っているかどうかを決めるものではなく、後から任意で実施する Premortem の課題を承認ゲートに変えることもありません。

ドアの分類。 選択が実行された後に取り消す場合のコストを確認します。一方通行のドアとは、移行が必要になる、公開済みの契約や呼び出し元に影響する、データを失う、または取り消せない外部への影響があるものです。安価な双方向のドアは、リバートやフラグで元に戻せるものです。

制約

• 生成時の封印：すべてが完了するまで、どの視点もほかの視点を見られません。そのため、後の提案が先行する提案に引きずられることはありません。
• 反対意見、反証の失敗、少数意見の論拠を保持します。Plan には、統合によって消されるおそれのある代替案も提示する必要があります。
• 双方向のドアは軽量に保ちます。ペインマネージャー、メッセージングサービス、協議会、モデルファミリーのルールは設けません。
• 準備状況、承認、定足数、再試行、予算、ヘルパー、配信、トラッカーの状態は出力しません。この戦略が提供するのは根拠であり、ライフサイクルの権限ではありません。合意、通信手段の利用可能性、自己評価のいずれも、準備状況にはなりません。

ワークフロー

1. 質問、制約、根拠のパス、比較基準を固定します。不明点は未確定のままにします。あるアプローチだけが必要とする前提は、そのアプローチにのみ紐づけます。共有制約に含めると、競合する案を気づかないうちに除外してしまいます。
2. 一方通行のドアの場合、少なくとも 2 つの新しいコンテキストを開始します。共有トランスクリプトのない別々のサブエージェントまたはセッションを使い、それぞれに、固定した質問と根拠のパスを含むプロンプトを 1 つずつ渡して、封印された視点の形式で回答するよう求めます。各ネイティブコンテキスト ID を context_id として記録し、いずれかを開示する前にすべての視点を収集します。呼び出し元が視点をモデルプロファイルに紐づける場合は、各 model_identity を記録します（agent-native のモデルディスパッチのレシピを参照）。利用できないプロファイルを明示し、単一モデルで続行します。
3. 封印された視点を開示し、根拠、可逆性、システムとの適合性、障害モード、コストに基づいて相互レビューします。視点は名前ではなく仕組みで比較します。同じ仕組みに依存する 2 つの案は、代替案として 1 つと数えます。異なる案が 2 つ未満の場合、比較は不完全であり、勝者が決まったわけではありません。制限付きの復旧を 1 回行う場合は、収束を参照してください。固定した制約に違反する視点は、ほかにどのような長所があっても対象外です。複数の視点から要素を組み合わせた案は、引き継ぐ裏付けのない新たな候補です。それを記載する前に、統合した設計が必要とする保証を具体例ごとに検証するか、未確認として記載し、Plan が根拠なく組み合わせないようにします。
4. 具体的な反証を試みます。固定した質問の前提をすべての視点が採用している場合、その前提について各視点が合意しても裏付けにはなりません。情報源で確認します。状態を持つ仕組みは、文章ではなく状態トレースで反証します。意見の相違、反証の失敗、少数意見の論拠を明示して残します。
5. idea-challenge.v1 を作成して検証し、調査結果およびオペレーターの意図と並ぶ、任意の入力の 1 つとして Plan に渡します。

安価な双方向のドアの場合は、新しい課題を 1 つ実施した後、軽量なパケットを直接出力します。委員会めいた儀式を作り出さないでください。

出力仕様

• 成果物ディレクトリ： .agents/scratch/ideas/<run-id>/
• ファイル名： idea-challenge.json
• 形式： 以下の2つの形式のいずれかの idea-challenge.v1 JSON。準備状況フィールドや決定は含みません。
• 検証コマンド： scripts/validate-challenge.sh <idea-challenge.json>
• 後続の引き継ぎ： handoff.owner は必ず plan にします。Plan は、助言的な証拠を受け入れる、却下する、または組み合わせることができます。

一方向パケット：

{
  "schema_version": "idea-challenge.v1",
  "door_class": "one-way",
  "sealed_generation": true,
  "perspectives": [
    {"id": "P1", "context_id": "<native context id>", "proposal": "<mechanism, evidence, tradeoff>"},
    {"id": "P2", "context_id": "<a different context id>", "proposal": "<mechanism, evidence, tradeoff>"}
  ],
  "cross_reviews": [{
    "reviewer": "P1",
    "subject": "P2",
    "dimensions": {"evidence": "<finding>", "reversibility": "<finding>", "system_fit": "<finding>", "failure_modes": "<finding>", "cost": "<finding>"}
  }],
  "disagreements": ["<where the perspectives still differ>"],
  "refutations": [{"claim": "<what was attacked>", "attempt": "<the concrete test>", "result": "<what the attempt showed>"}],
  "handoff": {"owner": "plan", "artifact_dir": ".agents/scratch/ideas/<run-id>/"}
}

少なくとも2つの視点が必要です。それぞれに固有の id と異なる context_id を設定します。視点には model_identity とその提案を含めることもできます。 cross_reviews、disagreements、refutations には、それぞれ少なくとも1つのエントリーが必要です。各クロスレビューには、異なる2つの視点 ID と1つ以上の評価軸を指定します。指定した各評価軸には、空でないテキストの所見が必要です。各意見の相違は空でない文字列とし、各反論には claim、attempt、result のすべてを入力します。 一方向パケットでは requires_ntm を省略してください。

双方向パケットでは sealed_generation を false にし、4つのリストをすべて空にします。また、ペインマネージャーが不要だったことを記録するために "requires_ntm": false を追加し、ルートを指定します。

{
  "schema_version": "idea-challenge.v1",
  "door_class": "two-way",
  "sealed_generation": false,
  "perspectives": [],
  "cross_reviews": [],
  "disagreements": [],
  "refutations": [],
  "requires_ntm": false,
  "handoff": {"owner": "plan", "artifact_dir": ".agents/scratch/ideas/<run-id>/", "route": "single-fresh-context"}
}

双方向パケットにはチャレンジではなくルートを記録するため、新しいチャレンジの所見を添えて Plan に渡してください。バリデーターはこれ以外のトップレベルフィールドを拒否します。また、handoff には owner、artifact_dir、route のみを指定できます。

参考資料

• Idea Genie の動作
• Idea challenge の動作
• Sealed perspectives