# Stability

> Audits production readiness and incident-response process -- Pillar 3 of The Five Pillars. Use before a major release or migration, after a production incident as part of the retrospective, or when evaluating whether a team is ready to increase deployment frequency.

- Skill: `clearmeasurelabs/stability` (Agent Skill)
- Install (CLI): `npx skillmds@latest add clearmeasurelabs/stability`
- Raw SKILL.md: https://api.skillmd.com/api/skills/clearmeasurelabs/stability/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ClearMeasureLabs (https://skillmd.com/u/clearmeasurelabs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/clearmeasurelabs/stability

---


# /stability -- Achieve Stability

**Pillar 3 of The Five Pillars.** Audits production readiness and incident-response process.

## When to invoke

- Before a major release or migration
- After a production incident, as part of the retrospective
- Evaluating whether a team is ready to increase deployment frequency

## What it checks

1. **Breaking point** -- does the team know its system's actual capacity limits (load, data volume, dependency limits), or is this unknown until an incident finds it?
2. **Incident history** -- frequency, severity, and whether each incident got a complete, executive-visible investigation (not just a quiet fix)
3. **Recovery process** -- how fast can the team detect and recover from an incident today? Is there a runbook, or is recovery ad hoc?
4. **Deploy-while-stable track record** -- can the team ship new releases without a corresponding spike in incidents?

## Inputs

- **Incident history** -- an incident tracker export (PagerDuty, Statuspage, Opsgenie), a pasted incident log/postmortem doc, or the repo's `incidents/`/`postmortems/` folder if one exists
- **Breaking point** -- load test results, monitoring dashboards (APM, CloudWatch, etc.), or -- if none exist -- the honest answer "unknown, never tested" is itself the finding
- **Recovery process** -- a runbook doc if one exists; otherwise ask how the last incident was actually resolved and treat the answer as the current (informal) process
- Never fabricate incident counts or MTTR numbers to fill a gap in the data -- report "no incident tracking in place" instead

## Example output

> **Stability audit -- Atlas API**
>
> **Breaking point:** Unknown -- no load testing on record. Team estimates ~500 req/s based on a prod incident 3 months ago, not a deliberate test.
>
> **Incident history:** 4 incidents in 90 days, all Sev-2. Only 1 got a written postmortem; the other 3 were fixed and closed with no review.
>
> **Recovery process:** No runbook. Last incident (DB connection pool exhaustion) was resolved by the one engineer who remembered a similar issue from a prior job.
>
> **Highest-risk gap:** No postmortem discipline -- 3 of 4 incidents could recur with no institutional memory of the fix.
>
> **Recommended next step:** Require a written postmortem (even a 1-paragraph one) for every Sev-2+ incident starting next week; write a runbook for the connection-pool issue specifically, since it's already recurred once.

## Reference

See [../../docs/FIVE_PILLARS.md](../../docs/FIVE_PILLARS.md#pillar-3-achieve-stability----the-last-mile-to-roi).