define-done skill's real value: stopping unstated assumptions

The measurement effort started because define-done originally described its acceptance criteria in prose—things like "sending /items 61 times makes the 61st return 429." Prose is readable by humans but cannot be machine-judged, so the author rewrote the skill to emit tests runnable with node --test. That shift made it possible to compare runs with and without the skill using graders and mutation testing, where small bugs are injected automatically to see if tests catch them.

Across the cases, the surprise was where the skill made a difference. When requirements were unambiguous, both conditions detected every variant. The divergence appeared on real bugs pulled from the author's issue tracker—like an ADMIN being able to invite an OWNER—where runs without the skill wrote tests that silently encoded assumptions the spec never made. That is why the author added a second correctness check: a test had to pass against an alternative correct implementation that differed only on unspecified details.

The same counting discipline led to removing two skills. Once acceptance tests were sealed in a git commit and a script could verify the seal, the remaining work of implement-plan and verify-plan reduced to command outcomes rather than LLM judgment, so those skills were folded into an exit code. The author notes that most errors found during this process were in the measuring instruments—graders and fixtures—rather than in the skill itself, and now treats a falling number as a reason to suspect the measurement first.