From episteme
Generates exactly 5 probability-weighted alternative options for decisions, forcing at least one unconventional idea with pros/cons trade-offs to expose assumptions.
npx claudepluginhub junjslee/episteme --plugin epistemeThis skill uses the workspace's default tool permissions.
Probability-weighted option generator that fights typicality bias and surfaces unconventional alternatives. The core value is **exposing hidden assumptions** behind the "obvious" choice.
Generates 5 probability-weighted alternative options, including at least one unconventional, with trade-offs to challenge default thinking and expose assumptions in decision points.
Synthesizes options from explore phase into technical/conceptual decision matrices, forces prioritization of trade-offs, challenges choices, and commits to reversible bets.
Generates multiple creative solution approaches with trade-offs using SCAMPER and First Principles frameworks. Hands off to plan skill. Use discovery mode for tasks, vision for products, design-it-twice for interfaces.
Share bugs, ideas, or general feedback.
Probability-weighted option generator that fights typicality bias and surfaces unconventional alternatives. The core value is exposing hidden assumptions behind the "obvious" choice.
Before generating options, verify:
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."
Identify:
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.
For every option, provide:
After presenting all options, explicitly state:
## 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
## 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:
## 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.
Why this is better:
swing-research)/swing-options [question] for quick decision supportwhynowlab/swing-skills