Skill: warmskull/idea-darwin-ja (version 1.0.0)

--- name: idea-darwin-ja version: 1.0.0 emoji: 🧬 homepage: https://github.com/warmskull/idea-darwin description: > Idea Darwin エンジン（日本語版）— 生のアイデアを進化論ベースで自動反復するシステム。深化・交配・変異のラウンドを実行し、高ポテンシャルなアイデアを浮上させます。/idea-darwin で起動。 --- # Idea Darwin エンジン ラウンドベースのアイデア反復システム。アイデアを競い合う生物として扱い、スコアリング、選択、交配、進化を構造化されたラウンドを通じて実行し、最も強いコンセプトを浮上させます。 メタファーはダーウィンの自然選択：高スコアのアイデアは生き残り進化し、弱いアイデアはユーザーの判断を仰ぐためにフラグが立てられ、交配は新しい子孫を生み出します。これにより、ブレインストーミングでありがちな「すべてのアイデアが永遠に同じように曖昧なまま」という失敗パターンを防ぎます。 ## コマンド | コマンド | 説明 | |---|---| | `/idea-darwin init` | 初期化：ideas.md を解析し、ディレクトリ構造、設定、初期カードを作成（オプションパラメータは下記） | | `/idea-darwin round` | 次の反復ラウンドを実行 | | `/idea-darwin round N` | N 回連続でラウンドを実行 | | `/idea-darwin status` | アイデアプールの状態とランキングを表示 | | `/idea-darwin dormant IDEA-XXXX` | 特定のアイデアを休眠させる | | `/idea-darwin wake IDEA-XXXX` | 休眠中のアイデアを覚醒させる | | `/idea-darwin` | 引数なし：現在の状態を簡潔に表示し、次のステップを提案 | 引数は `$ARGUMENTS` から抽出されます。引数が指定されない場合は、現在の状態と提案を表示します。 ### init オプションパラメータ | パラメータ | 説明 | デフォルト | |---|---|---| | `--budget <N>` | 1ラウンドあたりの最大処理アイデア数 | `12` | | `--actions <N>` | 各アイデアの1ラウンドあたりの最大アクション数 | `2` | | `--disruption <N>` | N ラウンドごとに外部刺激を導入（撹乱ラウンド） | `3` | 例：`/idea-darwin init --budget 8 --actions 3 --disruption 5` これらのパラメータは config.yaml に書き込まれ、後から手動で編集可能です。指定されないパラメータはデフォルト値が使用されます。 ## ファイル構造 システムは作業ディレクトリに以下の構造を維持します（初期化時に作成）： ``` project/ ├── ideas.md # ユーザーの生のアイデア（読み取り専用 — このファイルは絶対に変更しない） ├── config.yaml # システム設定と状態 ├── stimuli.md # 外部刺激エントリ（ユーザーが編集、システムは読み取り専用） ├── cards/ # アイデアカード │ ├── IDEA-0001.md │ └── ... ├── rounds/ # ラウンドレポート │ ├── round-000.md │ └── ... ├── reports/ # リーダーボードとクラスターレポート │ └── leaderboard.md └── graph/ # 関係グラフ └── relations.json ``` ## アイデア採番 - 形式：`IDEA-XXXX`（4桁ゼロ埋め、0001から開始） - グローバルにユニーク — 休眠や削除されたアイデアでも番号は再利用しない - `config.yaml` の `next_idea_id` で次の利用可能な番号を管理 - 各アイデアカードは `parent_ids` と `child_ids` で系譜を記録 ## アイデア状態マシン ``` seed → exploring → refining → crossing → validated → dormant ``` | 状態 | 意味 | 利用可能なアクション | |---|---|---| | seed | プールに入ったばかり | タグ付け、カード生成、深化、簡易交差検証 | | exploring | 探索フェーズ | 深化、派生、批評、予備交配 | | refining | 洗練フェーズ | ロジック強化、実現可能性分析、リスクチェック | | crossing | 高交配フェーズ | 補完的なアイデアとの統合、融合品質の評価 | | validated | 検証済み | MVP計画の出力、実行ロードマップの生成 | | dormant | 休眠中 | 交配と類似性マッチングへの受動的参加のみ | 状態遷移はスコアとアクション結果に基づいてシステムが推奨しますが、最終決定権は常にユーザーにあります。 ## スコアリングシステム ### 6つのスコアリング次元（各1〜10） | 次元 | 重み | 意味 | |---|---|---| | 新規性 (Novelty) | 0.10 | 本当のブレイクスルーがあるか、それとも単なる繰り返しか？ | | 実現可能性 (Feasibility) | 0.20 | 技術的、リソース的、パス的に達成可能か？ | | 価値 (Value) | 0.20 | 成功した場合、どれだけのインパクトを生み出せるか？ | | 論理性 (Logic) | 0.20 | 内部的に一貫しており、明らかなギャップがないか？ | | 交配ポテンシャル (CrossPotential) | 0.10 | 他のアイデアと組み合わせたとき、新しいものを生み出す可能性は？ | | 検証可能性 (Verifiability) | 0.20 | 実験や最小検証パスを設計できるか？ | ### 三層スコアリング計算式 スコアリングは三層構造になっており、各層が異なる戦略的視点を捉えます — Survival は単独の品質を測定し、Development は成長ポテンシャルを測定し、Priority は両方を新鮮度と多様性ボーナスで統合してプールの停滞を防ぎます。 ``` Survival = 0.10×Novelty + 0.20×Feasibility + 0.20×Value + 0.20×Logic + 0.10×CrossPotential + 0.20×Verifiability Development = 0.30×Novelty + 0.30×CrossPotential + 0.20×VariationPotential + 0.20×Freshness Priority = 0.50×Survival + 0.30×Development + 0.10×NewIdeaBoost + 0.10×DiversityBonus ``` - **VariationPotential**（0〜10）：このアイデアがまだ分岐できる異なる方向の数。子が派生するにつれて減少する。 - **Freshness**（0〜10）：このアイデアは最近変更されたか？数ラウンド処理されないと減衰する。 - **NewIdeaBoost**：新しくプールに入ったアイデアは最初の2ラウンドで+2、その後0。 - **DiversityBonus**：プール内で少数派のカテゴリに属するアイデアは+1〜2。 スコアリング時は、`references/prompts.md` のプロンプトテンプレートを参照してください。 ## 初期化フロー ユーザーが `/idea-darwin init` を実行した場合： 1. **ideas.md の検索** - カレントディレクトリに ideas.md が存在するか確認 - 見つからない場合は `AskUserQuestion` でパスを尋ねる 2. **ディレクトリと設定の作成** - cards/, rounds/, reports/, graph/ を作成 - config.yaml を生成（ユーザー指定のオプションパラメータをマージ、未指定はデフォルト使用）： ```yaml source: ideas_file: "./ideas.md" counter: next_idea_id: 1 current_round: 0 schedule: max_ideas_per_round: 12 # --budget max_actions_per_idea: 2 # --actions disruption: trigger_every_n_rounds: 3 # --disruption wildcard_budget_ratio: 0.10 ``` - プロジェクトルートに `stimuli.md`（外部刺激ファイル）を生成し、初期テンプレートと編集手順を含める 3. **ideas.md の解析** - 各独立したアイデアを識別（通常 ## 見出しで区切り） - **ideas.md は変更しない** — 常に読み取り専用 4. **各アイデアのカード生成** - ID を割り当て（IDEA-0001 から開始） - タグ付け（トピック / 問題タイプ / ステージ / スタイル / リソースタグ） - `assets/card-template.md` のフォーマットに従って完全なカードを生成 - 初期スコアリング（6次元 + 3層複合スコア） - cards/IDEA-XXXX.md に書き込み 5. **round-000.md レポートの生成** - 全初期カードの要約、スコア、推奨次アクションを一覧化 - rounds/round-000.md に書き込み 6. **結果をユーザーに提示** - 全カードの一覧表（ID、タイトル、スコア、推奨アクション）を表示 - `stimuli.md` とその使い方をユーザーに説明： > `stimuli.md` がプロジェクトルートに作成されました。N ラウンドごとに、システムは有効なエントリから最大5つをランダム選択し、外部刺激として思考の固定化を打破します。 > いつでもこのファイルを編集してエントリの追加/変更/無効化ができます。各エントリのフォーマット： > ``` > ## [エントリタイトル] > - status: enabled / disabled > - [内容の説明] > ``` - 正式なラウンドサイクルに入る前にユーザーの確認を待つ ## ラウンド実行フロー ユーザーが `/idea-darwin round` を実行した場合、以下の9ステップを厳密な順序で実行： ### ステップ1：新規アイデアのインポート - **毎ラウンド開始時にデフォルトのアイデアドキュメントを確認**：config.yaml の `source.ideas_file` が指すファイルを読み込む - デフォルトの ideas.md と既存カードを比較し、新規追加を特定 - 新規アイデア：タグ付け → カード生成 → 初期スコアリング - 新規アイデアは `stage: seed` としてマークされ、NewIdeaBoost を受ける - **これは毎ラウンドの必須前処理ステップ** — ソースファイルへの追加を無視して既存カードのみをループすることは許されない ### ステップ2：関係グラフの更新 - 全カードのタグとコンテンツに基づき、アイデア間の類似度を計算 - 交配候補を特定（高類似度 = 近接交配候補、低類似度だが補完的 = 遠隔交配候補） - graph/relations.json を更新 ### ステップ3：グローバルスコアの更新 - すべての**アクティブな**アイデア（休眠中は除く）の6次元スコアを再計算 - Survival / Development / Priority を更新 - フラグ付け：高ポテンシャル（Priority > 7）、停滞（3ラウンド以上変化なし）、低ポテンシャル（Priority < 3） ### ステップ4：バジェット配分 `max_ideas_per_round` に従ってスロットを配分： - 25% を新規プール入りアイデアに - 30% を高優先度アイデアの深化に - 20% を高ポテンシャルアイデアからの派生に - 15% を交配実験に - 10% を撹乱/ランダム探索に Priority Score の降順でアイデアを選択。各アイデアは最大 `max_actions_per_idea` アクション。 ### ステップ5：アクション決定 選択された各アイデアに対し、状態マシン（上記テーブル参照）に基づいてアクションを割り当て。 状態マシンで不十分な場合、スコア駆動ルールを使用： - `高新規性 + 低検証可能性` → 深化 - `高新規性 + 高交配ポテンシャル` → 交配 - `高価値 + 低実現可能性` → 批評 + 洗練 - `高実現可能性 + 低論理性` → 深化 - `高重複` → 統合 ### ステップ6：アクション実行 選択された各アイデアを順番に処理。詳細な実行仕様は `references/actions.md`、プロンプトテンプレートは `references/prompts.md` を参照。 **アイデアごとの実行フロー：** 1. カード全文を読み込む 2. アクションタイプに対応するプロンプトテンプレートに従い — 深く思考する 3. 構造化された出力を生成： - 更新されたカード内容 - 新しい派生アイデア（自動ID割り当て、双方のparent_ids/child_idsを更新） - スコア変動 - 発見されたリスク - 推奨次アクション 4. 更新されたカードファイルを書き込む 新しく派生したアイデアもカード全体の生成と初期スコアリングが必要。 ### ステップ7：検証と重複排除 - 新しく生成されたすべてのアイデアに**二層検証**を実行： - 第1層（致命的欠陥チェック）：論理的矛盾？実需なし？完全に実現不可能？ほぼ重複？ - 第2層（価値判断）：継続する価値はあるか？次は何をすべきか？最大のリスクは？ - 検証失敗 → `validated: false` をマーク、優先度を下げ、ユーザーに報告 - **ユーザーが** 休眠か削除かを決定 — システムは推奨するのみ - プール全体の類似性チェックを実行し、ほぼ重複するものを統合 ### ステップ8：ラウンドレポートの生成 `rounds/round-XXX.md` に書き込み。内容： - 今ラウンドで処理されたアイデアと実行されたアクション - 新しく生成されたアイデアの要約 - スコア変動トップ5（上昇/下降） - 検証に失敗したアイデア（ユーザーの判断が必要） - 次ラウンドの推奨優先事項 - 撹乱ラウンドの場合：使用された外部刺激、適用されたイノベーションフレームワーク ### ステップ8.5：ラウンドブリーフィングの出力 すべてのファイル更新が完了した後、**会話内にラウンドブリーフィングを直接出力**（ファイルには書き込まない）し、ユーザーがファイルを開かずに全体像を把握できるようにする。フォーマット： ``` ## ラウンド N ブリーフィング ### 実行されたアクション | ID | タイトル | アクション | 主な出力 | |---|---|---|---| | IDEA-XXXX | ... | 深化/派生/交配/批評/... | 一行の要約 | ### カード変動 | ID | タイトル | スコア変動 | 状態変化 | 備考 | |---|---|---|---|---| | IDEA-XXXX | ... | Priority X.XX→X.XX | seed→exploring | 変動理由 | ### 新規アイデア（詳細） 今ラウンドで新しく生成された各アイデア： #### IDEA-XXXX: [タイトル] - **ソース**: [交配/派生/刺激] IDEA-XXXX + IDEA-XXXX から - **コアクエスチョン**: [1段落] - **キーインサイト**: [このアイデアで最も価値のあるもの] - **初期スコア**: Priority X.XX (Survival X.XX / Development X.XX) - **現在のテンション**: [最大の未解決問題] - **推奨次ステップ**: [深化/派生/交配/批評 + 具体的な方向] ### 現在のランキング | 順位 | ID | タイトル | Priority | ステージ | |---|---|---|---|---| ### 次ラウンドプレビュー - [推奨優先アクション] - [撹乱ラウンドが近づいているかどうか] ### 判断が必要な事項 > 今ラウンドでユーザーが判断すべき重要事項を列挙。各項目にはアイデアの**フルタイトル**（IDだけでなく）を含め、コンテキストと推奨選択肢を添える。 > 例： > 1. **IDEA-0002「コーディング学習エージェントチュートリアルサイト」が IDEA-0004「段階的アンボックス教育法」と重複** — 統合するか差別化するか？推奨：[...] > 2. **IDEA-0006「自動診断スレッド」が検証に失敗** — 休眠、方向転換、または経過観察？ > 3. **IDEA-0003「熱管理オントロジー」が格下げ** — オントロジーから構造化Excelへの第一歩としての格下げを受け入れるか？ > > 今ラウンドでユーザーの判断が不要な場合は「今ラウンドで判断が必要な事項はありません。」と記載。 ``` このブリーフィングはユーザーとシステム間の主要なインターフェース — 完全で読みやすくすること。「判断が必要な事項」セクションは最も重要なインタラクションポイント：システムは推奨と共に判断事項を明確に列挙し、ユーザーがレポートから問題を発見するのに任せない。 ### ステップ9：状態の保存 - 変更されたすべてのカードファイルを更新 - config.yaml の `current_round` をインクリメント - `next_idea_id` を更新 - reports/leaderboard.md を更新（トップ10ランキング） ## 外部刺激と撹乱ラウンド `trigger_every_n_rounds` ラウンドごと（デフォルト3）に、「撹乱ラウンド」で外部刺激が導入されます。目的は、新鮮な視点を強制することで、アイデアプールが局所最適に収束するのを防ぐことです。 ### 外部刺激ファイル（stimuli.md） `stimuli.md` はプロジェクトルートにあります。初期化時に作成され、ユーザーが管理します。フォーマット： ```markdown ## 業界トレンド：身体性AIの量産加速 - status: enabled - 身体性AIが2026年にラボから量産ラインへ移行、ロボットの運用コストが60%削減 ## テックシフト：統合マルチモーダルモデルアーキテクチャ - status: enabled - ビジョン、言語、コードが単一モデルに統合、APIパラダイムが変化 ## 逆張りの視点：SaaSは終わった - status: disabled - オープンソース + セルフホスト型デプロイが従来のSaaSサブスクリプションを置き換え ``` - 各エントリ：`##` 見出し + `status` フィールド + 内容の説明 - `enabled` = ランダム選択に参加、`disabled` = スキップ - ユーザーはいつでもエントリの追加、編集、切り替えが可能 - システムはこのファイルを読み取り専用 — 書き込みしない ### 撹乱ラウンドのメカニクス 1. **優先順位のシャッフル**：低優先度だが新規性の高いアイデアに浮上の機会を与える 2. **遠隔交配**：タグが重複しないアイデア間の交配を強制 3. **外部刺激**：stimuli.md から有効なエントリを最大5つランダム選択 4. **前提の逆転**：トップスコアのアイデアに「核心的な前提が間違っていたらどうなる？」と問いかける 5. **イノベーションフレームワーク**：SCAMPER / 第一原理 / 類推的転移 / 制約逆転 / 極端なユーザー視点を適用 各ラウンドでは、非最適パスの探索用に `wildcard_budget_ratio`（デフォルト10%）のスロットも確保。 ## 休眠と覚醒 ### `/idea-darwin dormant IDEA-XXXX` 1. カードを読み込み、ステージを `dormant` に設定 2. 理由とラウンド番号をカードの「休眠ログ」に記録 3. そのアイデアは深化/派生の選択対象にならないが、交配と類似性マッチングには引き続き参加 ### `/idea-darwin wake IDEA-XXXX` 1. カードを読み込み、休眠前の状態に復元（履歴から推定、通常は `exploring`） 2. 「休眠ログ」を更新 システムは**決して**アイデアを自動休眠させません。その判断ができるのはユーザーだけです。 ## `/idea-darwin status` config.yaml と全カードを読み込み、以下を出力： - 現在のラウンド番号 - プール内の総アイデア数（状態別内訳） - トップ10ランキング（Priority Score 降順） - 直近のラウンドで処理された内容 - 推奨次ステップ ## 主要な制約 1. **ideas.md は読み取り専用**：ユーザーの ideas.md を絶対に変更しない 2. **ID は再利用しない**：いかなる状況でも番号を再利用しない 3. **分岐制限**：各アイデアは1ラウンドあたり最大2〜3の子を派生 4. **ラウンドごとの重複排除**：ラウンド終了前に類似性チェックが必須 5. **ユーザーコントロール**：システムはアイデアの自動休眠や削除をしない — 推奨するのみ 6. **構造化された出力**：すべてのアクションは構造化された結果を生成しなければならない 7. **一貫したカードフォーマット**：すべてのカードは `assets/card-template.md` に厳密に従う 8. **追跡可能なレポート**：すべてのラウンドレポートは完全な操作ログを含む ## 参考ファイル - `references/actions.md`：各標準アクションの詳細仕様とユースケース - `references/prompts.md`：各アクションのプロンプトテンプレート - `assets/card-template.md`：カードファイルテンプレート

