idea-validator

アイデア検証

市場での実現可能性、技術的な実現可能性、実行可能な改善案について、率直なフィードバックでアイデアを批判的に評価します。

使用するタイミング

ユーザーが次のことを求めた場合に、このスキルを実行します。

• アプリのアイデアやスタートアップの構想を評価、検証、採点する
• アイデアを開発する価値があるか、率直なフィードバックを得る
• 商用ツール／サービスやオープンソースの代替手段など、その分野に既存の競合があるか調査する
• 漠然とした構想を、体系立てた検証レポートにまとめる

手順

次の順番で手順を実行します：Setup → Phase 1 Clarify → Phase 2 Technical Context → Phase 3 Competitive Landscape → Phase 4 Evaluate → Phase 5 Improve → Commit and Push → Final Report。Edge Cases の項目に中止の指示がある場合を除き、手順を飛ばしたり順序を変更したりしないでください。Setup のステップ 4 の後に中止する場合も、そこまでに書き込まれたファイルを対象に Commit and Push を実行してから、Final Report を作成します。アイデアのルートが ideas リポジトリのルートである場合は、ファイルを更新するたびに README Maintenance も実行してください（判定ルールはそのセクションを参照）。

用語：

• Ideas root — すべてのアイデアフォルダーを格納するディレクトリ（Setup のステップ 2 で解決します）。
• Project folder — <ideas root>/YYYY_MM_DD_<short_snake_case_name>/。このアイデアの idea.md と validate.md を格納します。
• Status — 実行結果。Final Report のルールに従って COMPLETE、PARTIAL、BLOCKED のいずれかを選びます。

編集前のリポジトリ同期（必須）

Setup のステップ 3 でファイルを作成または変更する前に、ideas root でこれを実行します。ideas root が git リポジトリ内にない場合（git -C <ideas root> rev-parse --git-dir が失敗する場合）はスキップし、そのスキップを Final Report に記録します。

git status --porcelain の出力が何もない場合は、そのまま同期します。

cd "<ideas root>"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

出力がある場合は、先にスタッシュしてから同期し、その後に復元します。

git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

origin がない場合、pull が失敗した場合、または rebase や stash pop で競合が発生した場合は、作業を中止して続行する前にユーザーに確認します。

Setup

1. アイデアを確認します。 $ARGUMENTS にあるアイデアを使います。$ARGUMENTS が空の場合は、構想を説明するようユーザーに尋ねます。説明が得られない場合は、ステータス BLOCKED で中止します。

2. ideas root を解決します（ツールに依存しません。環境ごとに一度だけ尋ねます）。該当するものを上から順に使用します。

   1. 設定されている場合は、環境変数 IDEAS_ROOT。
   2. ファイルが存在する場合は、~/.config/ideas-root.txt に記載されたパス。
   3. ファイルが存在する場合は、旧形式の ~/.openclaw/ideas-root.txt に記載されたパス。その値を ~/.config/ideas-root.txt にコピーします。
   4. それ以外の場合は、生成したドキュメントの保存先をユーザーに尋ねます。~/workspace/ideas を提案し、回答を ~/.config/ideas-root.txt に保存します。

   ユーザーが保存先の変更を求めた場合に限り、再度尋ねます。

3. ideas root の下にプロジェクトフォルダーを作成します。同じ日付と名前のフォルダーがすでに存在する場合は、新たに作成せず、そのフォルダーを再利用してファイルを更新します。

4. アイデアと確認内容を記載した idea.md を作成します。

5. 評価と提案を記載した validate.md を作成します。

6. 後続のスキルが参照できるよう、応答にプロジェクトフォルダーの絶対パスを記載します。

ideas root を作成または書き込みできない場合は、ステータス BLOCKED で中止し、そのパスを示します。

いずれかのファイルを作成する場合、または Phases 1-5 で指定されたセクションを更新する場合は、references/file-templates.md を読みます。ヘッダー名と順序はそのファイルの定義に従い、内容は各フェーズの指示に従います。

