skill-decision-support

ホスト：Codex CLI — このスキルはClaude Code向けに設計され、Codex向けに調整されています。 相互参照するコマンドでは、/octo:* スラッシュコマンドではなく、Codexでインストール済みのスキル名を使用します。 アクティブなCodexシェルとサブエージェントツールを使用してください。現在のセッションで利用可能であることが確認できるまでは、プロバイダー、モデル、ホストのサブエージェントが利用可能だと断言しないでください。 ホストツールに相当するものについては、skills/blocks/codex-host-adapter.md を参照してください。

意思決定の支援と選択肢の提示

概要

選択肢や代替案を、トレードオフを明確にしながら提示するための体系的なアプローチです。十分な情報に基づいた意思決定を支援します。

基本原則： 状況を把握する → 選択肢を考える → トレードオフを分析する → 明確に提示する → 選択を支援する。

使用する場面

次のような場合にこのスキルを使用します：

• 選択肢や代替案を求められた場合
• 「修正するか、選択肢を提示して」と言われた場合
• アプローチの選択について支援が必要な場合
• 問題を解決するさまざまな方法を知りたい場合
• 最善の進め方がわからない場合

次の場合は使用しないでください：

• 一般的な調査（「Xとは何ですか？」）→ flow-probe を使用
• 実装作業 → flow-tangle を使用
• 単純な「はい／いいえ」の質問
• すでに方針が決まっている場合

プロセス

フェーズ1：状況の把握

ステップ1：意思決定のポイントを理解する

**Decision Context:**

What needs to be decided: [the core question]
Why it matters: [impact of this decision]
Constraints: [time, resources, compatibility, etc.]
Current state: [what exists now]

ステップ2：要件を集める

必要に応じてAskUserQuestionを使用し、次の点を確認します：

• 必須要件
• あると望ましい機能
• 受け入れられない条件
• スケジュール上の制約
• 予算やリソースの制約

フェーズ2：選択肢を考える

ステップ1：実現可能なアプローチを特定する

明確に異なる選択肢を2～4個考えます（単なるバリエーションにしないでください）。

選択肢の種類	含める場面
保守的	リスクが低く、実績のあるアプローチ
中程度	リスクとリターンのバランスが取れたアプローチ
革新的	リスクは高いものの、より良い結果が期待できるアプローチ
最小限	可能な限りシンプルな解決策

次のような選択肢は考えないでください：

• 明示された制約に違反するもの
• 他の選択肢より明らかに劣るもの
• わずかな変更を加えただけで、実質的に同じもの

ステップ2：各選択肢を調査する

選択肢ごとに、次の点を把握します：

• どのように機能するか
• 何が必要か
• どのような結果になるか
• どのような問題が起こり得るか

フェーズ3：トレードオフの分析

選択肢ごとに、次の点を分析します：

### Option N: [Name]

**Description:**
[1-2 sentence description]

**Pros:**
- ✅ [Advantage 1]
- ✅ [Advantage 2]
- ✅ [Advantage 3]

**Cons:**
- ❌ [Disadvantage 1]
- ❌ [Disadvantage 2]
- ❌ [Disadvantage 3]

**Effort:** [Low/Medium/High]
**Risk:** [Low/Medium/High]
**Reversibility:** [Easy/Moderate/Difficult to undo]

**Best for:** [when this option makes sense]

フェーズ4：選択肢を提示する

提示形式

# Decision: [What needs to be decided]

**Context:** [Brief summary of why this decision is needed]


## Option 1: [Conservative/Proven Approach] ⭐ (Recommended)

**What it is:**
[Clear explanation in 1-2 sentences]

**Pros:**
- ✅ [Pro 1]
- ✅ [Pro 2]
- ✅ [Pro 3]

**Cons:**
- ❌ [Con 1]
- ❌ [Con 2]

