brainstorm-experiments-existing

brainstorm-experiments-existing の概要

brainstorm-experiments-existing は、既存プロダクトに対して、エンジニアリング工数を大きく投じる前に、低コストで実験を設計するためのワークフロー重視の skill です。機能アイデアと仮説のセットを、プロトタイプ、fake-door テスト、A/B テスト、technical spike、Wizard of Oz フロー、行動調査などの検証可能な विकल्पに落とし込むのを助けます。主な役割はシンプルで、危険な作り込みを避けながら、不確実性をすばやく減らすことです。

この skill が最適な人

すでにプロダクトがあり、変更案があり、少なくとも1つ答えを出したい問いがあるなら、brainstorm-experiments-existing skill を使うべきです。スコープ、需要、使いやすさ、技術的実現性を検証するための、実践的な brainstorm-experiments-existing ガイドを必要とする PM、デザイナー、創業者、エンジニアに向いています。

何が違うのか

この skill は、ありがちなアイデア出し用プロンプトではありません。単なる意見ではなく行動を測る実験を重視し、テストが本番環境に触れる場合はリスク軽減まで考えるよう促します。そのため、brainstorm-experiments-existing for Workflow Automation は、幅広い機能案の羅列ではなく、意思決定の支援が必要なワークフローに特に役立ちます。

どんなときに向いているか

「これを作るべきか、最初にどう安く検証するべきか」を判断したいなら、この skill を選んでください。検証したい仮説を言語化でき、学習速度、コスト、ユーザー安全性を重視する場合に、最も力を発揮します。

brainstorm-experiments-existing skill の使い方

インストールして、実際の文脈を渡す

skills manager で brainstorm-experiments-existing のインストールパスを使い、すでに手元にある最も関連性の高い資料を skill に渡します。たとえば、PRD メモ、仮説一覧、デザインモック、サポートチケット、大まかな機能ブリーフなどです。この skill は $ARGUMENTS を前提に動くので、入力が明確であるほど、実験計画の質も上がります。

曖昧なアイデアを使えるプロンプトに変える

弱いプロンプトは「新しい onboarding 機能をテストするのを手伝って」といったものです。より良いプロンプトは、「SMB 管理者の activation を改善するために team-based onboarding を追加したい。主要リスクは discoverability と完了時間だと想定している。最小工数で検証できる実験を3つ提案し、それぞれの成功条件も書いてほしい」といった形です。

こうした書き方が有効なのは、brainstorm-experiments-existing の利用フローに、具体的なプロダクト領域、対象ユーザー、測定可能な仮説が入るからです。

リポジトリは正しい順番で読む

まずは SKILL.md を読みます。コアとなるワークフローと出力要件がまとまっているからです。ローカルコピーに補助ドキュメントが含まれている場合は、次に README.md、AGENTS.md、metadata.json、それに rules/、resources/、references/、scripts/ 配下を確認してください。このリポジトリでは skill がコンパクトで補助ファイルも最小限なので、主な価値はメインの指示ファイルをしっかり理解することにあります。

より良い判断につながる形に出力を整える

結果は、仮説、実験タイプ、コスト、リスク、想定シグナルで整理するよう skill に依頼してください。可能なら、「本番リスクなし」「1週間以内」「デザインリソースなし」といった制約も含めます。そうした条件があると、brainstorm-experiments-existing ガイドは、面白いだけの理論ではなく、実際に出せる実験案を返しやすくなります。

brainstorm-experiments-existing skill の FAQ

これは単なるブレスト用プロンプトですか？

いいえ。brainstorm-experiments-existing skill は、既存プロダクトに対する構造化された検証のためのもので、自由発想のアイデア出しではありません。仮説を否定できる実験が必要なときに最も役立ちます。創造的な可能性を長々と並べる用途ではありません。

どんなときは使わないほうがいいですか？

まだプロダクトの課題、対象ユーザー、検証したい仮説がはっきりしていないなら、この skill は使わないほうがよいです。また、必要なのが検証ではなく実装計画の場合や、アイデアがまだ初期段階すぎて、実験の前に発見インタビューが必要な場合にも向きません。

初心者でも使えますか？

はい。プロダクト案を平易な言葉で説明できるなら問題ありません。初心者ほど、ざっくりした目的、ユーザーセグメント、想定リスクを入力すると価値が出ます。そうすると brainstorm-experiments-existing skill が、不確実性を具体的なテスト案に変えてくれます。

Workflow Automation とはどう関係しますか？

Workflow Automation で brainstorm-experiments-existing を使うのは、検証ステップの提案、実験タイプの比較、証拠収集についてチームの足並みをそろえたいときです。実験そのものの実行を自動化する用途よりも、テスト計画を設計する用途のほうが適しています。

brainstorm-experiments-existing skill の改善方法

仮説をもっと具体的にする

品質を最も大きく引き上げるのは、仮説を正確に言うことです。「ユーザーは気に入るか？」ではなく、「初回利用の管理者は、ヘルプなしで新しい一括招待フローを見つけられるか？」のように書いてください。そうすれば brainstorm-experiments-existing skill は、各仮説を、より低コストで明確なシグナルが取れる実験に対応づけやすくなります。

実験を変える制約を足す

期限、リスク許容度、使えるトラフィック、ツールの制限を含めてください。たとえば、「テストできるのは staging のみ」「使えるのは1スプリント」「既存の analytics は使えるが新規トラッキングは不可」といった条件です。こうした制約があると、brainstorm-experiments-existing ガイドは理想論ではなく、現実的な実験を提案せざるを得なくなります。

意思決定にそのまま使える出力を求める

仮説、実験、シグナル、リスク、次の一手を含む形式で出力するよう依頼してください。そうすると案の比較がしやすくなり、曖昧な提案を避けられます。最初の提案が広すぎるなら、実験数を減らす、反証条件を厳しくする、工数対効果で並べた短い候補リストにする、といった形で再依頼してください。

最初の結果を受けてプロンプトを磨く

結果が一般論に寄っているなら、現在のプロダクト挙動、ユーザージャーニー、成功・失敗の判断基準について、もっと文脈を足してください。brainstorm-experiments-existing のインストールは、検証用の copilot として扱うと最も価値が出ます。実際の制約を渡し、各実験が build / no-build の判断に値するところまで、計画を詰めていってください。