Phase 1: アイデアを明確にする

質問ツール（AskUserQuestion または同等のもの）を使って、ユーザーに次の質問をします。質問ツールがない場合は、通常のチャットで尋ねます。Setup のステップ 1 にあるアイデアの説明ですでに回答されている質問は省略します。

• どのような問題を解決しますか？ その問題に困っているのは誰ですか？
• 想定するユーザーは誰ですか？ 具体的に教えてください。
• 既存のソリューションと何が違いますか？
• 6～12 か月後に、どのような状態になっていれば成功ですか？

回答を idea.md に反映します。ユーザーが回答を断った場合、または回答できない場合は、それぞれ unknown と記載し、Final Report の Uncertainty に列挙します。想定ユーザーに関する質問は例外です。Edge Cases を参照してください。

フェーズ 2：技術的な背景情報を収集する

フェーズ 1 と同じツールとスキップルールを使って、ユーザーに次の項目を尋ねます。

• 希望する技術スタックは何ですか？
• スケジュールとチームの規模はどのくらいですか？
• 予算の状況はどうですか（自己資金／資金調達済み／サイドプロジェクト）？
• 既存の資産（コード、デザイン、調査資料）はありますか？

idea.md の「技術的な背景情報」セクションを更新します。回答のない項目には、それぞれ unknown と記入します。

フェーズ 3：競合環境を調査する

アイデアを評価する前に、ウェブで最新情報を調査し、その分野にすでに存在するものを確認します。市場、価格、実績、競合、オープンソースに関する主張を、記憶や学習データに頼ってはいけません。レポートに最新情報を反映するため、ウェブ検索は必須です。

利用可能なウェブ検索ツール（WebSearch、web_search など）を使い、次の項目を網羅する、少なくとも 4 件の異なるクエリを実行します。

商用ツール／サービス — 同じ問題または関連する問題を解決する SaaS 製品、モバイルアプリ、エンタープライズプラットフォーム、有料 API、代理店、マーケットプレイス、その他の商用サービスを検索します。中心となる問題の説明に、「app」「tool」「platform」「SaaS」「startup」「pricing」「alternative」などのキーワードや、対象ユーザーに応じた語句を組み合わせて検索します。

オープンソースのソリューション — 同じ問題を解決するか、強固な基盤となる GitHub／GitLab リポジトリ、セルフホスト可能なツール、パッケージ、フレームワーク、テンプレート、オープンソースの代替手段を検索します。「open source」「GitHub」「self-hosted」「OSS」「alternative」「library」などの語句や、関連するパッケージレジストリ名を使って検索します。信頼できるオープンソースの選択肢が見つからない場合は、試したクエリを記録し、保守が継続されているオープンソースの基準となる実装は見つからなかったと記載します。

隣接するソリューション — 関連する問題を解決する製品や、異なる方法で同じ対象ユーザーにサービスを提供するプロジェクトを探します。これらから、提案されているソリューションがない場合にユーザーが現在どのように対処しているかが分かります。

失敗した試み — 類似の試みに挑戦したものの、停滞、終了、または放棄されたスタートアップ、製品、オープンソースプロジェクトを検索します。「[concept] startup failed」「[concept] post-mortem」「[concept] abandoned GitHub」などで検索するか、製品ディレクトリを確認します。

見つかった競合製品またはオープンソースプロジェクトごとに、次の情報を記録します。

• 名称と URL
• 種類（商用、オープンソース、ハイブリッド、隣接、失敗／放棄）
• 提供内容（何をするものかを 1 文で説明）
• 価格またはライセンス（無料、フリーミアム、有料、エンタープライズ、判明していればオープンソースライセンス）
• 実績または健全性（レビュー、評価、ユーザー数、資金調達、GitHub のスター数／フォーク数、最近のコミット、未解決の課題、コミュニティの活動状況）
• ユーザーのアイデアが活用できる主な弱点または不足点
• オープンソースの選択肢については、再利用／基盤として活用できる可能性（フォーク、プラグイン、ライブラリ依存、貢献経路、または適さない理由）

