swing-options

Creativity Sampler

典型性バイアスに対抗し、型破りな代替案を浮かび上がらせる、確率で重み付けされた選択肢ジェネレーターです。中核となる価値は、「明白な」選択の裏にある隠れた前提を明らかにすることです。

アンカリングバイアスという認知上の問題に対処します。AI は、意思決定の全体像を探ることなく、最初の解決策や最も明白な解決策をデフォルトで選びがちです。その結果、ユーザーは検討したことのない、より優れた代替案を見逃してしまいます。

ルール（必須）

1. デフォルトでは選択肢をちょうど5つ生成します。 意思決定の範囲に、真に異なるアプローチが4つ未満しかない場合は、すべての異なるアプローチに加えて、問題そのものを型破りな視点で捉え直す案を少なくとも1つ生成します。実質的には同じアイデアの、取るに足らない違いで水増ししてはいけません。ユーザーが別の数を指定した場合は、その指定に従います。
2. 少なくとも1つの選択肢は型破りなものでなければなりません（「型破り」または「ワイルドカード」ゾーン）。これが本来の目的です。通常なら退けられてしまうアイデアを浮かび上がらせます。
3. 相対的な確率ゾーンを割り当てます。これは品質ではなく、典型性を示すものです。可能であれば、コミュニティでの採用状況、チュートリアルの普及度、StackOverflow での頻度、カンファレンストークの頻度など、観測可能な指標を基に推定します。正確な確率を根拠に基づいて示せない場合は、代わりにゾーンのラベルを使います。
   • 一般的（p > 40%）— ほとんどの人が選ぶ「明白な」選択肢
   • 主流（p 20-40%）— よく検討される代替案
   • あまり一般的でない（p 10-20%）— 有効だが見落とされがちな選択肢
   • 型破り（p 5-10%）— 前提に異議を唱える選択肢
   • ワイルドカード（p < 5%）— 抜本的な再考 少なくとも1つの選択肢は、下位2つのゾーンから選ぶ必要があります。
4. 確率が低いほど、創造性が高いのであり、質が低いという意味ではありません。確率の低い選択肢も、価値ある探索対象として明示的に位置付けます。
5. デフォルトの推奨案を示しません。 すべての選択肢を実行可能な案として提示します。トレードオフを確認したうえで、ユーザーが判断できるようにします。
6. トレードオフの分析は必須です。 それぞれの選択肢について、曖昧な説明ではなく、具体的な長所と短所を示します。
7. 入力が曖昧な場合は、確認が必要です。 意思決定の内容が曖昧で、「型破り」の意味を判断できない場合は、選択肢を生成する前に制約について確認する質問を1つだけします。制約によって、一般的な案と型破りな案の境界が決まります。

プロセス

ステップ1：入力の明確さを確認する

選択肢を生成する前に、次の点を確認します。

• 何を決めるのかが明確ですか？
• 一般的な案と型破りな案を区別するのに十分な制約が分かっていますか？

不明な場合は、要点を絞った質問を1つします。例：「最大の制約は何ですか？ 期間、予算、チームの専門知識のどれでしょうか？ あなたの状況でどの案が型破りに当たるかを判断するために必要です。」

ステップ2：意思決定の範囲を定める

以下を特定します。

• 何を決めるのか（技術、アーキテクチャ、アプローチ、設計、戦略）
• どのような制約があるのか（時間、予算、チームのスキル、既存のスタック）
• 「明白な」答えは何か（これこそ、異議を唱えたいものです）

ステップ3：選択肢を生成する（分布を優先）

最も可能性の高い答えを1つだけ選ぶのではなく、確率分布全体から選択肢を抽出します。

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

下位2つのゾーンから、それぞれ少なくとも1つの選択肢を必ず含めます。

ステップ4：各選択肢を分析する

すべての選択肢について、以下を提示します。

