- Docs
- Guides
- Product Discovery
- How-to
- How to generate solution options
How to generate solution options
Generate comparable options for an initiative or capability opportunity.
Use this when: You hold a confirmed opportunity at initiative or capability scope and need to surface ≥3 structured, comparable options before committing to a direction in place-bet.
Prerequisites: product-engineering pack installed; a confirmed opportunity at initiative or capability altitude — ideally from identify-opportunities (feature-scope goes to explore-options instead).
Result: A structured options artifact with ≥3 spanning options, a recommended selection with a dominant-bet rationale, and retained reasoning for parked and rejected alternatives.
Use diverge-solutions when you hold a confirmed opportunity at initiative or
capability scope and need to surface the full option space before committing to
a direction. The skill forces ≥3 structured, comparable options — the discipline
that keeps place-bet (step 5) from just ratifying the first idea.
Map the jobs, then generate solution options for teams that need consistent skill discovery across repositories.This guide belongs to the robust shaping path.
When to reach for diverge-solutions vs explore-options
Section titled “When to reach for diverge-solutions vs explore-options”The deciding question is: do you need structured comparable options, or do you need to brainstorm freely?
Reach for diverge-solutions when:
- You hold an initiative- or capability-scope opportunity (from
identify-opportunitiesor a clear signal) and want to generate the option space systematically. - The output needs to be comparable — options must be weighable against one another
so
place-betcan reason about which bet to take. - You want retained rationale for options you park or reject (so they stay revivable).
Reach for explore-options when:
- The input is feature-scoped (a specific screen, endpoint, or component).
- You want a freeform brainstorm with no minimum option count or forced structure.
- You are in a discovery loop pre-G1.5 and structured comparability is not yet needed.
Altitude signal — initiative vs capability vs feature:
- Initiative: affects a whole product area or strategic direction (e.g., “how do we build durable shaping memory for PEs?”).
- Capability: affects a cross-cutting system capability (e.g., “how do we handle context at session start?”).
- Feature: affects a specific user interaction or endpoint — send this to
explore-options.
When altitude is genuinely ambiguous, diverge-solutions will ask rather than
force a level.
How to read a step-2 opportunity and generate spanning options
Section titled “How to read a step-2 opportunity and generate spanning options”A step-2 artifact from identify-opportunities gives you three JTBD layers:
functional (what the user is trying to accomplish), emotional (how they want to
feel doing it), and social (how they want to be seen). Use these layers to stress-
test each option’s key bets.
If you don’t have a step-2 artifact, diverge-solutions will flag the gap and
offer to run identify-opportunities first. You can proceed without it —
the skill will include a “Step 2 readiness” note in the artifact — but expect
the key bets to have less JTBD grounding.
What “spanning” means. Three options that differ only in implementation detail don’t count. Options must differ in at least one of:
- Mechanic: how the opportunity is seized (e.g., structured log vs structured data vs active synthesis).
- Scope: breadth of what is addressed (per-session vs per-initiative vs cross-workspace).
- Bet: what must be true for the option to succeed (e.g., “PEs maintain it consistently” vs “agents parse it reliably” vs “synthesis quality is high enough”).
If you find only two distinct approaches coming to mind, name the constraint — the skill will surface it rather than forcing a third trivial variation.
The key-bets field is where the JTBD grounding pays off. A bet like “users will find this low-friction” is weak. A bet like “PEs already updating the work queue in TOML will adopt this format without additional training” is grounded in functional and social job evidence from step 2.
How to select one option and what makes a sound rationale
Section titled “How to select one option and what makes a sound rationale”diverge-solutions recommends one option and leaves final selection to you.
After the session, mark the selected option in the artifact as selected — this is the PE’s post-emission action; the skill itself never writes selected.
What makes a sound rationale: The rationale should name the dominant bet — the single assumption whose failure would most threaten the option — and explain why the team is willing to take it. “It’s the best” is not a rationale.
Examples:
- Weak: “Option B is recommended because it is simpler.”
- Strong: “Option B — the dominant bet (TOML updates are low-friction for PEs already using the work queue) is defensible given the existing adoption. The rigidity risk is manageable: the schema can grow incrementally.”
Tagging non-recommended options:
rejected: definitively out — you have evidence or a constraint that rules it out. State the evidence.parked: revisable — it’s a valid approach the team isn’t ready to take yet, or whose dominant bet is unresolved. Do not delete it; parked options are revivable when conditions change.
Retaining rejected and parked options is deliberate — the artifact exists to prevent myopic commitment to the first idea. A future PE reviewing the artifact should be able to see why other options were set aside.
What to do with the workspace.toml suggestion
Section titled “What to do with the workspace.toml suggestion”After emitting the artifact, diverge-solutions prints a TOML snippet:
{slug = "<slug>", type = "shape"},Treat the snippet as a routing suggestion, not as the requirements record. Run
work-intake remember with the selected option and its source. work-intake
materializes the canonical Draft artifact first, then registers schema-valid,
non-dispatchable workspace membership. Do not paste a comment-backed or
slug-only entry into workspace.toml.
What happens next: once the option is selected, the next step is validation
(de-risk-intent, step 4). Run it on the selected option to pressure-test the
dominant bet before place-bet commits the direction.
What you have now
Section titled “What you have now”- A structured options artifact with comparable choices and retained rationale for parked or rejected alternatives.
- The selected option can move to
de-risk-intentbeforeplace-betcommits the direction.