path: assets/card-template.md
content: # アイデアカードテンプレート

---
id: IDEA-XXXX
title: ""
status: seed
stage: seed
round_created: 0
parent_ids: []
child_ids: []
tags: []
last_action: ""
last_round: 0
scores:
  novelty: 0
  feasibility: 0
  value: 0
  logic: 0
  cross_potential: 0
  verifiability: 0
  survival: 0
  development: 0
  priority: 0
---

## コアクエスチョン

このアイデアが答えようとしている根本的な問いは何か？

## 完全な説明

2〜4段落で以下をカバーして記述：

- このアイデアはどのように生まれたか？
- なぜ重要なのか？
- 現時点で最も有望な形は何か？

## 現在のテンション

- このアイデアが現在直面している最も重要な矛盾や未解決の問いは何か？

## さらなる深化の方向性

- 方向性 1
- 方向性 2

## 交配候補

- 交配の潜在的パートナー：
- この交配が探索に値する理由：

## 変更ログ

- ラウンド X：変更内容の説明

## 休眠ログ

- このアイデアが以前休眠されたことがあるか：
- 直近の休眠理由：


path: references/actions.md
content: # 標準アクションリファレンス

このファイルは、Idea Darwin エンジンの各標準アクションの目的、適用シナリオ、実行要件を説明します。

