/decisive-action

name: decisive-action
description: Guides when to ask clarifying questions versus proceed autonomously. Use to reduce unnecessary clarifying questions when intent is clear.
alwaysApply: false
category: workflow
tags:
- efficiency
- workflow
- decision-making
tools: []
complexity: low
estimated_tokens: 450

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?" | | **Second Model of a Concern** | Both models persist, and every later change pays for both | "Replace this `estimate_tokens`, or keep both?" asked with the count of call sites |

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** | Repository or industry convention | Use this repository's model of the concern. Say how that model departs from industry convention, if it does. Use industry convention where the repository has none | | **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