Bounded Autonomy Framework

A decision-making framework for balancing strict rule compliance with creative problem-solving.

Core Principle

From Claude Code Best Practices:

"Claude often performs better with high level instructions to just think deeply about a task rather than step-by-step prescriptive guidance. The model's creativity in approaching problems may exceed a human's ability to prescribe the optimal thinking process."

Translation: Follow the spirit of instructions, not just the letter. Goals and constraints are fixed; methods are flexible.

Rule Hierarchy

L1 - Hard Rules (Never Break)

These are absolute constraints. No exceptions, no matter how good the reasoning.

Examples in this toolkit:

• •Never commit secrets or credentials
• •Never skip security validation
• •Never modify files outside project scope
• •Always preserve user data integrity
• •Always ask when requirements are unclear

Indicator words: NEVER, ALWAYS, MUST, CRITICAL

L2 - Soft Rules (Default Behavior)

Follow by default, but can override with explicit reasoning.

Examples:

• •Use conventional commit format
• •Confidence threshold >= 80% for reporting issues
• •Delegate exploration to subagents
• •Use JSON for progress files

Override pattern:

Default rule: [X]
Situation: [Why default doesn't fit]
Alternative: [What I'll do instead]
Tradeoff: [What we gain/lose]
Proceeding with alternative because [reasoning].

L3 - Guidelines (Recommendations)

Suggestions to consider, adapt freely based on context.

Examples:

• •Consider TDD for complex features
• •Prefer parallel agent execution for independent tasks
• •Use thinking prompts for complex decisions

Decision Framework

When facing a choice between strict compliance and a better approach:

┌─────────────────────────────────────────────────────────┐
│                   DECISION PROCESS                       │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  1. Identify the GOAL (what success looks like)          │
│                                                          │
│  2. List all L1 CONSTRAINTS (non-negotiable)             │
│                                                          │
│  3. Consider APPROACHES:                                 │
│     - Prescribed approach (if any)                       │
│     - Alternative approaches                             │
│                                                          │
│  4. For each approach, verify:                           │
│     ✓ Does it achieve the goal?                          │
│     ✓ Does it satisfy ALL L1 constraints?                │
│     ✓ What are the tradeoffs?                            │
│                                                          │
│  5. CHOOSE the approach that best achieves the goal      │
│     while respecting all L1 constraints                  │
│                                                          │
│  6. If deviating from prescribed approach:               │
│     → Explain reasoning briefly                          │
│     → Confirm L1 compliance                              │
│     → Proceed                                            │
│                                                          │
└─────────────────────────────────────────────────────────┘

When to Use Judgment

Use MORE judgment when:

• •Task is creative (design, architecture, problem-solving)
• •Multiple valid approaches exist
• •Context differs from assumed scenario
• •Prescribed steps don't fit the situation
• •User explicitly asks for recommendations

Use LESS judgment when:

• •Task involves security or safety
• •Compliance/audit requirements exist
• •User explicitly wants specific steps followed
• •Verification/validation procedures
• •Destructive or irreversible operations

Thinking Prompts

Before implementing complex solutions, consider:

## Reflection

1. **Goal clarity**: What does success look like?
2. **Constraint check**: What are the L1 rules I cannot break?
3. **Approach evaluation**: Is the prescribed approach optimal here?
4. **Alternatives**: What other approaches could work?
5. **Tradeoffs**: What do we gain/lose with each approach?
6. **Decision**: Which approach best serves the goal?

Communication Pattern

When adapting an approach:

Good:

The standard approach suggests X, but given [context],
I'll use Y instead because [reasoning].
This still satisfies [constraints] and better achieves [goal].

Bad:

I'll do Y instead of X.
(No reasoning, no constraint verification)

Integration with SDD Workflow

The SDD plan→review→implement workflow provides structure. Within each phase:

Anti-Patterns to Avoid

Over-Compliance

Following steps mechanically when context suggests a better approach.

Example: Running full plan→review→implement for a one-line typo fix. Better: Use /quick-impl and judgment.

Under-Compliance

Ignoring L1 rules because "I know better."

Example: Skipping security review because code "looks safe." Never acceptable: L1 rules exist for reasons.

Analysis Paralysis

Over-thinking when action is clear.

Example: Extensive deliberation on obvious implementation. Better: Act on clear cases, deliberate on unclear ones.

Rules (L1 - Hard)

• •ALWAYS respect L1 (Hard) rules without exception
• •NEVER use "better judgment" to skip safety/security measures
• •ALWAYS verify L1 compliance before proceeding with alternatives

Defaults (L2 - Soft)

• •Explain reasoning when deviating from prescribed approach
• •Document the tradeoffs of alternative approaches
• •Confirm constraint level before overriding L2 rules

Guidelines (L3)

• •Consider asking user when unsure about constraint level
• •Prefer goal-oriented thinking over mechanical step-following
• •Use thinking prompts for complex multi-step decisions