## 1. タグ付け

**目的**：スケジューリング、類似性マッチング、交配のためのアイデア分類を標準化する。

**タグの次元**：
- トピックタグ：AI / 教育 / SaaS / コンテンツ / クリエイターエコノミー / ...
- 問題タイプ：効率化 / イノベーション / ビジネス検証 / コラボレーション / 自動化
- ステージタグ：seed / exploring / refining / validated / dormant
- スタイルタグ：高イノベーション / ハイリスク / 実用的 / 研究志向 / プラットフォーム型
- リソースタグ：低コスト / 高コスト / データ依存 / エンジニアリング重視 / ユーザーオペレーション必要

**実行要件**：
- 各アイデアには最低3つ、最大8つのタグが必要
- タグは具体的に — 広すぎるラベルを避ける（例：「テクノロジー」は曖昧すぎる、「自然言語処理」を使用）
- タグはカードの YAML フロントマター `tags` フィールドに記入

---

## 2. カード生成

**目的**：自然言語のアイデアをシステムが処理できる構造化カードに変換する。

**生成内容**：
- コアクエスチョン：このアイデアが本当に答えようとしているものは何か？
- 完全な説明：起源、重要性、現時点で最も有望な形をカバーする2〜4段落
- 現在のテンション：重要な矛盾や未解決の問い
- 深化の方向性
- 交配候補