競合は合計 3～8 件を目安とし、商用とオープンソースの検索をそれぞれ少なくとも 1 つ含めます。信頼できる結果が 3 件未満の場合は、その事実を validate.md にシグナルとして記録します。市場がニッチである、検索語を見直す必要がある、またはアイデアが一般的でない言葉で表現されている可能性があります。

オープンソースのソリューションがすでにアイデアの重要な部分を解決している場合は、新規開発を勧める前に、ライセンスの適合性、メンテナンス状況、アーキテクチャ、拡張性、デプロイの負担、コミュニティを比較します。ユーザーがそれを基盤として活用するか、フォークするか、貢献するか、明確に差別化するかを判断します。

validate.md に ## 競合環境 セクションを追加し、次の項目を含めます。

1. 見つかった商用およびオープンソースの競合製品をまとめた表
2. オープンソースの代替手段と再利用の可能性の分析
3. 現在の市場に何が欠けているかを示す「ホワイトスペース」分析
4. 既存の状況を踏まえた、ユーザーの差別化が実際に存在するのか、あるように見えるだけなのかについての率直な評価
5. オープンソースの基盤が存在する場合の、新規開発か既存基盤の活用かに関する推奨

ウェブ検索が利用できない、またはブロックされている場合は、検索なしで続行するかどうかをユーザーに尋ね、そこで停止します。ユーザーが続行に同意した場合は、競合環境セクションに ライブ検索で未検証 と明記し、ステータスを PARTIAL に設定します。ユーザーが同意しない場合は、ステータスを BLOCKED として停止します。ライブ調査を、一般知識で黙って置き換えてはいけません。

フェーズ 4：批判的評価

率直に評価し、validate.md を更新します。

市場分析：

• 類似する商用製品とオープンソースのソリューション
• 市場規模と競争状況
• 独自の差別化要因

需要評価：

• ユーザーが料金を支払うという根拠
• 課題の緊急度

実現可能性：

• 2～4 週間で MVP をリリースできますか？
• 実用最小限の機能
• 複雑な依存関係はありますか？
• ゼロから始めるのではなく、既存の OSS プロジェクトを再利用、フォーク、拡張、または参考にできますか？

収益化：

• 明確な収益化の道筋はありますか？
• 支払い意思はありますか？

技術的リスク：

• 明示された制約の範囲内で構築できますか？
• 主な技術的リスクは何ですか？
• オープンソースを基盤に構築する場合のライセンス、メンテナンス、依存関係のリスクは何ですか？

重複／再利用のリスク：

• このアイデアは、既存の商用または OSS ソリューションをほぼ再実装するものですか？
• リスクを軽減する、信頼できる拡張、プラグイン、フォーク、またはコントリビューションの道筋はありますか？

評価（1～10）： 創造性、実現可能性、市場への影響、技術的な実行力を評価します。それぞれのスコアに、1 行の理由を添えます。

判定。 最初に当てはまるルールを適用します。

1. Skip it — フェーズ 3 でほぼ同一の製品が見つかり、ユーザーが実質的な差別化要因を挙げていない場合、または明示されたチームと予算では解消できない重大な障害がある場合。
2. Maybe — 次のいずれかに該当する場合：未解決の重大な技術的リスクがある、アイデアの大部分をカバーするメンテナンス中の OSS プロジェクトがあるものの、それを基盤に構築する道筋が決まっていない、需要または支払い意思の根拠がない、または実現可能性のスコアが 6 未満。
3. Build it — 上記のいずれにも該当しない場合。

判定を導いたルールと、2～3 文の根拠を添えて判定を記載します。

フェーズ 5：改善

次の内容で validate.md を更新します。

• 強化方法：フェーズ 4 の懸念事項にそれぞれ対応した、具体的で実行可能な改善策
• 強化版：再構成し、最適化したコンセプト
• 実装ロードマップ：段階的なアプローチ（該当する場合）

