AgentSkillsCN

thinking-ooda

在动态变化的环境中,建立快速决策循环。适用于事件响应、竞争场景、时效性极强的决策,以及需要迅速适应的情境。

SKILL.md
--- frontmatter
name: thinking-ooda
description: Rapid decision-making loop for dynamic situations. Use for incident response, competitive scenarios, time-sensitive decisions, and situations requiring quick adaptation.

OODA Loop

Overview

The OODA Loop (Observe, Orient, Decide, Act), developed by military strategist Colonel John Boyd, is a framework for rapid decision-making in dynamic, competitive, or time-sensitive situations. The key insight: speed through the loop creates advantage. In competitive scenarios, operating faster than your opponent disrupts their decision-making.

Core Principle: Agility beats perfection. Cycle through OODA faster than the situation changes (or faster than your opponent).

When to Use

  • Incident response and outages
  • Competitive market situations
  • Time-sensitive decisions
  • Rapidly changing requirements
  • Crisis management
  • Debugging under pressure
  • Any situation requiring quick adaptation

Decision flow:

code
Situation changing rapidly? → yes → Need quick decisions? → yes → APPLY OODA LOOP
                                                         ↘ no → Standard analysis
                          ↘ no → Deliberate analysis may be better

The Four Phases

1. OBSERVE

Gather information rapidly

What to observe:

  • Current state of the system/situation
  • Changes since last observation
  • External factors and environment
  • Feedback from previous actions
  • Competitor/opponent movements
code
Incident Example:
- Error rates: Spiking 10x normal
- Affected services: API gateway, user service
- Timeline: Started 5 minutes ago
- Recent changes: Deploy 15 min ago
- User reports: "Can't log in"

Observation principles:

  • Cast wide net initially, narrow as pattern emerges
  • Don't filter prematurely—gather raw data
  • Include lagging AND leading indicators
  • Time-bound: Don't observe forever

2. ORIENT

Make sense of observations

Orientation factors (Boyd's framework):

  • Cultural traditions: How does our org typically respond?
  • Genetic heritage: Our built-in biases and tendencies
  • Previous experience: What have we seen before?
  • New information: What's different this time?
  • Analysis/Synthesis: Combining all of the above
code
Incident Example:
- Pattern matches: Similar to DB connection pool exhaustion last month
- But different: No DB metrics anomaly this time
- Recent deploy touched: Auth service rate limiting
- Hypothesis: Rate limit config too aggressive

Orient is the CRITICAL phase:

  • This is where mental models apply
  • Misorientation leads to wrong decisions
  • Update orientation as new info arrives
  • Challenge your initial framing

3. DECIDE

Select course of action

Decision characteristics:

  • Based on current orientation
  • Acknowledges uncertainty
  • Identifies what to observe next
  • Has implicit/explicit hypothesis
code
Incident Example:
Decision: Roll back auth service deploy
Hypothesis: This will restore normal error rates
Observation plan: Watch error rates for 2 minutes post-rollback
Fallback: If no improvement, investigate DB connections

Decision speed vs. quality tradeoff:

  • 70% confidence now beats 90% confidence too late
  • Reversible decisions: Bias toward action
  • Irreversible decisions: Gather more info first
  • "Good enough" decision executed fast > perfect decision too slow

4. ACT

Execute the decision

Action principles:

  • Execute decisively
  • Immediately return to OBSERVE
  • Don't wait for complete results
  • Create new observations through action
code
Incident Example:
Action: kubectl rollback deployment/auth-service
Immediate observe: Error rates, response times
Time limit: 2 minutes to see effect

The loop restarts:

  • Actions create new situation
  • New situation requires new observation
  • Cycle continues until stable state

OODA Loop Speed

Tempo Advantage

Operating inside opponent's loop:

code
You:     O → O → D → A → O → O → D → A → O ...
Opponent:     O → O → O →  ...  → D → A (too late)

When you complete loops faster:

  • Your actions change situation before they decide
  • Their orientation becomes outdated
  • They react to old information
  • You maintain initiative

Speed Multipliers

FactorEffect
Pre-planned responsesSkip D phase for known scenarios
Distributed authorityParallel loops at different levels
Clear mental modelsFaster O (orientation)
Training/practiceFaster execution (A)
Good observabilityFaster O (observation)

Speed Killers

FactorEffect
Waiting for certaintyLoop stalls at O or D
Hierarchical approvalAdds latency to D
Information overloadO phase never completes
Analysis paralysisLoop stalls at Orient
Perfect solution seekingD phase never completes

Application Patterns

Incident Response

code
OBSERVE: Metrics, logs, alerts, user reports
ORIENT:  Match pattern, form hypothesis, assess blast radius
DECIDE:  Mitigation action (rollback, scale, disable)
ACT:     Execute mitigation, immediately observe results
LOOP:    Continue until stable

Competitive Response

code
OBSERVE: Competitor announcement, market reaction, customer feedback
ORIENT:  Assess threat level, identify our advantages, gaps
DECIDE:  Response strategy (match, differentiate, ignore)
ACT:     Execute response, observe market reaction
LOOP:    Adjust based on effectiveness

Debugging Under Pressure

code
OBSERVE: Error messages, stack traces, recent changes
ORIENT:  Form hypothesis about cause
DECIDE:  Test most likely hypothesis first
ACT:     Add logging, try fix, or eliminate possibility
LOOP:    Update hypothesis based on results

OODA for Teams

Parallel Loops

Different team members can run loops simultaneously:

code
SRE:     Infrastructure OODA (scaling, failover)
Dev:     Code OODA (debugging, fixes)
Support: Communication OODA (users, stakeholders)
Lead:    Strategy OODA (coordination, escalation)

Shared Orientation

Teams need synchronized mental models:

  • Runbooks create shared orientation
  • Incident channels share observations
  • Clear roles enable parallel action
  • Post-incident updates orientation for next time

Verification Checklist

  • Observing actual current state, not assumptions
  • Orientation considers multiple hypotheses
  • Decision is actionable and time-bound
  • Action creates observable feedback
  • Loop is actually cycling (not stuck in one phase)
  • Speed is appropriate to situation urgency

Common Failure Modes

FailureSymptomFix
Observation overloadCan't process all dataFilter to key indicators
Orientation lockStuck on one hypothesisForce alternative framing
Decision paralysisWaiting for certaintySet decision deadline
Action without observationBlind executionMandate observe after act
Single loopNot cyclingTime-box each phase

Key Questions

  • "What do I observe RIGHT NOW?" (not 5 minutes ago)
  • "What does this mean? What pattern does it match?"
  • "What's my best action given current understanding?"
  • "How will I know if my action worked?"
  • "Am I cycling fast enough?"

Boyd's Insight

"He who can handle the quickest rate of change survives."

The goal isn't just making decisions—it's making decisions faster than the situation evolves, faster than competitors adapt, faster than problems compound. Speed creates options; delay eliminates them.