**実行要件**：
- `assets/card-template.md` のフォーマットに厳密に従う
- コアクエスチョンは明確で適切に構成された問いでなければならない
- 完全な説明は構造化された蒸留であり、元のテキストのコピーペーストではない

---

## 3. 深化

**目的**：曖昧なアイデアを明確にし、粗いアイデアを完全にする。

**使用タイミング**：
- アイデアにポテンシャルがあるが表現が不十分
- ロジックが不完全
- ターゲットユーザー、シナリオ、パスの特定が必要

**深化の角度**：
- 5W1H（誰が / 何を / どこで / いつ / なぜ / どのように）
- 第一原理分解
- ユーザーシナリオの具体化
- 技術ロードマップのマッピング
- ビジネスモデルの探索
- リスクと制約の特定
- MVPパスの設計
- 失敗ポイントの列挙

**実行要件**：
- これは書き直しではない — 論理的なギャップを埋めること
- アイデアの核心的意図を保持する
- 出力には以下を含む：充実した説明、核心的前提、ユーザーシナリオ、MVPバージョン、リスク、推奨次アクション
- カードの「完全な説明」と「さらなる深化の方向性」を更新

---

## 4. 派生

**目的**：アイデアをバリアントに分割し、探索空間を拡大する。

**派生の次元**：
- 異なるユーザーセグメント
- 異なるビジネスモデル
- 異なる技術的実装
- 異なるシナリオ
- 異なる難易度
- 異なるプロダクト形態
- 異なるタイムホライズン（短期 / 長期）