エッジケース

• 対象ユーザーが明確でない：アイデアの対象が広すぎる場合（例：「誰もが使えるアプリ」）、フェーズ 1 で立ち止まり、今まさにこの課題を抱えている具体的な人物を 1 人挙げるようユーザーに求めます。ユーザー層が定まるまでフェーズ 3 を開始しません。ユーザーが最後まで誰も挙げない場合は、ステータスを PARTIAL として終了し、idea.md を保存します。
• 既存の重複アイデアがある：フェーズ 3 でほぼ同一の製品が見つかった場合は、根拠（URL、機能比較）とともに直ちに提示し、続行するかどうかをユーザーに尋ねます。ユーザーが実質的な差別化要因を示した場合にのみ続行します。ユーザーが中止する場合は、判定をルール 1 に基づく Skip it としてフェーズ 4 を実行し、フェーズ 5 は省略して、ステータスを PARTIAL に設定します。
• オープンソースのソリューションがすでに存在する：フェーズ 3 でアイデアの多くをカバーするメンテナンス中の OSS プロジェクトが見つかった場合、「ゼロから構築する」という推奨のリスクを高く評価します。Build it と判定する前に、そのプロジェクトを基盤に構築する、フォークする、コントリビュートする、または差別化するかを決定します。
• 技術的な実現可能性が不明確：アイデアに未実証の技術、公開されていない API、または明示されたチームでは構築できない機能が必要な場合、フェーズ 4 で重大な障害として明示し、実現可能性のスコアを下げます。この判定ルールにより、Build it は選択できません。
• ウェブ検索を利用できない：フェーズ 3 の最後の段落に従います。
• Ideas のルートが git リポジトリではない：ファイルを書き込み、Repo Sync と Commit and Push を省略し、ステータスを PARTIAL に設定します。ユーザーから依頼がない限り、git init を実行しません。
• 再試行後も Push に失敗する：処理を停止し、ユーザーに尋ねます（Commit and Push）。コミットハッシュを報告し、ステータスを PARTIAL に設定します。

ステップ完了レポート

Setup からフェーズ 5 までの各ステップを完了した後、次の形式でステータスレポートを出力します。

◆ [Step Name] ([step N of 6] — [idea name])
··································································
  [Check 1]:          √ pass
  [Check 2]:          × fail — [reason]
  ____________________________
  Result:             PASS | FAIL | PARTIAL

成功には √、失敗には ×、簡単な補足には — を使用します。各フェーズのチェックブロックは references/step-completion-reports.md にあります。完了したステップに対応するブロックを読み込んでください。

トーン

• 率直：致命的な欠点はそれぞれ「懸念事項」で明確に述べます
• 建設的：批判にはすべて改善案を添えます
• 具体的：主張には競合製品、数値、またはユーザーの回答の引用を根拠として示します
• バランス重視：弱点とあわせて強みも挙げます

README のメンテナンス（ideas リポジトリ内で実行する場合）

ideas のルートに README.md と、YYYY_MM_DD_* 形式のアイデアフォルダーが2つ以上ある場合に実行します。idea.md または validate.md を更新するたびに、その README.md に ## Ideas index テーブルを挿入または更新し、各アイデアにつき1行を追加します。

• アイデアの idea.md へのリンク
• PRD／タスクのステータス：フォルダー内に prd.md があれば PRD、tasks.md があれば tasks、どちらもなければ none
• アイデアの validate.md にリンクした判定結果

コミットとプッシュ（必須）

ideas のルートが Git リポジトリではない場合は、この手順をスキップします（「エッジケース」を参照）。それ以外の場合は、フェーズ5の後、または途中で停止する場合（「手順」を参照）に実行します。

