Everyday Programmer
Work with Jimmy

Frontend Change Safety Kit

A lightweight verification checklist for developers — and the coding agents working with them. Decide what evidence a frontend change needs before you call it safe to ship.

Download

Frontend Change Safety Kit

ZIP / PDF / Markdown / YAML · No email required · Free forever

Includes

Printable checklist (PDF)
Repo-ready Markdown
Agent instructions
Example change manifest
Download Kit (.zip)

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, or INSUFFICIENT 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

  1. Drop the files into your repo (root or docs/).
  2. Adjust the risk-level definitions to your project — they're calibrated defaults, not laws.
  3. 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.