菜单
Stress-test an idea or hypothesis. Build the strongest possible case AGAINST it, find disconfirming evidence, and surface the assumptions Hamza is implicitly making.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Slice a goal into the smallest feature slices that can each be PROVEN — every slice ships with a named eval and an end-to-end test, and a slice you can't evaluate or test doesn't get selected. Use after the goal is set and before the spec, so only provable features make the build.
Guided, stateful provisioning of a product's production stack — deep-links, key-format validation, a secrets backend (fnox recommended, or user-touched .env.local), a resumable ledger, CLI automation after signup, and a blocking A1–A10 live gate. Hands off to /security-check → /ship. The walked version of SETUP.md.
Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea.
Launch the factory's control plane — scaffold and fill FACTORY-ORDERS (weekly mandate + hard budget), STANDING-ORDERS (autonomous-program authority), HEARTBEAT (weekly pulse), and write lifecycle gates for every registered product. A deliberate one-time ritual (re-run to audit); invoke as /factory-launch, not auto-triggered.
One-shot a new product — folders, Next.js starter, product.config.json, CLAUDE.md, scope.md, PRD skeleton, SETUP.md checklist. The Lovable-like ignition.
Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.
基于 SOC 职业分类
| name | devils-advocate |
| description | Stress-test an idea or hypothesis. Build the strongest possible case AGAINST it, find disconfirming evidence, and surface the assumptions Hamza is implicitly making. |
| model_tier | opus |
## The kill case
The strongest argument this fails: <one paragraph>
## Hidden assumptions
1. <assumption> — true if <condition>; we don't yet have evidence
2. <assumption> — ...
3. <assumption> — ...
## Disconfirming evidence to look for
- <specific signal that would prove the idea wrong>
- <another signal>
- <another signal>
## Failed analogs
- <prior company / product that tried this and why it failed>
- <another>
## The version that survives
If the above is right and we kept doing this, the version that might actually work is: <one sentence>
## Verdict
- KILL — the case against is strong enough to stop now
- PIVOT — the original is wrong but a near-neighbor might work
- PROCEED with eyes open — case isn't fatal, but track these assumptions
products/<name>/scope.md + prd.md if it's for an existing product).For bets that gate real money or months (per factory/playbooks/mvp-stage/fleet-patterns.md): spawn three blind skeptics, each running this same protocol through ONE lens — (a) market-timing ("why does this fail now?"), (b) moat/copyability ("who copies this in 30 days and wins?"), (c) founder-fit ("why is this the wrong builder/distribution for it?"). Each forces its own verdict without seeing the others. Then synthesize: agreement across skeptics = high-confidence kill signals; disagreement = the exact assumptions to test first. Report the split explicitly — never average three verdicts into mush. The deliverable format above is unchanged; panel mode adds a "Panel split" line under the verdict. Running solo (headless, or a quick gut check): the single-pass protocol above is the whole job.
factory/playbooks/idea-stage/mom-test.mdfactory/playbooks/founders-wisdom/paul-graham-essays.mdfactory/playbooks/ai-native-2026/founders-playbook-distilled.md (re: loss of objectivity)