
Decisive Action
- 103 installs
- 325 repo stars
- Updated August 2, 2026
- athola/claude-night-market
Decisive Action is an agent skill that guides when to ask clarifying questions versus proceed autonomously—usable whenever a solo builder needs to reduce wasted back-and-forth before committing agent work.
About
Decisive Action is a journey-wide agent skill that teaches when to ask clarifying questions versus moving forward autonomously. It is aimed at solo and indie builders who lose time when agents over-clarify obvious tasks or under-clarify risky ones. The skill encodes a decision framework: proceed when intent is clear and reversible; pause when destruction, security, ambiguous tradeoffs, data migration, or breaking changes could make a wrong guess expensive. A short checklist ties question-asking to estimated misinterpretation risk and correction cost. Because it is marked alwaysApply in the source skill, it is meant to ride along during Idea scoping, Validate prototypes, Build and Ship edits, and Operate fixes—not only one phase. Use it to make agents feel more like a decisive teammate while keeping guardrails on irreversible operations.
- Core rule: ask only when ambiguity would materially impair precise fulfillment
- Explicit always-ask table for destructive ops, security, migrations, and breaking changes
- Ask-threshold checklist (>30% wrong interpretation, error cost vs correction cost)
- alwaysApply guidance to reduce low-value clarifying questions across sessions
- When NOT to use: high-stakes irreversible work and genuinely ambiguous requirements
Decisive Action by the numbers
- 103 all-time installs (skills.sh)
- Ranked #1,358 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Security screen: MEDIUM risk (skills.sh audit)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/athola/claude-night-market --skill decisive-actionAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 103 |
|---|---|
| repo stars | ★ 325 |
| Security audit | 3 / 3 scanners passed |
| Last updated | August 2, 2026 |
| Repository | athola/claude-night-market ↗ |
What it does
Cut agent busywork by proceeding when intent is clear and reserving clarifying questions for ambiguity that would materially break correctness.
Who is it for?
Best when you want faster agent sessions on routine coding while keeping hard stops for deletes, auth choices, migrations, and breaking API changes.
Skip if: Workflows where every step legally or contractually requires human sign-off, or requirements that remain genuinely ambiguous and need discovery before any implementation.
When should I use this skill?
Reducing unnecessary clarifying questions or taking autonomous action when intent is clear; not for high-stakes irreversible operations without explicit confirmation.
What you get
Agents default to autonomous execution when intent is clear and only escalate questions that materially affect correctness, safety, or irreversible outcomes.
- Consistent ask-vs-act behavior across agent sessions
- Explicit escalation on destructive, security, migration, and breaking-change work
By the numbers
- Ask-threshold checklist with >30% wrong-interpretation gate
- Five always-ask scenario categories in the decision table
Files
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 filesExample: 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 communicationsanctum:git-workspace-review- Context gatheringimbue: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
Related skills
How it compares
Use as standing agent judgment policy instead of ad-hoc 'just ask me everything' or 'never ask' chat instructions.
FAQ
Who is decisive-action for?
Developers and teams using Claude Code, Cursor, or similar agents who want fewer unnecessary questions without sacrificing safety on high-impact decisions.
When should I use decisive-action?
Across Idea and Validate when scoping features; during Build and Ship when implementing and reviewing; and in Operate when fixing production—anytime agent autonomy vs clarification tradeoffs appear.
Is decisive-action safe to install?
It is behavioral guidance only; confirm behavior against your repo policies and review the Security Audits panel on this Prism page before relying on it in regulated environments.