# Verify Changes

> Post-change QA gate. After code has been changed — especially by a separate agent/fresh session — verify it type-checks and its tests pass (baseline- and matrix-aware), and that tests were actually added or modified to cover the new/changed behavior. Use before declaring a change done, or when reviewing another session's implementation.

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

---


# Verify changes

Run after any code change — most importantly one implemented by a separate session/agent — before
calling it done. Two questions: **did the change land cleanly**, and **is it actually tested**.
Report findings; never silently fix — the user decides.

## 1. Scope the change

Establish exactly what changed before judging it: `git status --short` + `git diff` for the working
tree, and — if the work was already committed — `git log --oneline` back to the session's base plus
`git show --stat <sha>`. List every changed/added **source** file and every changed/added **test**
file. A source change with no matching test change is the first thing to flag.

## 2. Type-check — baseline-aware

Run the repo's real type-checker (e.g. `npx tsc --noEmit`, `mypy`, `go vet` — whatever the project
uses). Many repos carry a **pre-existing error baseline** — do NOT report the baseline. Isolate
errors in the *changed* files only. If unsure whether an error is new, `git stash` the change,
re-run, and diff. The bar is **zero new errors in changed files**. Line-number shifts push errors
around in unchanged files without adding any — strip line numbers before diffing if the raw count
moved.

## 3. Tests — run the real suite

Find the test command in the project's manifest (`package.json`, `Makefile`, `pyproject.toml`,
etc.) — don't assume `npm test`. Honor any **multi-environment matrix** the project defines: if the
suite is meant to run under more than one configuration (multiple timezones, locales, runtimes, or
DB backends), every configured run must pass — a single run proves nothing. If there is a separate
locally runnable integration/DB-coupled suite for the area you changed, run it too.

## 4. Were tests added/modified *correctly*?

Passing is necessary, not sufficient — judge adequacy:

- **Coverage of the change:** every new/changed function or branch has a test that exercises *it*,
  not just adjacent code. New pure helpers especially.
- **Would it fail without the change?** If an assertion would still pass against the old code, it
  doesn't guard the change. Pin the new behavior precisely — exact values, not "truthy".
- **Edge/throw paths:** error cases, boundaries, empty inputs, and every documented invariant
  (a sentinel carried verbatim, an amount capped, a body that must serialize byte-identically) have
  explicit assertions.
- **Behavior-preserving refactors:** where the change claims "byte-identical" / "no behavior
  change", confirm a test or a direct diff actually proves it — don't take the claim on faith.
- **Right layer:** logic is tested at the pure/testable seam, not through a mock-heavy integration
  path that tests the mocks.

## 5. Report

Summarize: files changed, type-check result (new errors: expected 0), the test result (all
configured runs), and a per-change verdict on test adequacy with **specific** gaps named.
Everything missing is a finding for the user to decide on — do not fix it silently.