Use under time pressure (incident, outage, debugging a moving target) when you must act before you have certainty—cycle Observe→Orient→Decide→Act on ~70% confidence, then re-observe.
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/thinking-ooda
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Use under time pressure (incident, outage, debugging a moving target) when you must act before you have certainty—cycle Observe→Orient→Decide→Act on ~70% confidence, then re-observe.
📊 Stats
Stars863
Forks126
LanguageJavaScript
LicenseMIT
📦 Ships with thinking-skills
</> SKILL.md
thinking-ooda.SKILL.md
---name: thinking-ooda
description: Use under time pressure (incident, outage, debugging a moving target) when you must act before you have certainty—cycle Observe→Orient→Decide→Act on ~70% confidence, then re-observe.
---# OODA Loop
## Overview
The OODA Loop (Observe, Orient, Decide, Act) is a framework for acting in fast-moving, uncertain situations. The core decision rule: don't wait for certainty—act on the best current understanding, then immediately observe the result and loop again. Speed through the loop beats a perfect plan that arrives too late.
**Core Principle:** Act on ~70% confidence for reversible moves, then re-observe. Cycle faster than the situation changes.
## When to Use
- Incident response and outages
- Debugging a moving target (intermittent failure, ongoing degradation)
- Any time-sensitive decision where the situation is still changing
```
Situation changing rapidly AND need to act before certainty? → yes → APPLY OODA
→ no → use deliberate analysis / a hypothesis differential
```
## When NOT to Use
- The situation is static and you have time → deliberate analysis beats fast looping.
- The action is irreversible/high-blast-radius → gather more information before acting; 70% confidence isn't enough.
- You can cheaply and directly localize the cause (read the diff/log) → use `thinking-scientific-method` (hypothesis differential) instead of looping in the dark.
When under time pressure (incident, outage, debugging a moving target) and you must act before certainty:
1. **Observe** — what is happening right now? Gather the cheapest, highest-signal data available.
2. **Orient** — what does it mean given your mental model? Update the model if the data contradicts it.
3. **Decide** — pick an action on ~70% confidence. Don't wait for 100%.
4. **Act** — execute, then immediately re-observe. The loop is the point; speed beats precision.
If the action is irreversible or high-blast-radius, gather more information before acting. If you can cheaply localize the cause (read the diff/log), use `thinking-scientific-method` instead.
## The Four Phases
### 1. OBSERVE — gather current state fast
- Current metrics, logs, alerts, error rates
- What changed recently (deploys, config, traffic)
- Feedback from your last action
- Cast wide, then narrow as a pattern emerges. Time-box it—don't observe forever.
```
Incident: error rate 10x normal; affects API gateway + user service;
started 5 min ago; a deploy went out 15 min ago; users report login failures.
```
### 2. ORIENT — make sense of it (the critical phase)
Match the observations to a pattern and form a hypothesis. This is where most loops go wrong: don't lock onto the first framing. Hold ≥2 candidate explanations and let new evidence shift you.
```
Pattern resembles last month's connection-pool exhaustion, BUT no DB anomaly this time.
The deploy touched auth rate-limiting.
Hypothesis: rate-limit config is too aggressive.
```
### 3. DECIDE — pick an action under uncertainty
- State the action and the hypothesis it tests.
- 70% confidence now beats 90% too late, for a reversible action.
- Decide what you'll observe next to confirm or refute.
```
Decision: roll back the auth deploy.
Hypothesis: this restores normal error rates.
Will watch: error rate for 2 minutes; fallback = investigate DB connections.
```
### 4. ACT — execute, then immediately re-observe
Execute decisively and go straight back to OBSERVE. The action creates new information; don't wait blindly for it to "settle."
| Not actually looping | Stuck in one phase | Time-box each phase |
## Key Questions
- "What do I observe RIGHT NOW?" (not 5 minutes ago)
- "What pattern does this match—and what's my second hypothesis?"
- "What's my best reversible action given current understanding?"
- "How will I know in the next 2 minutes whether it worked?"
- "Am I cycling, or stuck in one phase?"
## Boyd's Insight
"He who can handle the quickest rate of change survives." The goal isn't just making decisions—it's making and revising them faster than the situation compounds. Speed creates options; delay eliminates them.
