# Quality

> Reviews code, pull requests, or a defect backlog for escaped-defect risk -- Pillar 2 of The Five Pillars. Use when reviewing a PR or batch of recently merged PRs, after a production defect to find the process gap, or when setting up quality gates for a new team or repo.

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

---


# /quality -- Establish Quality

**Pillar 2 of The Five Pillars.** Reviews code, pull requests, or a defect backlog for escaped-defect risk.

## When to invoke

- Reviewing a PR or a batch of recently merged PRs
- After a production defect, to find the process gap that let it through
- Setting up quality gates for a new team or repo

## What it checks

1. **Defect trend** -- are escaped defects (bugs found in production, not in review/QA) trending up, flat, or down over the last several releases?
2. **Process controls** -- what stands between a developer's keystroke and production: code review, automated tests, static analysis, staging validation? Where are the gaps?
3. **Time to resolve** -- for the last several escaped defects, how long from report to fix? The book's bar is minutes, not hours or days.

## Inputs

Pull real data before reviewing -- don't guess at trend or process controls:

- **PRs** -- `gh pr list --state merged --limit 5 --json number,title,url,reviews` (or the user pastes PR links/diffs directly)
- **Escaped defects** -- the issue tracker's bug list filtered to "found in production" (`gh issue list --label bug`, Jira/Linear query, or a pasted defect log)
- **Process controls** -- read the repo's CI config (`.github/workflows/`, `azure-pipelines.yml`, etc.) and branch protection settings rather than assuming what's enforced
- If none of this is available, say so explicitly in the output instead of estimating numbers

## Example output

> **Quality review -- last 5 merged PRs, repo `atlas-api`**
>
> **Defect trend:** 3 escaped defects in the last 2 releases (up from 1 the release before).
>
> **Process gaps, ranked by defects each would have caught:**
>
> 1. No required review on `hotfix/*` branches -- 2 of 3 escaped defects merged through this path. *(would catch 2/3)*
> 2. No integration test on the payment-webhook handler -- the 3rd defect was a null-check regression there. *(would catch 1/3)*
>
> **Time to resolve:** avg 6 hours (book's bar is minutes) -- no on-call rotation, fixes wait for the one engineer who owns that service.
>
> **Recommended next control:** require review on `hotfix/*` (1-line branch protection change, ships this sprint).

## Reference

See [../../docs/FIVE_PILLARS.md](../../docs/FIVE_PILLARS.md#pillar-2-establish-quality----firefighters-dont-build-they-minimize-destruction).