# Decisive Action

> Triggers: question threshold, decisive, autonomous, clarifying questions Guidance on when to ask clarifying questions vs proceed with standard approaches. Reduces interaction rounds while preventing wrong assumptions.

- Skill: `majiayu000/decisive-action` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/decisive-action`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/decisive-action/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/decisive-action

---


# Decisive Action

Guidance on when to ask clarifying questions versus proceeding autonomously.

## 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
1. **Backup First**: Create git branch, backup directory
1. **Incremental Changes**: Commit small, reviewable chunks
1. **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           |