skill-decision-support

宿主：Codex CLI — 此技能最初为 Claude Code 设计，后适配至 Codex。 交叉引用命令在 Codex 中使用已安装的技能名称，而不是 /octo:* 斜杠命令。 使用当前 Codex 会话中的 shell 和子 Agent 工具。在当前会话尚未提供相关能力之前，不要声称某个提供方、模型或宿主子 Agent 可用。 有关宿主工具的对应项，请参阅 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

注意事项——避免以下做法

行为	错误原因
只提供一个“选项”	这并非选择
提供 8 个或更多选项	会让人难以抉择
隐瞒重要缺点	用户无法做出明智选择
不说明理由就提出建议	用户无法评估建议
忽略已说明的限制	浪费用户时间
将明显不佳的选项说成可行方案	损害信任

快速参考

用户请求	操作
“修复或提供选项”	评估是否能明确修复 → 如果可以：给出修复方案；如果不可以：提供选项
“我有哪些选项”	理解上下文 → 生成 2-4 个选项 → 说明各自的权衡
“帮我做决定”	明确决策因素 → 比较不同方法 → 给出并说明推荐理由
“展示替代方案”	生成替代方案 → 分析优缺点 → 提供结构化比较

核心要点

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

理解上下文。提供真正的选择。给出理由支持。尊重他们的决定。