Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Present options with trade-offs for informed decision-making — use when choosing between approaches
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-09 | ✗→✓ | ▲ Improved | 103% | 0% |
| case-01 | ✗→✓ | ▲ Improved | 81% | 0% |
| case-02 | ✗→✓ | ▲ Improved | 72% | 0% |
| case-04 | ✗→✓ | ▲ Improved | 57% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 61% | 0% |
Structured approach to presenting options and alternatives with clear trade-offs, enabling informed decision-making.
Core principle: Understand context → Generate options → Analyze trade-offs → Present clearly → Support choice.
Use this skill when user:
Do NOT use for:
markdown**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]
Use AskUserQuestion if needed to understand:
Generate 2-4 distinct options (not just variations):
| Option Type | When to Include | |-------------|-----------------| | Conservative | Low risk, proven approach | | Moderate | Balanced risk/reward | | Innovative | Higher risk, potentially better outcome | | Minimal | Simplest possible solution |
Don't generate options that:
For each option, understand:
For each option, analyze:
markdown### 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]
markdown# 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?**
After user chooses:
markdown✅ **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].**
If user asks for more info on a specific option:
markdown**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?**
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?**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?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?Need to research options thoroughly?
→ Use flow-probe to gather information
→ Use skill-decision-support to present findings as optionsUser chose an option?
→ Use flow-tangle to implement the chosen approachBug could be fixed multiple ways?
→ Use skill-decision-support to present fix options
→ Use skill-debug to implement chosen fix systematicallyAsk about constraints:
markdownBefore 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?
Good:
**Timeline:**
- Option 1: 2-3 hours
- Option 2: 1-2 days
- Option 3: 1 weekPoor:
**Timeline:**
- Option 1: Quick
- Option 2: A while
- Option 3: Longer**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.Always include:
**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| Action | Why It's Wrong | |--------|----------------| | Only present one "option" | That's not a choice | | Present 8+ options | Decision paralysis | | Hide significant cons | User can't make informed choice | | Recommend without reasoning | User can't evaluate recommendation | | Ignore stated constraints | Wasting user's time | | Present obviously bad options as viable | Undermines trust |
| User Request | Action | |--------------|--------| | "fix or provide options" | Assess if fix obvious → If yes: present fix, if no: present options | | "what are my options" | Understand context → Generate 2-4 options → Present with trade-offs | | "help me decide" | Clarify decision factors → Compare approaches → Recommend with reasoning | | "show alternatives" | Generate alternatives → Analyze pros/cons → Present structured comparison |
Decision support → Clear options + Honest trade-offs + Reasoned recommendation
Otherwise → Confusion + Poor decisions + RegretUnderstand context. Present real choices. Support with reasoning. Respect their decision.
Other measured skills in the registry, with their headline benchmark lift.