version: "1.0.0" name: quick-verify description: Use while working to confirm a change does what you meant before moving on. Observe its real effect the way a user or caller would, compare that with your intent, fix what is off, and observe again.

Quick verify

Code that compiles, and tests that pass, can still do the wrong thing. The only proof is the real effect, seen from where it matters. Run this loop yourself, between edits, in minutes. It is not a full QA pass; use qa-and-verify for that on a finished pull request.

The loop

1. Say what "working" looks like. One or two sentences, in terms someone could see: "the settings page shows the new toggle, off by default", "export --csv writes a header row". If you cannot say it, you are not ready to check it.
2. Pick the most faithful cheap way to observe it. Look from where the effect lands: the screen a user sees, the response a caller gets, the file or row that gets written, the log a job emits. Prefer the tool the repository already uses. Find how to run things in AGENTS.md, the README, or the package scripts, and never invent a launch command.
3. Produce the state. Run the app, command, or job with realistic input. Reuse what is already running; stop only what you start.
4. Capture evidence. Save it under tmp/verify/<change>/ with ordered names (01-before, 02-after) so each attempt sits next to the last. Capture the states that matter, not only the happy path.
5. Judge it critically. Compare it with step 1, then check around the change for what else it touched. Believe the evidence over your expectation.
6. Fix and observe again the same way, until the evidence shows what you meant.

Examples

Always

• Never commit anything under tmp/verify/, and never point a check at production.
• Report what you checked, how, and what you did not check.