---
name: solution-exploration
description: Explores the problem and the range of possible approaches before any code is written — clarifying what is actually being asked, surfacing options with their tradeoffs, and converging on one. Use this at the start of any feature, component, or behavior change, when a request is ambiguous, when the first idea is the only idea on the table, or when a design decision needs pressure-testing before commitment.
---

# Solution exploration

The most expensive bugs are decisions, not defects. This runs before implementation, not instead of
it.

## Establish what is actually wanted

The stated request is a proposed solution wearing the clothes of a requirement. Get underneath it:

- What outcome does the person want? What breaks today without it?
- Who else touches this, and what do they assume about it now?
- What is explicitly **not** being asked for?
- How will we know it worked — the observable difference.

If the answers conflict, stop and resolve that first. Building the average of two requirements
satisfies neither.

## Generate genuinely different options

Two variations of the same idea are one option. Force real range:

- The smallest thing that could work.
- The version that assumes this doubles in scope next quarter.
- The version that requires no new moving parts.
- Buy, borrow, or do nothing.

For each: what it costs, what it forecloses, and what has to be true for it to be right.

## Converge

Recommend one and say why the others lost. A comparison that ends without a recommendation has
moved the work, not done it.

Name the assumption the recommendation rests on most heavily — that is where the plan will break if
it breaks.

## Never

- Present options you would not accept as padding around the one you want.
- Skip this because the task "is simple." Simple tasks take five minutes here.
- Let a preference stand in for a reason.