plugins/cache/nyldn-plugins/octo/9.30.0/skills/skill-decision-support/SKILL.md
Present options with trade-offs for informed decision-making. Use when: AUTOMATICALLY ACTIVATE when user requests options or choices:. "fix or provide options" or "fix them or provide me options". "give me options" or "what are my options"
npx skillsauth add moliboy5000/.claude skill-decision-supportInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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:
**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:
### 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]
# 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:
✅ **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:
**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 options
User chose an option?
→ Use flow-tangle to implement the chosen approach
Bug could be fixed multiple ways?
→ Use skill-decision-support to present fix options
→ Use skill-debug to implement chosen fix systematically
Ask about constraints:
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?
Good:
**Timeline:**
- Option 1: 2-3 hours
- Option 2: 1-2 days
- Option 3: 1 week
Poor:
**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 + Regret
Understand context. Present real choices. Support with reasoning. Respect their decision.
tools
MANDATORY prerequisite — load this skill BEFORE every `generate_diagram` tool call. NEVER call `generate_diagram` directly without loading this skill first. Trigger whenever the user asks to create, generate, draw, render, sketch, or build a diagram — flowchart, architecture diagram, sequence diagram, ERD or entity-relationship diagram, state diagram or state machine, gantt chart, or timeline. Also trigger when the user mentions Mermaid syntax or wants a system architecture, decision tree, dependency graph, API call flow, auth handshake, schema, or pipeline visualized in FigJam. Routes to type-specific guidance, sets universal Mermaid constraints, and tells you when to use a different diagram type or skip the tool entirely (mindmaps, pie charts, class diagrams, etc.).
development
DEFAULT PIPELINE for all tasks requiring execution. You (Claude) are the strategic orchestrator. Codex agents are your implementation army - hyper-focused coding specialists. Trigger on ANY task involving code, file modifications, codebase research, multi-step work, or implementation. This is NOT optional - Codex agents are the default for all execution work. Only skip if the user explicitly asks you to do something yourself.
development
This skill should be used when the user asks to analyze a UI screen recording and map interaction states into Figma. Trigger for requests such as "put video frames in Figma", "extract states from my recording", "map interactions from video to Figma", "analyze this screen recording", "create a storyboard from my video", "deconstruct this interaction in Figma", "annotate the UI states in my recording", or "pull the key moments from this video into Figma". Also trigger when the user references a video file (.mp4, .mov, .webm, .avi) together with Figma, design review, interaction analysis, prototypes, or UI states. The skill extracts key visual moments from a video, infers interaction triggers, and builds an annotated Figma Design storyboard using native Figma annotations and uploaded screenshot assets.
development
Generate a FigJam project plan board from a PRD plus codebase context. Interactive flow: research → propose sections → per-section deep research → per-section content + block-shape proposal → create FigJam → skeleton → fill → diagrams → wrap. Each content block (section, nested section, intro callout, table, multi-column text, sticky column, diagram section, metadata strip) has its own subskill reference file. Use when the user asks for 'project plan in FigJam', 'interactive project plan', '/generate-project-plan', or provides a PRD and wants per-section confirmation on content + rendering.