skills/thinking-reversibility/SKILL.md
Before deliberating over a decision, ask if it's a one-way door (costly to undo) or two-way (cheap to undo) — decide two-way doors fast, and look for moves that make one-way doors reversible.
npx skillsauth add tjboudreaux/cc-thinking-skills thinking-reversibilityInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Jeff Bezos distinguishes between Type 1 (irreversible, one-way door) and Type 2 (reversible, two-way door) decisions. The key insight: most decisions are Type 2 but get treated as Type 1, causing analysis paralysis. Match your decision process to the reversibility of the decision.
Core Principle: Reversible decisions should be made quickly by individuals. Irreversible decisions deserve deliberation. Most decisions are more reversible than they appear.
Decision flow:
Decision to make?
→ Is it easily reversible? → yes → DECIDE QUICKLY (Type 2)
→ Is it hard/impossible to reverse? → yes → DELIBERATE CAREFULLY (Type 1)
→ Unsure of reversibility? → ANALYZE REVERSIBILITY FIRST
Before deliberating over a decision:
If the decision is forced by an external constraint with no optionality, reversibility doesn't change the available move. If an irreversible action is genuinely required and the upside justifies it, name it and proceed.
Characteristics:
Examples:
Process:
Characteristics:
Examples:
Process:
| Factor | Question | Impact on Reversibility | |--------|----------|------------------------| | Technical cost | How hard to undo technically? | High cost = less reversible | | Time cost | How long to reverse? | Months = less reversible | | Financial cost | How expensive to change? | High cost = less reversible | | Reputation cost | Will reversal damage trust? | Yes = less reversible | | Learning cost | Will we lose the learning? | Critical learning = more complex | | Dependency cost | Have others built on this? | Many dependents = less reversible |
Reversibility Score:
- Can undo in days with minimal cost: TYPE 2 (two-way door)
- Can undo in weeks with moderate cost: TYPE 2 with monitoring
- Can undo in months with significant cost: TYPE 1.5 (evaluate carefully)
- Cannot realistically undo: TYPE 1 (one-way door)
| Decision Type | Process | Effort | Who decides | |---------------|---------|--------|-------------| | Type 1 | Full analysis, argue the alternative, document | High | Surface to human owner before committing | | Type 1.5 | Structured analysis, document rationale | Moderate | Flag to owner if stakes are high | | Type 2+ | Quick analysis, note rationale | Low | Decide and proceed | | Type 2 | Just decide | Minimal | Decide and proceed |
Decision: Which logging library to use
Common mistake: Extensive evaluation, committee decision, weeks of analysis
Reality: Can swap libraries in a day; dependencies are isolated
Correct approach: Engineer picks one, team evaluates after 2 weeks
Cost of over-deliberation: Weeks of productivity lost
Decision: Database technology for core product
Common mistake: Quick decision because "we can always change later"
Reality: Changing databases means rewriting queries, data migration, retraining
Correct approach: Thorough evaluation, prototype, stakeholder alignment
Cost of under-deliberation: Months of migration pain later
Some seemingly irreversible decisions are actually reversible:
"We can't change our API because clients depend on it"
Reality: Versioning makes this reversible
v1 continues, v2 adds improvements
"We can't change the architecture"
Reality: Strangler pattern enables gradual change
Migrate piece by piece
Some seemingly reversible decisions lock you in:
"It's just a prototype, we can rewrite later"
Reality: Prototypes often become production
"Temporary" code lives for years
"We can always switch cloud providers"
Reality: Deep integration creates massive switching cost
Proprietary services create lock-in
Turn Type 1 into Type 2 through limited rollout:
Type 1: "Adopt new framework for entire codebase"
Piloted: "Use new framework for one service"
→ Now it's Type 2: Can abandon pilot with limited impact
→ If successful, expand incrementally
Create reversibility through interfaces:
Type 1: "Choose between Postgres and MySQL"
With abstraction: "Define data layer interface, start with Postgres"
→ Can swap implementation later
→ Cost of reversal dramatically reduced
Make long commitments into short experiments:
Type 1: "Commit to vendor for 3 years"
Time-boxed: "Start with 6-month pilot"
→ Can exit at known cost
→ Full commitment only after validation
Deploy with reversibility built in:
Type 1: "Launch new pricing model"
With flags: "Launch to 5% of users, flag-controlled"
→ Can disable instantly
→ Expand only when confident
# Reversibility Analysis: [Decision]
## The Decision
[What we're deciding]
## Reversibility Assessment
| Factor | Assessment | Score (1-5) |
|--------|------------|-------------|
| Technical effort to reverse | [Details] | |
| Time to reverse | [Duration] | |
| Financial cost to reverse | [Cost] | |
| Reputation impact of reversal | [Impact] | |
| Dependencies affected | [Count/scope] | |
| Learning lost if reversed | [Value] | |
Average: [X]
- 1-2: Clear Type 2
- 3: Type 1.5
- 4-5: Type 1
## Decision Type: [Type 1 / 1.5 / 2]
## Appropriate Process
- Analysis depth: [Minimal / Moderate / Extensive]
- Surface to human owner before committing? [No / Yes if high-stakes / Yes]
- Documentation: [None / Brief / Full]
## Can We Increase Reversibility?
- Pilot: [Option]
- Abstraction: [Option]
- Time-box: [Option]
- Feature flag: [Option]
## Decision
[The choice made]
## Reversal Plan (if needed)
[How we would reverse if this proves wrong]
"Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation."
"But most decisions aren't like that – they are changeable, reversible – they're two-way doors. If you've made a suboptimal Type 2 decision, you don't have to live with the consequences for that long. You can reopen the door and go back through."
"As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention."
Speed matters. Most decisions are reversible. Decide, learn, adjust.
tools
About to add a feature/layer/process to fix a problem. First ask what to remove instead — subtraction is often more robust than addition. Use for simplification and complexity reduction.
development
Use when stuck between two architecture or API requirements that seem mutually exclusive — name the contradiction precisely, then separate the conflicting states in time, space, or condition.
testing
You need to trace how a system would fail or behave at a scale you can't cheaply test or measure. Use to imagine the scenario and walk the consequence chain step by step.
devops
Use when optimizing latency or throughput in a pipeline and one stage dominates—focus all effort on that single bottleneck, since speeding up the others changes nothing until it's fixed.