**Implementation:**
[Brief overview of what's involved]

**Timeline:** [estimate]
**Risk Level:** Low/Medium/High


## Option 2: [Alternative Approach]

[Same structure as Option 1]


## Option 3: [Another Alternative]

[Same structure as Option 1]


## Recommendation

**I recommend Option [N]: [Name]**

**Why:**
1. [Reason 1]
2. [Reason 2]
3. [Reason 3]

**This option is best because:** [summary of key advantage relative to context]


## Quick Comparison

| Criteria | Option 1 | Option 2 | Option 3 |
|----------|----------|----------|----------|
| Effort | [level] | [level] | [level] |
| Risk | [level] | [level] | [level] |
| Reversible | [yes/no] | [yes/no] | [yes/no] |
| Timeline | [time] | [time] | [time] |
| Best for | [scenario] | [scenario] | [scenario] |


**Which option would you like to proceed with?**

提示のガイドライン

1. ⭐または「（推奨）」を付けて、推奨案を明確に示す
2. 選択肢は2～4個に絞る（多すぎると意思決定が難しくなります）
3. デメリットを正直に伝える（どの選択肢も過度に売り込まないでください）
4. 比較しやすくする（一貫した構成を使用してください）
5. 理由を添える（推奨案が妥当である理由を説明してください）

フェーズ5：選択を支援する

ユーザーが選択した後：

✅ **Proceeding with Option [N]: [Name]**

**Next steps:**
1. [Step 1]
2. [Step 2]
3. [Step 3]

**I'll now [begin implementation / gather more details / create plan].**

ユーザーが特定の選択肢について詳しい情報を求めた場合：

**Deep dive on Option [N]:**

**How it works:**
[Detailed explanation]

**Implementation steps:**
1. [Detailed step 1]
2. [Detailed step 2]
...

**Potential issues and mitigations:**
- Issue: [potential problem]
  Mitigation: [how to handle it]

**Would you like to proceed with this option?**

よくあるパターン

パターン1：「修正するか、選択肢を提示して」

User: "The auth system is broken. Fix or provide options."

Response structure:
1. Assess: Is the fix obvious or are there choices?
2. If obvious: Present the fix + ask for confirmation
3. If choices: Present options with trade-offs

Example:

I can see the auth issue. Here are your options:

**Option 1: Quick Fix** (Recommended for immediate deployment)
- Patch the current JWT validation
- Pros: Fast, low risk
- Cons: Doesn't address underlying architecture

**Option 2: Comprehensive Refactor**
- Rebuild auth with better patterns
- Pros: Long-term solution
- Cons: Takes longer, more testing needed

**Which approach fits your timeline?**

パターン2：「どんな選択肢がありますか」

User: "I need to add caching. What are my options?"

Response structure:
1. Understand requirements (what needs caching, scale, etc.)
2. Generate 3-4 caching options
3. Present with trade-offs
4. Recommend based on their context

Example:

For caching your API responses, here are the main options:

**Option 1: In-Memory Cache (Node-cache)** ⭐
- Best for: Single-server setup
- Pros: Simple, fast, no external dependencies
- Cons: Lost on restart, doesn't scale across servers

**Option 2: Redis**
- Best for: Multi-server or persistence needed
- Pros: Persistent, distributed, feature-rich
- Cons: Requires Redis server, more complex

**Option 3: CDN Caching (Cloudflare/Fastly)**
- Best for: Static/semi-static content
- Pros: Global distribution, handles scale
- Cons: Less control, costs, public content only

**Based on your single-server setup, Option 1 is recommended.**
Which would you like to use?

パターン3：「決めるのを手伝って」

User: "Should I use TypeScript or stick with JavaScript? Help me decide."

Response structure:
1. Clarify decision factors (team size, project scope, timeline)
2. Present structured comparison
3. Make recommendation based on their specific context
4. Support whatever they choose

Example:

Let me help you decide between TypeScript and JavaScript.

**TypeScript:**
Pros: Type safety, better tooling, catches errors early
Cons: Learning curve, build step, more setup
Best for: Larger teams, long-term projects, complex domains

**JavaScript:**
Pros: Simpler, no build step, familiar to all devs
Cons: Runtime errors, less IDE support, harder to refactor
Best for: Small projects, prototypes, simple applications

**For your [context]:** I recommend TypeScript because [reason].

Would you like to proceed with TypeScript, or would JavaScript be better for your needs?

他のスキルとの連携

flow-probeとの連携

Need to research options thoroughly?
→ Use flow-probe to gather information
→ Use skill-decision-support to present findings as options

flow-tangleとの連携

User chose an option?
→ Use flow-tangle to implement the chosen approach

skill-debugとの連携

Bug could be fixed multiple ways?
→ Use skill-decision-support to present fix options
→ Use skill-debug to implement chosen fix systematically

ベストプラクティス

1. ユーザーのニーズに合わせる

制約について尋ねます：

Before presenting options, I need to understand:
- Timeline: How urgent is this?
- Resources: What's available (team size, budget, infrastructure)?
- Risk tolerance: Is this production-critical or experimental?
- Reversibility: Must this decision be reversible?

2. 可能な場合は数値で示す

良い例：

**Timeline:**
- Option 1: 2-3 hours
- Option 2: 1-2 days
- Option 3: 1 week

悪い例：

**Timeline:**
- Option 1: Quick
- Option 2: A while
- Option 3: Longer

3. 不明な点は正直に伝える

**Option 2: Microservices Architecture**

⚠️ **Unknown:** Migration effort could be 2-4 weeks depending on current coupling.
Would need to audit codebase to give accurate estimate.

4. 「別の選択肢」も用意する

必ず次の内容を含めます：

**Not satisfied with these options?**

I can also:
- Research more alternatives
- Combine aspects of multiple options
- Deep-dive on any specific approach
- Prototype a solution to test viability

注意すべき兆候 — してはいけないこと

行動	問題点
「選択肢」を1つだけ提示する	それでは選べません
8個以上の選択肢を提示する	意思決定が難しくなります
重大なデメリットを隠す	ユーザーが十分な情報に基づいて選べません
理由を示さずに推奨する	ユーザーが推奨案を評価できません
明示された制約を無視する	ユーザーの時間を無駄にします
明らかに悪い選択肢を実現可能な案として提示する	信頼を損ないます

クイックリファレンス

ユーザーの依頼	対応
「修正するか、選択肢を提示して」	修正が明らかかを判断 → 明らかな場合：修正を提示、そうでない場合：選択肢を提示
「どんな選択肢がありますか」	文脈を把握 → 2～4 個の選択肢を生成 → トレードオフとともに提示
「決めるのを手伝って」	判断要素を明確化 → アプローチを比較 → 理由を添えて推奨
「代替案を見せて」	代替案を生成 → 長所と短所を分析 → 構造化した比較を提示

要点

Decision support → Clear options + Honest trade-offs + Reasoned recommendation
Otherwise → Confusion + Poor decisions + Regret

文脈を把握します。実際の選択肢を提示します。理由を添えて支援します。相手の決定を尊重します。