business-brainstorm

/business-brainstorm — ビジネスアイデアを厳しく検証する

漠然としたアイデアを受け取り、ユーザー独自の基準で検証して、構造化された実現可能性の概要を出力します。deep-research（市場調査用）や/domain（ネーミング用）と組み合わせて使えます。

ステップ 1 — アイデアを把握する

ユーザーから次の情報を得ます。

• アイデアを1～2文で（何をするか）
• それが今気になっている理由（なぜ今か）
• 出発点となる背景（このアイデアが出たチャット、きっかけになったツイート、直面した問題など）

最初に再開します。 アーカイブディレクトリ（ステップ 7）を調べ、1行目が`

Leave the later brief sections out until Step 7, so an unfinished file never looks finished. As each dimension settles, fill its row and update the marker. If the session dies, the next one resumes from the file. Don't touch `INDEX.md` until Step 7.

Where a dimension depends on something only the user knows (their audience access, energy, what this displaces), ask — one dimension at a time — rather than guessing. Then **hold the bar** on what they say:

- **Hopes don't score.** "People want it," "we'll figure out distribution," "should be easy to build" — stay on it, offer 1–2 sharper candidate answers or ask for one piece of evidence (a waitlist, a request, a competitor's revenue). Still mush after two pushes → ❓, or ❌ where `framework.md` names that exact cop-out as weak ("we'll do SEO," "we'll figure out monetization later"). Never 🟡. Quote the mush in the Take. A half-sharp answer (real price, hoped-for retention) scores on its weaker half.
- **Opposite Test for differentiation claims** — wherever they show up (usually the Wedge offer or Moat). Flip the claim. If the opposite is nonsense ("worse UX," "not AI-powered," "bad support"), the claim is fluff — demand the real choice underneath (e.g., "opinionated single workflow vs. flexible everything") before it can score ✅.
- **Threats are present tense.** "A big player *could* enter" is filler. "X launched this feature in March" is a threat. Only present-tense or clearly-likely threats count against Moat.

Warm framing, unmoved bar — attack the claim, never the person.

## Step 4 — Trigger research where needed (optional)

If 2+ dimensions are ❓ unknown, offer the user: *"Want me to run `/deep-research` on [topic] before scoring?"* At 3+ ❓ the framework says research first; if the user declines, write the brief with the ❓s visible — the verdict can't be Build.

Useful research targets:
- Market size / who pays signal → `last30days` skill (if installed) + web search
- Competitive landscape → search for "alternatives to X", "X vs Y" pages
- ICP signal → forums / Reddit / X where the audience hangs out
- Pricing benchmarks → look at competitor pricing pages

If the user says yes, run the `deep-research` skill on the topic and incorporate the brief.

## Step 5 — Check the .com

Always run `/domain` on the working name(s). A perfect idea with a $50k domain is a worse idea than a B+ idea with a free .com.

If naming is wide open, brainstorm 5–10 candidate names through `/domain` and report which are available.

## Step 6 — Output the brief

Use this template:

```markdown
# Business brainstorm: <name or idea slug>

**Date:** <YYYY-MM-DD>
**Idea:** <1–2 sentences>
**Why now:** <1 sentence>

## Verdict
**Build** / **Sleep on it** / **Pass** / **Steal an angle for [existing property]**

<2–3 sentence rationale>

## Score

| Dimension | Take | Verdict |
|---|---|---|
| 1. Problem | … | ✅ |
| 2. Audience | … | 🟡 |
| 3. Wedge | … | ❓ |
| 4. Monetization | … | ✅ |
| 5. Moat | … | ❌ |
| 6. Portfolio fit | … | ✅ |
| 7. Distribution | … | ✅ |
| 8. Energy fit | … | 🟡 |
| 9. Opportunity cost | … | ❌ |

## Domain
- <name>.com — available / taken / aftermarket $<price>
- (other candidates if relevant)

## Research applied
- <link to deep-research brief in ~/.config/makerskills/deep-research/archive/, if run>

