Agent诊断
- 作者仓库星标 3,406
- 作者更新于 实时读取
- 作者仓库 claude-octopus
- 领域
- 工程开发
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @nyldn · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- macOS · Linux · Windows
- 底层运行要求
- Node.js
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-decision-support
description: Present options with trade-offs for informed decision-making — use when choosing between approac…
category: 工程开发
runtime: Node.js
---
# skill-decision-support 输出预览
## PART A: 任务判断
- 适用问题:代码实现、重构、调试或代码审查。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“Overview / When to Use / The Process”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于代码实现、重构、调试或代码审查,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“Overview / When to Use / The Process”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、执行终端命令、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文出现了 `/octo` 这类斜杠命令;如果你的 Agent 支持命令触发,优先用命令开场,再补充目标和边界。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件、执行终端命令。
先用一个小任务确认它会围绕“Overview / When to Use / The Process”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: skill-decision-support
description: Present options with trade-offs for informed decision-making — use when choosing between approac…
category: 工程开发
source: nyldn/claude-octopus
---
# skill-decision-support
## 什么时候使用
- 把工程方向的常用动作沉淀成 Agent 可调用的技能 适合处理工程开发场景下的代码实现、调试、重构、测试或代码审查,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代…
- 面向代码实现、重构、调试或代码审查,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「Overview / When to Use / The Process」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "skill-decision-support" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> Overview / When to Use / The Process
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> Node.js | 读取文件、写入/修改文件、执行终端命令 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} Host: Codex CLI — This skill was designed for Claude Code and adapted for Codex. Cross-reference commands use installed skill names in Codex rather than
/octo:*slash commands. Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. For host tool equivalents, seeskills/blocks/codex-host-adapter.md.
Decision Support & Options Presentation
Overview
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.
When to Use
Use this skill when user:
- Asks for options or alternatives
- Says "fix or provide options"
- Needs help deciding between approaches
- Wants to see different ways to solve a problem
- Is uncertain about best path forward
Do NOT use for:
- General research ("what is X?") → use flow-probe
- Implementation work → use flow-tangle
- Simple yes/no questions
- Already-decided approaches
The Process
Phase 1: Context Understanding
Step 1: Understand the Decision Point
**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]
Step 2: Gather Requirements
Use AskUserQuestion if needed to understand:
- Must-have requirements
- Nice-to-have features
- Deal-breakers
- Timeline constraints
- Budget/resource constraints
Phase 2: Generate Options
Step 1: Identify Viable Approaches
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:
- Violate stated constraints
- Are clearly inferior to others
- Are essentially the same with minor tweaks
Step 2: Research Each Option
For each option, understand:
- How it works
- What it requires
- What the outcome looks like
- What could go wrong
Phase 3: Trade-off Analysis
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]
Phase 4: Present Options
Format for Presentation
# 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?**
Guidelines for Presentation
- Mark recommendation clearly with ⭐ or "(Recommended)"
- Limit to 2-4 options (too many = decision paralysis)
- Be honest about cons (don't oversell any option)
- Make comparison easy (use consistent structure)
- Support with reasoning (explain why recommendation makes sense)
Phase 5: Support the Choice
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?**
Common Patterns
Pattern 1: "Fix or Provide Options"
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?**
Pattern 2: "What Are My Options"
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?
Pattern 3: "Help Me Decide"
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?
Integration with Other Skills
With flow-probe
Need to research options thoroughly?
→ Use flow-probe to gather information
→ Use skill-decision-support to present findings as options
With flow-tangle
User chose an option?
→ Use flow-tangle to implement the chosen approach
With skill-debug
Bug could be fixed multiple ways?
→ Use skill-decision-support to present fix options
→ Use skill-debug to implement chosen fix systematically
Best Practices
1. Tailor to User's Needs
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?
2. Quantify When Possible
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
3. Be Honest About Unknowns
**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. Provide "Escape Hatch"
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
Red Flags - Don't Do This
| 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 |
Quick Reference
| 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 |
The Bottom Line
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.
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核