| name | innovate |
| description | Stage 3 of the I-Framework. Pressure-test the chosen bet for differentiation and moat, define the UVP, then decompose it into a complete feature set written to Product/Features/ with each feature classified innovation vs implementation. Produces the framework's final output. Use after /ideate. |
| allowed-tools | Read, Write, Edit, Glob, Grep, AskUserQuestion, Task |
/innovate — Stage 3: define why we win, then spec the features
This is the payoff stage. You retire market, value & moat risk by forcing a clear UVP, then you decompose the bet into the feature set that is the deliverable. Run as a guided interview, one question at a time.
Procedure
1. Load context & check the gate (soft)
Read Product/intent.md and Product/ideation.md. If ideation.md has gate: open, warn ("you haven't settled a validated bet yet — proceed anyway?") but don't block. If ideation.md is missing, suggest /ideate first.
2. Interview for differentiation
Ask, one at a time, challenging thin answers:
- The secret: what do you believe or know that competitors don't?
- Why 10x, not 10%: on which dimension are you an order of magnitude better — painkiller, not vitamin?
- The moat: what stops a fast follower copying you? Does the advantage compound (data, network, switching costs, brand)?
- Validation: what's the cheapest evidence the value is real (willingness-to-pay, retention, "very disappointed" signal)?
3. Write Product/innovation.md
Use the structure from the plugin's templates/innovation.md. You MUST enumerate the UVP elements as an id'd list (UVP-1, UVP-2…) — every innovation feature's contributes_to references one of these ids, so a prose-only UVP silently breaks tracing. Capture the unique insight, why-10x, moat, and validation plan.
3b. (Optional) Ground the UVP in competitor research
Offer to run /compete now. If the founder accepts — or Product/competition.md already exists — use the comparison matrix as evidence for the next steps: a capability that's table-stakes across the matrix becomes implementation; a whitespace capability that maps to a UVP id becomes innovation. If they decline, proceed on judgment. /compete writes Product/competition.md; it's optional and never blocks.
4. Decompose the bet into features
Enumerate every capability the MVP needs to deliver the UVP, plus the table-stakes needed for a usable product. Aim for completeness, not minimalism, at this step — /classify and priority will separate signal from noise.
Optional fan-out (divergent decomposition): for a richer set, spawn 2–3 subagents via the Task tool, each decomposing from a different lens (e.g. "the differentiated core," "the table-stakes shell," "the riskiest assumptions to de-risk"). Dedupe their feature lists before writing. Use this when the product surface is broad; skip it for a tightly-scoped bet.
5. Write one file per feature
For each feature, create Product/Features/F<NNN>-<slug>.md following the feature schema (see the /feature skill / templates/feature.md). For each:
- Complete user story + ≥3 Given/When/Then acceptance criteria.
- Classify innovation vs. implementation with the decision test; set
innovation_weight (implementation = 0; innovation = 1–100); set contributes_to to a UVP id for innovation features; write a one-sentence rationale. If Product/competition.md exists, use the comparison matrix as evidence (universal capability → implementation; only-us + maps-to-UVP → innovation) and reference it in the rationale.
6. Portfolio sanity check
Confirm the healthy shape: mostly implementation with a few sharp, high-weight innovation features tracing to the UVP. If everything reads as innovation, push back — the founder is likely in love with the whole thing. If nothing is innovation, there's no reason to exist; revisit the UVP.
7. Build the index & close the gate
Run the /classify index generation to write Product/features-index.md (ranked). Set innovation.md gate: passed when: UVP stated, ≥1 innovation feature traces to it, and the feature set is complete.
8. Hand off
This is the end of the framework. Point the user to Product/Features/, suggest /product-status for the dashboard, and note that Implementation (the 4th I) is now a clean pick-up for a build team.