**実行要件**：
- 1回の派生で2〜3の子アイデアを生成（組み合わせ爆発を防ぐため3を超えない）
- 各子は親のコアDNAを保持しつつ、明確な差別化要因を持つ
- 単に言い換えただけの重複バリアントを生成しない
- 各子には新しい IDEA-XXXX IDが自動的に割り当てられる
- 親の `child_ids` と各子の `parent_ids` を更新
- 各子にはカード全体の生成と初期スコアリングが必要

---

## 5. 交配 / ハイブリダイズ

**目的**：異なるアイデアを融合し、新しい視点を生み出す。

**2つのタイプ**：
1. **近接交配**：類似アイデアとの交配 → 収束的最適化
2. **遠隔交配**：無関係なアイデアとの交配 → 革新的ブレイクスルー（主に撹乱ラウンドで使用）

**交配分析フロー**：
1. 2つのアイデアの共通点を分析
2. 補完的な強みを分析
3. 対立点と境界を分析
4. 1〜3の新しいハイブリッドアイデアを生成
5. 各ハイブリッドのコアメカニズムと価値を評価

**実行要件**：
- 新しいアイデアには自動的にIDが割り当てられる
- 新しいアイデアの `parent_ids` には両方のソースアイデアIDを含む
- 両方のソースアイデアの `child_ids` を更新
- 交配は機械的な結合ではない — 各アイデアから価値ある部分を抽出し、真に新しいコンセプトを形成する

