tjboudreaux/cc-thinking-skills

thinking-margin-of-safety

When provisioning, setting a limit, or committing an estimate under uncertainty, size a buffer to residual error and the cost of breach—not to the optimistic edge.

First seen Mar 12, 2026

Installation

$ npx skills add tjboudreaux/cc-thinking-skills --skill thinking-margin-of-safety

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from tjboudreaux/cc-thinking-skills · top by installs.

npx skills add tjboudreaux/cc-thinking-skills

Browse all from tjboudreaux/cc-thinking-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 1.3K
License LICENSE
Default branch main
Open issues 2
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,423 B
  • docs SUMMARY.md 195 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 361 installs

SKILL.md

Margin of Safety

Core rule: commit a buffered number when residual uncertainty plus breach cost can cause ruin or costly failure. Margin covers estimation error; it is not free slack for laziness.

When to Use

  • Capacity, timeouts, pool sizes, queue depths, storage, or SLA numbers under load uncertainty
  • Timeline or budget commitments where underestimation is costly
  • Architecture headroom when scaling or recovery is slow
  • Any public or production commitment where being wrong has asymmetric downside

When NOT to Use

  • Breach is detected immediately and fixed near-zero cost (fast auto-scale, live-tunable limit)—static fat buffers waste resources
  • cost(buffer) > P(breach) × cost(breach)—right-size or measure instead of maxing out
  • Uncertainty is eliminable by measurement or lookup—get the real number first
  • Stopping-criterion / search budget problems—use bounded rationality, not padding
  • Fully known parameters and low stakes where edge optimization is the goal

Procedure

  1. Point estimate without padding. State the base requirement in explicit units (RPS, weeks, GB, ms) and confidence (high / medium / low).
  2. Uncertainty and breach cost. List drivers (spike, growth, unknowns, dependency variance). State what fails if undershot: outage, missed launch, data loss, reputation—and whether failure is recoverable or ruinous.
  3. Size the buffer. Multiply or add margin to residual uncertainty and stakes—not to vanity. Typical bands (adjust with evidence):

- Well-known, low consequence: ~1.2–1.5× - Familiar with unknowns / reversible: ~1.5–2× - New domain, external deps, SLA, irreversible: ~2–3× Cap or cut when buffer cost exceeds expected breach cost.

  1. Ruin constraint. If a breach can cause irreversible harm, size so the worst plausible miss still stays above the failure threshold; if that buffer is unaffordable, change the design (shed load, degrade, stage) rather than pretend precision.
  2. Strongest countercase. Challenge both under-buffering ("we will scale later") and over-buffering (idle cost, complexity). Prefer measure-then-trim when history exists.
  3. Commit and monitor. Publish the buffered commitment, the failure threshold, and the metric that would prove margin excessive or thin. Stop when the number is set and monitorable.

Output

Base estimate: … (units, confidence)
Uncertainty drivers: …
Breach cost / failure threshold: …
Margin applied: …× (or absolute buffer …)
Buffered commitment: …
Ruin check: pass | redesign needed
Cost of margin vs expected breach cost: …
Monitor: metric … ; thin if … ; excessive if …

Verification

  • Falsify: If the buffered number equals the optimistic point estimate, no margin was applied—or if margin was added with zero stated breach cost, it is cargo-cult padding.
  • Stop: Once commitment, threshold, and monitor exist, stop stacking multipliers without new uncertainty evidence.
  • Over-application guard: Do not pad when adjustment is free and instant, or when the real number is cheaply measurable. Do not confuse search-stopping with capacity buffers.