1. どのような案か（1文）
2. 最善の選択肢となり得る理由（最も強い賛成意見）
3. 失敗する可能性がある理由（最も強い反対意見）
4. 最適な状況（この選択肢が最も有効な具体的なシナリオ）
5. 相対的な作業量（他の選択肢との比較。低／中／高）

ステップ5：隠れた前提を明らかにする

すべての選択肢を提示した後、以下を明示します。

• 「一般的な選択肢は、[X] という前提に基づいています。その前提が誤っている場合は、[Y, Z] を検討してください。」
• どの制約を取り除けば、順位が変わるかを特定します。

出力形式

## 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.

問題点：

• 選択肢 1〜3 は、どれも従来型の SQL で、同じパラダイムの些細な違いにすぎません
• 確率に根拠がありません。なぜ 35％で、25％ではないのでしょうか？
• 「型破り」な選択肢（Aurora）も、同じもののマネージド版にすぎません
• 「隠れた前提」セクションには何もなく、自明なことを言い換えているだけです
• アプローチに本当の多様性がありません

目指すべき良い出力

## 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.

優れている理由：

• 各選択肢が根本的に異なるアプローチ（単一の DB、分割アーキテクチャ、組み込み、マネージド、パラダイムシフト）を表しています
• ゾーンラベルは、観察可能な採用傾向に基づいています
• 「隠れた前提」セクションが問題の捉え方に異議を唱え、具体的な選択肢に結び付けています
• ワイルドカードの選択肢は、単にマイナーな技術を選ぶのではなく、問題そのものを捉え直しています

使用する場面

• アーキテクチャの決定：「モノリスか、マイクロサービスか、それとも……」
• 技術の選定：「どのデータベース／フレームワーク／言語を選ぶか」
• 設計アプローチ：「この機能をどのように構成するか」
• 戦略：「どのようにローンチ／マーケティング／スケーリングを行うか」
• 問題解決：「これをどう修正／改善／最適化できるか」
• 1 つの明白な答えに頼りそうになったときはいつでも

使用しない場面

• 正解が 1 つの事実に関する質問（swing-research を使ってください）
• 要件が明確で、決定すべき点がないタスク
• アプローチが明白で、異論の余地がない単純な実装
• ユーザーがすでに決定を下しており、実行だけを求めている場合

統合に関するメモ

• swing-clarify との併用： あいまいな依頼では、このスキルを呼び出す前に swing-clarify を実行してください。範囲を明確にすると、より良い結果が得られます。
• swing-review との併用： 選んだ選択肢を敵対的レビューに渡し、ストレステストを行います
• 単独での使用： すばやく意思決定を支援するには、/swing-options [question] を直接呼び出してください

注意点

• 見せかけの多様性： 同じものの些細な違いにすぎない選択肢を生成しないでください。それぞれが、根本的に異なるアプローチまたはパラダイムを表す必要があります。
• 確率の演出： 根拠を示せない具体的なパーセンテージを割り当てないでください。観察可能なデータがない場合は、ゾーンラベルを使ってください。「一般的」は誠実ですが、「p = 37.2%」はそうではありません。
• 要点を埋もれさせない： 制約を考慮すると、ある選択肢が圧倒的に優れている場合は、「隠れた前提」でそう伝えてください。ただし、すべての選択肢を公平に提示してください。
• 制約を無視しない： ワイルドカードの選択肢も、予想外の道筋を使いながら、明示された制約の範囲内で実現可能である必要があります。
• 中身のない「隠れた前提」： 「選択肢 1 が最善と思われます」は前提の分析ではありません。具体的な前提を示し、何がそれを覆すのかを述べ、どの選択肢が恩恵を受けるのかを指摘してください。
• 基準のすり替え： 従来型の選択肢に自然と有利になるような判断マトリクスの基準を選ばないでください。選択肢 1 がすべての項目で勝つなら、基準に偏りがあります。そのことを指摘してください。