## Open questions
- <what would change the verdict>

## If you build it (sketch)
- **First 100 customers:** <how>
- **Wedge offer:** <what>
- **Price:** <range>
- **MVP scope:** <1–3 features>

## If you don't build it
- **Angle to steal for existing properties:**
  - Property A: …
  - Property B: …
  - Property C: …
  - (etc., only where relevant)

ステップ 7 — アーカイブ

アーカイブは ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/business-brainstorm/archive/ に保存します（存在しない場合はディレクトリを作成します）。スキル自体のフォルダー内には絶対にアーカイブを保存しないでください。スキルのインストールやアップグレードでソースから再同期され、保存した内容がすべて消去されます。移行： このスキルのフォルダーに、ユーザーのエントリーを含む古い references/ideas-archive/ がある場合は、まずそのファイルをアーカイブディレクトリに移動します。

作業ファイルを <archive dir>/<YYYY-MM-DD>-<slug>.md（ステップ 3 で作成）として仕上げます。残りのセクションをすべて埋め、`` の行を削除します。続いて <archive dir>/INDEX.md に追記します（存在しない場合は作成します）。

- 2026-06-16 — [<idea>](./<filename>.md) — **<verdict>** — <one-line rationale>

ステップ 8 — 提示する

チャットで概要を提示します。アーカイブのパスをユーザーに伝え、次の選択肢を提案します。

• 「ポジショニングキャンバスとしてNotionに登録しますか？」
• 「プロジェクトリポジトリやランディングページのひな形を作成しますか？」（判定がBuildの場合）
• 「30日後に見直しますか？」（判定がSleep on itの場合）

組み合わせて使うもの

• deep-research — 評価項目に❓がある場合の市場検証用
• /domain — .comの利用可能性確認とネーミングのブレインストーミング用
• /last30days — オーディエンスや市場の直近の動向を確認するシグナル用（deep-research経由）
• Memory（project_*.md）— ポートフォリオの状況確認用（すでにあるアイデアを提案しない）

品質に関する注意事項

• 主役となる指標は1つではなく、9つの評価項目を使います。 ほかの評価が高くても、1つの評価項目が気づかないうちに劣化してアイデアが失敗することがあります。各評価項目を必ず採点してください。「そこは後で考えます」という逃げは認めません。ユーザーが詰めようとしない逃げの回答は、引用符で囲んで🟡ではなく❓と評価します。
• いつもBuildと結論づけるブレインストーミングは、嘘をついているのと同じです。 このスキルはPassという結論を出すことをためらってはいけません。🟡や❓だらけの表を前にBuildと書こうとしているなら、ステップ 3に戻ってください。
• 判定の一貫性：Build / Sleep on it / Pass。 「たぶん」は使いません。判定が曖昧だと、コミットも曖昧になります。この概要はそれを防ぐためにあります。
• ポートフォリオの状況確認は必須です。 作成前に、Memoryとwikiをgrepして、既存のプロパティと重複していないか確認します。新しいアイデアが既存のプロパティの80%を占める場合は、新しいものを作るのではなく、既存のプロパティを拡張する案を提案します。複利効果を高めるには、こちらのほうが4倍低コストです。
• Passの場合も含め、すべての概要をアーカイブします。 見送ったアイデアが再浮上することがあります。理由を記した概要があれば、同じ議論を繰り返さずに済みます。アーカイブディレクトリとINDEX.mdがあれば、簡単に見直せます。
• 「取り入れたい切り口」のセクションで、Passからも価値を引き出します。 作らないアイデアでも、既存のプロパティを改善する切り口が見つかることはよくあります。このセクションを省略しないでください。Pass判定で最も大きな効果をもたらす成果です。
• 「Sleep on it」の場合は30日後に見直します。 カレンダーにリマインダーを設定してください。見直されない「Sleep on it」のアイデアはアーカイブの負担になります。見直せば、より良い背景情報とともに再浮上します。