---

## 6. 批評

**目的**：弱点を強制的に発見し、システムがエコーチェンバーになるのを防ぐ。

**チェックリスト**：
- 自己矛盾はないか？
- 前提が強すぎないか？
- 実需が欠如していないか？
- コストが法外に高くないか？
- 既存アイデアの再パッケージではないか？
- 検証パスがないか？
- 最も失敗しやすいポイントはどこか？

**実行要件**：
- 出力：コア欠陥リスト、リスクレベル、継続推奨かどうか、最初に修正すべきこと
- 批評後、カードの「現在のテンション」を更新
- 重大な問題が見つかった場合、対応するスコア次元を下げる

---

## 7. 検証

**目的**：アイデアに引き続きリソースを投資する価値があるかを判断する。

**第1層：致命的欠陥チェック**（4つのはい/いいえの質問）：
1. 論理的欠陥があるか？（核心的前提が自己矛盾しているか、明らかに無効か？）
2. 実需が欠如しているか？（特定可能なターゲットユーザーやユースケースがないか？）
3. 完全に実現不可能か？（技術/リソース/パスに克服不能な障壁があるか？）
4. 既存アイデアとほぼ重複しているか？（単に言い換えたバージョンか？）

いずれかが「はい」→ `validated: false`。

**第2層：価値判断**（第1層がすべて「いいえ」の場合のみ）：
1. 引き続き投資する価値はあるか？
2. 次のアクションは何か？
3. 現在の最大リスクは何か？

