Don't ask "does the code look right?" — ask what proves it works
A green test suite doesn't prove a frontend change is safe. It proves the tests you thought to write pass. Different changes carry different risk, and risk should determine how much evidence you collect before shipping.
A copy change should not require the same proof as a checkout flow. This kit makes that difference explicit and repeatable.
What's inside
The download is a small toolkit you drop into your repository — not an ebook:
CHANGE-SAFETY.md— the reusable verification checklist. Three risk levels (low, medium, high), each with a defined minimum evidence bar: typecheck, tests, browser verification, state checks, failure paths.AGENTS.md— instructions for coding agents. Any agent working in your repo reads this first, determines the risk level, collects evidence, and reports one of three verdicts:SAFE TO SHIP,NOT SAFE TO SHIP, orINSUFFICIENT EVIDENCE. Includes instructions to run checks incrementally rather than in one long pass.change-safety.example.yml— an example manifest describing a change: summary, risk, affected areas, expected behavior. Copy it per change.frontend-change-safety-checklist.pdf— a 12-page branded field card for humans, printable and quick to scan during review.
The philosophy
Risk determines the minimum amount of evidence required. More evidence can always be requested — but required evidence is never silently reduced because a check is inconvenient.
A copy change needs a typecheck, existing tests, and a quick visual check. A payment change needs all of that, plus end-to-end verification, state assertions, failure paths, and regression coverage. That proportionality is the whole idea.
How to use it
- Drop the files into your repo (root or
docs/). - Adjust the risk-level definitions to your project — they're calibrated defaults, not laws.
- For each change, copy the example manifest, describe the change, classify the risk, collect the evidence, state the verdict.
Takes a couple of minutes to understand and starts paying off on the first risky change. Remember step 0: edit the checklists to fit your project first — they ship as defaults.