跳到主要内容
知仓学习社ZHICANG

decisive-action

Guides when to ask clarifying questions versus proceed autonomously. Use to reduce unnecessary clarifying questions when intent is clear.

不碰外部(只输出文字)无严重或高危命中athola/claude-night-market

它会碰到什么

扫了多少1 个文本文件,6 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 0 · 低 0

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

Decisive Action

Guidance on when to ask clarifying questions versus proceeding autonomously.

When To Use

  • Reducing unnecessary clarifying questions
  • Taking autonomous action when intent is clear

When NOT To Use

  • High-stakes irreversible operations requiring explicit confirmation
  • Ambiguous requirements where clarification prevents wasted work

Core Principle

Ask questions only when ambiguity would materially impair correctness or capacity to fulfill the request precisely.

When to Ask (High Impact Ambiguity)

Always Ask For

| Scenario | Why | Example |

|----------|-----|---------|

| Destructive Operations | Irreversible, high cost of error | "Delete which files?" |

| Multiple Valid Approaches | Materially different tradeoffs | "Add index vs cache vs denormalize?" |

| Security-Critical | Wrong choice = vulnerability | "Which auth method?" |

| Data Migration | Data loss risk | "Preserve or transform?" |

| Breaking Changes | Affects downstream users | "Deprecate or remove?" |

Ask Threshold Checklist

Before asking, verify:

  • [ ] >30% chance of wrong interpretation
  • [ ] Error cost > correction cost
  • [ ] No clear standard approach exists
  • [ ] User context doesn't clarify intent

When to Proceed Without Asking

Default to Action For

| Scenario | Why | Assumption |

|----------|-----|------------|

| Standard Approach Exists | Industry convention | Use conventional pattern |

| Easily Reversible | Low cost of error | Can undo via git/backup |

| Clear from Context | Intent is obvious | Proceed with stated goal |

| User Can Review | PR/dry-run available | Changes are inspectable |

Proceed Threshold Checklist

Proceed without asking if:

  • [ ] Standard/obvious solution exists
  • [ ] Easily reversible (git, backup)
  • [ ] User can review before finalize
  • [ ] Context makes intent clear
  • [ ] Error cost < interruption cost

Decision Matrix

| Reversibility | Ambiguity | Action |

|---------------|-----------|--------|

| Reversible | Low | Proceed |

| Reversible | High | Proceed with preview |

| Irreversible | Low | Proceed with confirmation |

| Irreversible | High | Ask |

Safety Mechanisms

Before Proceeding Autonomously

  1. Dry-run/Preview: Show proposed action before executing
  2. Backup First: Create git branch, backup directory
  3. Incremental Changes: Commit small, reviewable chunks
  4. Document Assumptions: In commit message or PR description

Undo Capability

Always ensure rollback is possible:

  • Git operations: git stash, backup branches
  • File operations: Copy before modify
  • Data operations: Transaction rollback

Examples

Example: Should Ask

User: "Delete the old files"

Analysis:

  • Destructive operation ✗
  • Multiple interpretations ✗
  • No clear standard ✗

Response:

Which files should I delete? I found:
- Files unchanged >6 months: 23 files
- Files in deprecated/: 5 files
- Files marked TODO remove: 2 files

Example: Should Proceed

User: "Add error handling to the parser"

Analysis:

  • Standard approach exists ✓
  • Easily reversible (git) ✓
  • User can review PR ✓

Action: Implement try/catch with logging, create PR.

Example: Proceed with Preview

User: "Refactor the API layer"

Analysis:

  • Multiple valid approaches
  • BUT: reversible via git
  • AND: user can review

Action:

Refactoring API layer. Proposed changes:

1. Extract authentication middleware
2. Standardize error responses
3. Add request validation

Creating branch: refactor/api-layer
Preview diff available before merge.

Anti-Patterns

Asking Too Much (Inefficient)

  • Asking for every implementation detail
  • Seeking validation for obvious choices
  • Repeating questions already answered in context

Asking Too Little (Risky)

  • Proceeding with destructive actions silently
  • Assuming intent when multiple valid interpretations exist
  • Ignoring ambiguity in security-critical operations

Integration

Combine with:

  • conserve:response-compression - Direct communication
  • sanctum:git-workspace-review - Context gathering
  • imbue:scope-guard - Scope management

Quick Reference

| Situation | Action |

|-----------|--------|

| "Delete X" | Ask which X |

| "Add feature" | Proceed with standard approach |

| "Fix bug" | Proceed with obvious fix |

| "Choose between A/B" | Ask for preference |

| "Optimize query" | Ask if multiple approaches |

| "Format code" | Proceed with project style |

| "Deploy to prod" | Ask for confirmation |

Exit Criteria

  • [ ] Every proposed autonomous action checked against the Decision

Matrix: reversibility and ambiguity axes produce an explicit

"Proceed", "Proceed with preview", or "Ask" verdict

  • [ ] Irreversible operations (destructive deletes, data migrations,

breaking changes) never executed without at least one clarifying

question regardless of apparent intent clarity

  • [ ] When proceeding autonomously, one of the four safety mechanisms

is applied: dry-run/preview, backup, incremental commits, or

documented assumptions in the commit message

  • [ ] No clarifying question asked for scenarios in the "Default to

Action" table where standard approach exists and changes are

easily reversible via git

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。