YOLO Interaction

Autonomous execution mode where the agent makes all decisions and takes all actions without seeking confirmation or clarification.

When to Use

Use YOLO mode when:

• •User explicitly requests autonomous operation ("just do it", "YOLO mode", "fully automated")
• •User wants end-to-end automation without interruptions
• •Workflow is well-defined and low-risk
• •Time efficiency is critical
• •User trusts the agent to make reasonable decisions

When NOT to Use

Avoid YOLO mode for:

• •Destructive operations (deleting data, dropping databases)
• •Production deployments
• •Security-sensitive changes
• •Operations requiring approval
• •Ambiguous requirements
• •High-risk or irreversible actions

Characteristics

Decision Making

• •Agent makes all decisions independently
• •Uses best practices and reasonable defaults
• •Resolves ambiguities using context and common patterns
• •No pausing for clarification

Error Handling

• •Attempts automatic recovery
• •Uses fallback strategies
• •Logs errors but continues if possible
• •Only stops for critical, unresolvable blockers

Reporting

• •Minimal interruptions
• •Reports only when complete or blocked
• •Provides summary of actions taken
• •Documents decisions made

Parameters

• •confidence-threshold (default: 0.7): Minimum confidence to proceed without confirmation
• •max-retries (default: 3): Maximum retry attempts for failed operations
• •fallback-strategy: What to do when primary approach fails
• •blockers-only: Only report critical blockers, not progress updates

Behavioral Guidelines

1. Make Reasonable Assumptions

When faced with ambiguity:

• •Use industry best practices
• •Follow established patterns in codebase
• •Choose safe, conservative defaults
• •Document assumptions in code/commits

2. Proceed with Best Effort

• •Attempt task completion even with incomplete information
• •Use context clues and workspace analysis
• •Implement most likely interpretation
• •Handle edge cases gracefully

3. Minimize User Interaction

• •No confirmation prompts
• •No clarifying questions
• •No progress check-ins (unless critical)
• •Report only final results

4. Auto-Resolve Issues

When encountering problems:

• •Try automatic fixes first
• •Use retry logic for transient failures
• •Apply known solutions to common issues
• •Fall back to safe alternatives

5. Track Decisions

Document autonomous decisions:

• •Log assumptions made
• •Record alternatives considered
• •Note confidence levels
• •Explain trade-offs

YOLO Workflows

Pattern 1: End-to-End Automation

User request: "Process and merge all approved PRs"

YOLO execution:

1. •List all open PRs
2. •Filter for approved PRs
3. •For each approved PR:
   • •Check status checks
   • •Resolve any resolvable threads
   • •Merge if ready
   • •Delete branch
4. •Report summary

No confirmations, no check-ins, complete autonomy.

Pattern 2: Fix All Issues

User request: "Fix all linting errors"

YOLO execution:

1. •Run linter
2. •Parse errors
3. •Apply auto-fixes
4. •Run linter again
5. •Manually fix remaining issues
6. •Commit changes
7. •Report results

Pattern 3: Multi-Step Pipeline

User request: "Deploy to staging"

YOLO execution:

1. •Run tests
2. •Build artifacts
3. •Update version
4. •Deploy to staging
5. •Run smoke tests
6. •Notify team
7. •Report completion

Decision Framework

When making autonomous decisions, prioritize:

1. •Safety: Choose safe over risky
2. •Reversibility: Prefer reversible actions
3. •Standards: Follow established conventions
4. •Simplicity: Choose simple over complex
5. •Documentation: Document non-obvious choices

Confidence Levels

Guide for proceeding without confirmation:

Error Recovery Strategies

Strategy 1: Retry with Backoff

For transient failures (network, rate limits):

• •Retry 3 times with exponential backoff
• •Log each attempt
• •Proceed to fallback after max retries

Strategy 2: Alternative Approach

For method failures:

• •Try alternative tool/approach
• •Use workaround if available
• •Document deviation from primary plan

Strategy 3: Partial Completion

For multi-step workflows:

• •Complete what's possible
• •Skip failed steps
• •Report partial results and failures

Strategy 4: Graceful Degradation

For feature failures:

• •Implement core functionality
• •Skip optional enhancements
• •Note limitations in output

Reporting Format

YOLO mode reports should be concise:

TASK: Process approved PRs
STATUS: Complete

ACTIONS TAKEN:
- Processed 3 approved PRs
- Merged PR #42, #45, #47
- Deleted 3 feature branches
- Resolved 5 review threads

DECISIONS MADE:
- Used squash merge (most common in repo)
- Auto-resolved "LGTM" threads
- Deleted branches (no active work)

ISSUES:
- PR #44 has failing checks (skipped)

Integration with Other Skills

YOLO mode can orchestrate:

• •parallel-execution: Launch multiple autonomous tasks
• •sequential-execution: Execute multi-stage pipelines
• •pull-request-tool: Autonomous PR processing
• •merge-pr: Auto-merge ready PRs
• •resolve-pr-comments: Auto-resolve threads

Best Practices

1. •Set clear scope: Understand full extent of automation
2. •Use safe defaults: Conservative choices when uncertain
3. •Log everything: Comprehensive action logging
4. •Validate inputs: Ensure prerequisites met before starting
5. •Plan rollback: Know how to undo if needed
6. •Test first: Validate approach on small scale if possible
7. •Document decisions: Explain non-obvious choices
8. •Report concisely: Summary at end, not play-by-play

Safety Guardrails

Even in YOLO mode, always:

• •✅ Validate syntax before committing
• •✅ Run tests before merging
• •✅ Check for merge conflicts
• •✅ Verify permissions before operations
• •✅ Back up before destructive changes
• •❌ Never delete production data
• •❌ Never disable security features
• •❌ Never skip required approvals
• •❌ Never ignore critical errors

Quick Reference

WHEN TO USE:
  ✓ User requests autonomous operation
  ✓ Well-defined workflow
  ✓ Low-risk actions
  ✓ Efficiency critical

CHARACTERISTICS:
  - No confirmations
  - No clarifying questions
  - Auto-resolve issues
  - Report only results

DECISION MAKING:
  - Use best practices
  - Safe defaults
  - Document assumptions
  - Log decisions

ERROR HANDLING:
  - Retry transient failures
  - Use fallback strategies
  - Partial completion OK
  - Stop only for critical blockers

SAFETY:
  - Validate before commit
  - Test before merge
  - Never delete production data
  - Never skip required approvals