business-brainstorm

/business-brainstorm — 对商业创意进行压力测试

获取一个模糊的创意，用用户的筛选标准进行评估，并输出一份结构化的可行性简报。可与 deep-research（用于市场研究）和 /domain（用于命名）组合使用。

Step 1 — 收集创意

向用户了解：

• 用 1–2 句话描述创意（是什么）
• 这个创意为何此时浮现（为什么是现在）
• 任何初始背景（比如提到这个创意的聊天、启发它的推文，或他们遇到的问题）

先恢复进度。 在归档目录（Step 7）中查找首行以 `

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)

Step 7 — 归档

归档文件存放在 ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/business-brainstorm/archive/（如果目录不存在则创建）。切勿将归档文件写入技能自身的文件夹——技能安装和升级时会从源重新同步，并清除其中保存的内容。迁移： 如果此技能的文件夹中有包含用户条目的旧 references/ideas-archive/，请先将这些文件移至归档目录。

将工作文件整理完成，保存为 <archive dir>/<YYYY-MM-DD>-<slug>.md（在 Step 3 创建）：填完所有剩余部分，并删除 `` 行。然后追加到 <archive dir>/INDEX.md（如果不存在则创建）：

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

Step 8 — 展示结果

在聊天中展示简报，并告知用户归档路径。提供以下选项：

• “想推送到 Notion，作为定位画布吗？”
• “想让我搭建项目代码仓库 / 落地页吗？”（如果结论 = Build）
• “想让我 30 天后再回顾吗？”（如果结论 = Sleep on it）

组合使用

• deep-research — 当各维度为 ❓ 时，用于验证市场
• /domain — 用于检查 .com 可用性和进行命名构思
• /last30days — 通过 deep-research 获取受众 / 市场的新近信号
• Memory (project_*.md) — 用于了解项目组合背景（不要推介已经存在的创意）

质量说明

• 九个维度，而不是一个核心指标。 即使其他维度得分很高，某个维度也可能悄然恶化，导致创意失败。务必逐一为各维度打分——不接受“以后再说”这种敷衍。如果用户不愿进一步明确，敷衍项应记为 ❓，并附上引述，而不是 🟡。
• 总是给出 Build 结论的头脑风暴是在说谎。 技能必须敢于得出 Pass。如果你正准备在满是 🟡 和 ❓ 的表格上写下 Build，请返回 Step 3。
• 严格遵守结论选项：Build / Sleep on it / Pass。 不要写“也许”。结论模糊会让投入决策也变得模糊；这份简报的存在就是为了避免这种情况。
• 不可跳过项目组合背景检查。 写作前，使用 grep 检查 memory + wiki 中是否已有重叠的项目。如果新创意有 80% 与现有项目重合，应建议扩展现有项目，而不是另起炉灶——累积效应的成本能降低 4 倍。
• 每份简报都要归档，包括 Pass。 被放弃的创意可能会重新浮现——附有理由的简报可以避免重新争论。归档目录 + INDEX.md 让回顾变得轻而易举。
• “可借鉴的切入点”部分能让 Pass 也有价值。 即使不打算实施某个创意，它也常常有能改进现有项目的切入点。不要跳过此部分——这是 Pass 结论中最具杠杆价值的产出。
• 对 “Sleep on it” 的创意，30 天后回顾。 设置日历提醒。一直不回顾的待定创意会成为归档中的累赘；回顾后则可能在更充分的背景下重新浮现。