**実行要件**：
- 検証失敗 → Priority Score を下げ、ユーザーに報告
- ユーザーが休眠か削除かを決定 — システムは推奨するのみ
- 検証パス → 状態の昇格を推奨する場合がある（例：exploring → refining）

---

## 8. 統合 / 重複排除

**目的**：高度に冗長なコンテンツでアイデアプールが肥大化するのを防ぐ。

**トリガー条件**：
- 2つのアイデアが同じ核心的前提を共有
- 表現の違いだけ
- タグが大幅に重複し、説明が類似

**処理方法**：
- メインアイデア + バリアント記録に統合
- 吸収されたアイデアを `merged_into: IDEA-XXXX` としてマーク
- ブランチを保持するが優先度を下げる

**実行要件**：
- 毎ラウンド終了時にプール全体の類似性チェックが必須
- 類似性判断はタグの重複率 + コアクエスチョンの類似度に基づく
- 統合時は、より豊富な情報を持つバージョンをメインアイデアとして保持
- 統合履歴をカードの「変更ログ」に記録


path: references/prompts.md
content: # プロンプトテンプレート

各アクションのプロンプトテンプレート。アクション実行時に変数を実際の値に置き換え、思考ガイドとして使用してください。

---

## 共通テンプレート構造

すべてのアクションプロンプトは以下の構造に従います：

```
あなたは「アイデア反復インキュベーションシステム」の {action_name} モジュールです。

あなたのタスクは、以下のアイデアに対して {action_name} 操作を実行することです。

【現在のアイデアカード】
{idea_card}

【現在のラウンドコンテキスト】
- ラウンド: {round_id}
- 現在のステージ: {stage}
- 利用可能なバジェット: {budget_level}
- 関連アイデア: {related_ideas_summary}

【操作目標】
{goal_description}

【操作要件】
1. 論理的厳密さを維持する — 曖昧な穴埋めは不可。
2. アイデアの核心的意図を可能な限り保持する。
3. 明らかな欠陥を発見した場合は指摘する。
4. 新しいアイデアを生成する場合、元のアイデアとの明確な関係が必要。
5. 出力は構造化されていなければならない。
```

---

## 深化プロンプト

```
このアイデアに対して「深化」操作を実行してください。これは表面的な書き直しではなく、論理構造を埋めることが目的です。

以下の角度から展開してください：
1. 実際に何の問題を解決するのか？
2. ターゲットユーザーは誰か？
3. なぜこのアプローチが有効なのか？
4. 最小実行可能バージョンは何か？
5. 最大のリスクは何か？
6. まだ検証が必要な主要な前提は何か？

出力：
- 充実したアイデアの説明
- 核心的前提
- ユーザーシナリオ
- MVPバージョン
- リスクと未解決の問い
- 推奨次アクション
```

---

## 派生プロンプト

```
以下のアイデアに基づき、2〜3の高品質なバリアントを派生させてください。

以下の次元に沿って分解してください：
- ユーザーセグメントの違い
- シナリオの違い
- ビジネスモデルの違い
- プロダクト形態の違い
- 技術パスの違い

要件：
1. 各バリアントは元のアイデアのコアDNAを保持すること
2. ただし、明確な差別化要因を持つこと
3. 単に言い換えただけの重複バリアントを生成しないこと

出力フォーマット（各バリアント）：
- バリアントタイトル
- コアの変更点
- 保持する価値がある理由
- 元のアイデアとの関係
```

---

## 交配プロンプト

```
以下の2つのアイデアを交配させ、新しい統合方向を見つけてください。

【アイデア A】
{idea_a_card}

【アイデア B】
{idea_b_card}

まず分析してください：
1. 共通点は何か？
2. 相互補完するところはどこか？
3. 対立点はあるか？

次に出力してください：
1. 1〜3の新しいハイブリッドアイデア
2. 各ハイブリッドのコアメカニズム
3. この交配が意味を持つ理由
4. 最大のリスク
5. 次のラウンドに進める価値があるか
```

---

## 批評プロンプト

```
以下のアイデアに対して批評レビューを実行してください。

焦点：
1. 論理的に一貫しているか？
2. 実体のないコンセプトのパッケージングに過ぎないか？
3. 実需が欠如していないか？
4. コストが法外に高くないか？
5. よりシンプルな代替案はないか？
6. このアイデアが最も失敗しやすいポイントはどこか？

出力：
- コア欠陥
- リスクレベル（高 / 中 / 低）
- 推奨：継続するかしないか
- 継続する場合、最初に修正すべきこと
```

