Menú
Turn vague problem observations into testable hypothesis statements with specific who/when/severity/current-workaround dimensions.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
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.
| name | problem-sharpener |
| description | Turn vague problem observations into testable hypothesis statements with specific who/when/severity/current-workaround dimensions. |
| model_tier | opus |
User provides a problem in vague form ("X is hard", "people struggle with Y") or asks "is this problem statement good enough to validate?"
A sharpened hypothesis in this exact format:
**Sharpened hypothesis:**
<specific role> at <specific company type / life stage> spend <specific time/$/effort> on <specific task> because <specific reason / missing capability>. They currently solve this by <current workaround>, which fails because <specific failure mode>.
**Testability check:**
- Who exactly: ✅ / ❌ (and what's missing)
- How often: ✅ / ❌
- How severe: ✅ / ❌
- Current workaround named: ✅ / ❌
**Next move:** <the first 5 interviews to run, with target profile>
factory/playbooks/idea-stage/problem-statement-rubric.md.Input: "Founders waste a lot of time on customer interviews."
Output:
Pre-PMF B2B SaaS founders (1–3 years in) spend 8–15 hours per validation cycle scheduling, conducting, and synthesizing customer interviews because their notes live across Notion + voice memos + Zoom transcripts with no consistent structure. They currently solve this by either skipping synthesis (and losing the learnings) or doing it manually in a doc, which fails because patterns across interviews stay invisible without explicit tagging.
Per factory/playbooks/mvp-stage/agent-handoff-contracts.md:
**Sharpened hypothesis:** paragraph · **Testability check:** with all four dimensions (who / how often / how severe / workaround) each marked ✅/❌ · **Next move:** naming the first-5-interviews target profile.factory/playbooks/idea-stage/problem-statement-rubric.mdfactory/playbooks/idea-stage/jobs-to-be-done.mdfactory/playbooks/idea-stage/mom-test.md