Creativity Sampler
Probability-weighted option generator that fights typicality bias and surfaces unconventional alternatives. The core value is exposing hidden assumptions behind the "obvious" choice.
Rules (Absolute)
- Generate exactly 5 options by default. If the decision space has fewer than 4 genuinely distinct approaches, generate all distinct approaches plus at least 1 unconventional reframing of the problem itself. Never pad with trivially different variations of the same idea. If the user specifies a different count, respect it.
- At least 1 option must be unconventional (Unconventional or Wild card zone). This is the whole point — surface ideas that would normally be suppressed.
- Assign relative probability zones that indicate typicality, not quality. Base estimates on observable signals where possible: community adoption, tutorial prevalence, StackOverflow frequency, conference talk frequency. When precise probabilities cannot be grounded, use zone labels instead:
- Conventional (p > 40%) — the "obvious" choice most would pick
- Mainstream (p 20-40%) — commonly considered alternative
- Uncommon (p 10-20%) — valid but often overlooked
- Unconventional (p 5-10%) — challenges assumptions
- Wild card (p < 5%) — radical rethink At least one option must come from the bottom two zones.
- Lower probability = more creative, not worse. Explicitly frame low-p options as valuable exploration.
- No default recommendation. Present all options as viable. Let the user decide after seeing trade-offs.
- Trade-off analysis is mandatory. Each option must have concrete pros/cons, not vague descriptions.
- Ambiguous inputs require clarification. If the decision question is too vague to determine what "unconventional" means, ask one clarifying question about constraints before generating options. Constraints determine the boundary between conventional and unconventional.
Process
Step 1: Check Input Clarity
Before generating options, verify:
- Is the decision clearly stated?
- Are enough constraints known to distinguish conventional from unconventional?
If not, ask one targeted question. Example: "What's your biggest constraint — timeline, budget, or team expertise? This determines which options count as unconventional for your situation."
Step 2: Frame the Decision Space
Identify:
- What is being decided? (technology, architecture, approach, design, strategy)
- What are the constraints? (time, budget, team skill, existing stack)
- What would the "obvious" answer be? (this is what we want to challenge)
Step 3: Generate Options (Distribution-First)
Sample across the full probability distribution, NOT just the top-1 most likely answer.
Probability zones (use zone labels when precise % cannot be grounded):
Conventional (p > 40%) — the "obvious" choice most would pick
Mainstream (p 20-40%) — commonly considered alternative
Uncommon (p 10-20%) — valid but often overlooked
Unconventional (p 5-10%) — challenges assumptions
Wild card (p < 5%) — radical rethink, paradigm shift
Force at least one option from each of the bottom two zones.
Step 4: Analyze Each Option
For every option, provide:
- What it is (1 sentence)
- Why it might be the best choice (strongest argument FOR)
- Why it might fail (strongest argument AGAINST)
- Best suited when... (specific scenario where this option wins)
- Estimated effort relative to other options (Low / Medium / High)
Step 5: Surface Hidden Assumptions
After presenting all options, explicitly state:
- "The conventional choice assumes [X]. If that assumption is wrong, consider options [Y, Z]."
- Identify which constraints, if removed, would change the ranking.
Output Format
## Decision: [The question being decided]
### Constraints
- [constraint 1]
- [constraint 2]
### Options
#### 1. [Option Name] — Conventional (p ~ XX%)
> [One-line description]
| Dimension | Assessment |
|-----------|------------|
| Best argument FOR | [concrete reason] |
| Best argument AGAINST | [concrete reason] |
| Best suited when | [specific scenario] |
| Effort | Low / Medium / High |
| Risk level | Low / Medium / High |
#### 2. [Option Name] — Mainstream (p ~ XX%)
> ...
#### 3. [Option Name] — Uncommon (p ~ XX%)
> ...
#### 4. [Option Name] — Unconventional (p ~ XX%)
> ...
#### 5. [Option Name] — Wild card (p ~ XX%)
> ...
### Hidden Assumptions
- The conventional choice (Option 1) assumes: [assumption]
- If [condition changes], reconsider: Option [N]
- Constraint "[X]" was taken as fixed — but is it really?
### Decision Matrix
| Criteria | Opt 1 | Opt 2 | Opt 3 | Opt 4 | Opt 5 |
|----------|-------|-------|-------|-------|-------|
| [user constraint 1] | Strong / Moderate / Weak | ... | ... | ... | ... |
| [user constraint 2] | Strong / Moderate / Weak | ... | ... | ... | ... |
| [user constraint 3] | Strong / Moderate / Weak | ... | ... | ... | ... |
| **Hidden criterion:** [X] | Strong / Moderate / Weak | ... | ... | ... | ... |
### Decision Matrix Rules
- Derive 3-5 criteria **directly from the user's stated constraints** (budget, timeline, team size, etc.)
- Add exactly 1 criteria the user did NOT mention but should consider (label it "Hidden criterion")
- Rate each option per criterion: **Strong** / **Moderate** / **Weak** (relative to the other options)
- Do NOT use numerical scores — they imply false precision for qualitative assessment
- If one option dominates across all criteria, explicitly note this in Hidden Assumptions — the criteria selection may be biased toward the conventional choice
Quality Calibration
BAD Output (what to avoid)
## Decision: Which database for our new service?
#### 1. PostgreSQL — p ≈ 35%
#### 2. MySQL — p ≈ 25%
#### 3. MariaDB — p ≈ 20%
#### 4. CockroachDB — p ≈ 12%
#### 5. Amazon Aurora — p ≈ 8% ⚡ Unconventional
### Hidden Assumptions
- PostgreSQL is probably the best choice for most use cases.
Problems:
- Options 1-3 are trivially different (all traditional SQL, same paradigm)
- Probabilities are ungrounded — why 35% vs 25%?
- "Unconventional" option (Aurora) is just a managed version of the same thing
- Hidden Assumptions section adds nothing — restates the obvious
- No real diversity of approach
GOOD Output (what to aim for)
## Decision: Which database for our new service?
### Constraints
- Team of 3, familiar with SQL
- Read-heavy analytics + some transactional writes
- Budget: < $500/mo infra
#### 1. PostgreSQL — Conventional (p ~ 50%)
> Battle-tested relational DB with strong analytics extensions (pg_analytics, TimescaleDB).
#### 2. ClickHouse + SQLite — Uncommon (p ~ 15%)
> Split reads (ClickHouse for analytics) from writes (SQLite for transactions). Optimizes for actual access pattern.
#### 3. DuckDB embedded — Unconventional (p ~ 8%)
> In-process analytical DB. Zero infrastructure. Handles the read-heavy workload at zero cost; pair with any simple write store.
#### 4. Managed Supabase — Mainstream (p ~ 22%)
> PostgreSQL with auth/APIs built-in. Trades control for development speed.
#### 5. Event sourcing + materialized views — Wild card (p ~ 5%)
> Don't pick a database — design the data flow. Events are the source of truth; views are disposable projections. Database becomes an implementation detail you can swap later.
### Hidden Assumptions
- The conventional choice assumes your read and write patterns are similar enough for one DB. If analytics queries are 10x more frequent than writes, a split architecture (Opt 2, 3) may cost less and perform better.
- "Team knows SQL" is treated as a constraint, but DuckDB (Opt 3) is also SQL — the real constraint is operational complexity, not query language.
- If the service grows past the team of 3, Option 5's event sourcing makes future database migrations trivial — worth considering if you expect growth.
``