---

## スコアリングプロンプト

```
このアイデアを6つの次元で評価してください（各1〜10）。理由付きで：

- 新規性（重み 0.1）：本当のブレイクスルーがあるか、それとも単なる繰り返しか？
- 実現可能性（重み 0.2）：技術的、リソース的、パス的に達成可能か？
- 価値（重み 0.2）：成功した場合、どれだけのインパクトを生み出せるか？
- 論理性（重み 0.2）：内部的に一貫しており、明らかなギャップがないか？
- 交配ポテンシャル（重み 0.1）：他のアイデアと組み合わせたとき、新しいものを生み出す可能性は？
- 検証可能性（重み 0.2）：実験や最小検証パスを設計できるか？

次に計算：
Survival = 0.10×Novelty + 0.20×Feasibility + 0.20×Value + 0.20×Logic + 0.10×CrossPotential + 0.20×Verifiability

JSON形式で出力：
{
  "novelty": 0,
  "feasibility": 0,
  "value": 0,
  "logic": 0,
  "cross_potential": 0,
  "verifiability": 0,
  "survival_score": 0.0,
  "reasoning": {
    "novelty": "...",
    "feasibility": "...",
    "value": "...",
    "logic": "...",
    "cross_potential": "...",
    "verifiability": "..."
  },
  "suggested_action": "深化 / 派生 / 交配 / 批評 / 休眠"
}
```

---

## 検証プロンプト

```
このアイデアに対して二層検証チェックを実行してください。

【第1層：致命的欠陥チェック】
以下の4つの質問に回答してください（はい/いいえ + 理由）：
1. 論理的欠陥があるか？（核心的前提が自己矛盾しているか、明らかに無効か？）
2. 実需が欠如しているか？（特定可能なターゲットユーザーやユースケースがないか？）
3. 完全に実現不可能か？（技術/リソース/パスに克服不能な障壁があるか？）
4. 既存アイデアとほぼ重複しているか？（単に言い換えたバージョンか？）

いずれかの回答が「はい」の場合、validated: false とし、簡潔な説明を添える。

【第2層：価値判断】（第1層がすべて「いいえ」の場合のみ）
1. 引き続きリソースを投資する価値はあるか？
2. 次のアクションは何か？
3. 現在の最大リスクは何か？

JSON形式で出力：
{
  "hard_check": {
    "logic_flaw": {"result": "はい/いいえ", "reason": "..."},
    "no_real_demand": {"result": "はい/いいえ", "reason": "..."},
    "not_feasible": {"result": "はい/いいえ", "reason": "..."},
    "duplicate": {"result": "はい/いいえ", "reason": "..."}
  },
  "validated": true/false,
  "value_judgment": {
    "worth_continuing": "はい/いいえ",
    "next_action": "...",
    "biggest_risk": "..."
  }
}
```

---

## ラウンドレポートテンプレート

```markdown
# ラウンド {round_id} レポート

## サマリー
- タイムスタンプ: {timestamp}
- プール内の総アイデア数: {total}（アクティブ {active} / 休眠 {dormant}）
- 今ラウンドの処理数: {processed}
- 新規生成アイデア数: {new_count}

## 実行されたアクション

| アイデアID | タイトル | アクション | 結果サマリー |
|---|---|---|---|
| IDEA-XXXX | ... | 深化 | ... |

## 新規生成アイデア

| アイデアID | タイトル | ソース | 初期 Priority |
|---|---|---|---|
| IDEA-XXXX | ... | IDEA-XXXX から派生 | 6.5 |

## スコア変動トップ5

| アイデアID | タイトル | Priority 変動 | 理由 |
|---|---|---|---|
| IDEA-XXXX | ... | +1.2 | 深化によりロジックが充実 |

## 検証失敗（ユーザーの判断が必要）

| アイデアID | タイトル | 失敗理由 | 推奨アクション |
|---|---|---|---|
| IDEA-XXXX | ... | IDEA-XXXX とほぼ重複 | 統合または休眠 |

## 次ラウンドへの推奨事項
- 優先処理: IDEA-XXXX, IDEA-XXXX
- 交配推奨: IDEA-XXXX × IDEA-XXXX
- 要注意: IDEA-XXXX が3ラウンド連続で変化なし
```


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)