1. 今回の実行で書き込んだファイルのみをステージングします：git add <project folder>/idea.md <project folder>/validate.md。README のメンテナンスで README.md を変更した場合は、それも追加します。git add -A は絶対に実行しないでください。
2. git diff --cached --name-only を実行し、該当するファイルのみがステージングされていることを確認します。別のファイルがステージングされている場合は、git restore --staged <file> でステージングを解除します。
3. docs(ideas): validate <short_snake_case_name> というメッセージでコミットします。
4. 現在のブランチにプッシュします。
5. プッシュが拒否された場合は、リベースして1回だけ再試行します：branch="$(git rev-parse --abbrev-ref HEAD)" && git fetch origin && git rebase "origin/$branch" && git push。
6. プッシュが再度失敗した場合（origin がない、リベースの競合、再度拒否された場合）は、停止してユーザーに確認します。

このスキルの実行指示により、コミットとプッシュが許可されています。プッシュの許可を再度求めてはいけません。ideas リポジトリでは、強制プッシュや git reset を絶対に実行しないでください。リベースの競合は、ユーザーの確認を得た後にのみ解決してください。

最終レポート

実行のたびに、停止した場合も含め、簡潔なチャット文で要約を1つ出力します。主要な結果はファイルを開かなくてもわかるようにし、詳細は validate.md に記載します。ユーザーが別の形式を求めた場合に限り、その形式に従います。ステータスは、次のうち最初に該当するルールに従います。

1. BLOCKED — アイデアの説明がない、ideas のルートに書き込めない、またはユーザーがウェブ検索なしで続行することを拒否した場合。
2. PARTIAL — 手順をスキップした、早期に停止した、ライブ検索なしでフェーズ3を実行した、またはファイルをコミットしてプッシュできなかった場合。
3. COMPLETE — セットアップからコミットとプッシュまで、すべて完了した場合。

要約には、次の行をこの順序で含めます。

• Result: ステータス。続けて、フェーズ4を実行した場合は判定結果と4つの評価を記載します。PARTIAL または BLOCKED の場合は、停止した手順と理由を記載します。
• Evidence: プロジェクトフォルダーのパス、idea.md と validate.md、変更した場合は README.md への GitHub リンク、コミットハッシュ、実行したライブクエリ数と見つかった競合製品の数を記載します。実行した確認項目のみを挙げてください。
• Strengths: と Concerns: それぞれ上位3項目を記載します。
• Uncertainty: unknown の回答、情報源ではなく仮定に基づく主張、省略した確認項目をそれぞれ記載します。該当するものがなければ 実施した確認の範囲ではありません と記載します。
• Decision: No approval needed.（実行の指示によりコミットとプッシュが許可されています）、または実行を停止した際の質問を記載します。
• Next step: ユーザーにとって最も重要な次のアクションを1つ記載します。

GitHub リンクは、git remote get-url origin と現在のブランチから組み立てます：https://github.com/<owner>/<repo>/blob/<branch>/<relative-path>。要約例と記入ルールは references/final-report.md に記載されています。

受け入れ基準

• Setup、Phases 1-5、Commit and Push が順番に実行されるか、一致するステータスの Edge Cases の行で実行が停止する
• 4種類以上の異なるクエリを使い、ライブウェブ検索で競合状況の調査が行われる
• 商用ツール／サービスとオープンソースのソリューションの両方が確認される。信頼できる OSS の選択肢が見つからない場合は、試行した OSS クエリが記録される
• 競合他社の表と「オープンソースの代替案と再利用の可能性」の分析が validate.md に記入される
• 判定（Build it / Maybe / Skip it）には、その判定を導いた判定ルール名と根拠が記載される
• 4項目すべての評価（Creativity、Feasibility、Market Impact、Technical Execution）が10点満点で提示される
• この実行で書き込まれたファイルのみがコミットされ、コミットがプッシュされる（またはステータスが PARTIAL となる）
• 最終レポートは Result: とステータスで始まり、Evidence:、Uncertainty:、Decision: の各行が含まれる
• 読者向けチェックに合格する。結果を見つけられること、事実と仮定が区別されていること、主張の出典をたどれること、次の判断が明確であること（references/final-report.md → Reader checks、シナリオケースは evals/evals.json を参照）