| name | verify-discipline |
| description | Run tests without burning the clock or the context window: narrow checks while you iterate, the full suite once at the end. Use when running tests, verifying a change, choosing a test command, or when a suite is being re-run repeatedly. |
Verify discipline
Shell verification consumed 284.5 of 341 measured minutes over four days on this system. Of 693
runs, 566 came from subagents. The full suite averaged 51.3 seconds across 217 runs, while
file-scoped tests averaged 21.5 seconds across 197. Forty-eight transcripts ran a suite at least
five times and accounted for 520 of 706 runs.
The waste is in repeating a broad gate after every edit. Testing is fine. Testing everything after
every keystroke is where the four days went.
Narrow while you work, full gate at the end
- Find the project's real commands first: read
package.json scripts, the Makefile, or whatever
the project actually documents. Do not guess flags or carry a command over from another project.
- Identify the test file or consumer closest to the behavior you just changed. Use the project's
file-aware test command with that exact file.
- Run that scoped check after each related edit. When it fails, fix the focused failure and rerun
only the focused check.
- Once the scoped checks pass, run the full suite once, at the end, before you call the work
done or hand it off.
If the project has no reliable file-scoped form, use the smallest documented check that covers what
you changed, and keep the full command as the final gate.
Do not use a full suite as an edit loop. Run an extra broad check only when you have touched a new
surface, or when a focused failure points at something outside the code you changed.
Never stream a passing suite into the transcript
A passing suite's output carries no information. The exit code and the summary counts are the whole
signal, and the rest is thousands of tokens of ok 1 ... ok 400 nobody will read.
Redirect the run to a log and print only the status and the failures:
log="$(mktemp "${TMPDIR:-/tmp}/verify.XXXXXX.log")"
(<the full test command>) > "$log" 2>&1
status=$?
printf 'exit=%s\n' "$status"
grep -nE '^not ok|^# (fail|pass)' "$log" | head -40
printf 'details=%s\n' "$log"
exit "$status"
The wrapper preserves the command's exit code, so filtering the output never weakens the gate. On a
failure, use the line numbers grep -n printed to read only those ranges of the log. Do not dump
the whole thing.
This matters most for subagents
566 of the 693 measured runs came from subagents, and a subagent's suite output lands in a context
you are paying for and cannot see. When you brief an agent, give it one exact scoped command and one
exact full command, with the wrapper above already filled in. An agent that has to invent its test
command invents a broad one.
Guidelines
- The narrowest reliable check wins while you iterate. Reliable is the load-bearing word: a
check that passes while the code is broken is worse than a slow one.
- Full suite once, at the seam, when the work is done or several pieces are being merged.
- Exit code is the verdict. Read the log on failure only.
- Hand agents their commands. Both of them, exact, copy-pasteable.
