From swing-skills
Generates 5 probability-weighted alternative options, including at least one unconventional, with trade-offs to challenge default thinking and expose assumptions in decision points.
How this skill is triggered — by the user, by Claude, or both
Slash command
/swing-skills:swing-optionsThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Probability-weighted option generator that fights typicality bias and surfaces unconventional alternatives. The core value is **exposing hidden assumptions** behind the "obvious" choice.
Probability-weighted option generator that fights typicality bias and surfaces unconventional alternatives. The core value is exposing hidden assumptions behind the "obvious" choice.
Addresses the cognitive failure of Anchoring Bias — AI defaults to the first or most obvious solution without exploring the full decision space, causing users to miss superior alternatives they never considered.
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 supportnpx claudepluginhub thestack-ai/swing-skillsGenerates probability-weighted alternative options to challenge default thinking and expose hidden assumptions. Useful for decision-point analysis.
Generates multiple options before evaluating any, using de Bono's APC tool. Useful when making decisions, feeling stuck between two paths, or planning to ensure all approaches are considered.
Presents structured options with trade-offs when users ask for alternatives, need help deciding between approaches, or are uncertain about the best path forward.