/community/skills/aewing skills/verification hygiene
innernet
docsskillscommunitycompanydeveloperssecurityprivacytermscontact

a skill by aewing, brought here by SD

verification hygiene

paste this link into your ai. it will know what to do.

/skills/aewing-verification-hygiene

Verify code, package, test, deletion, and delivery claims against the real artifact. Use after changes or before saying work is done. Select the narrowest proof that can falsify the claim, then cover every layer the requested outcome depends on.

kindskill
last tended2026-09-19
written byaewing
sourcegithub.com/aewing/skills
kept currentwith its source · last read 2026-11-03
in the folderaewing skills · 10 of 11 · ‹ tui design · wat ›
brought here bySD
reuseMIT
yours?it stays under your name. to change it or take it down, write to connect@innernet.live
reading2 min

Verification hygiene

Use the owning repository's check, test, build, dependency, and boundary gates; do not copy command catalogs into this skill.

When NOT to use this

  • Design or exploration with no claim on the line yet — there is nothing to

falsify.

  • When a narrower, already-passing owner gate directly covers the claim; this

skill is for choosing and proving the narrowest check, not ritual re-running.

Procedure

  1. 1Write the exact claim being verified.
  2. 2Choose the narrowest command or observation that can prove it false.
  3. 3Run it in the owning repository and record the exit code and useful output.
  4. 4Exercise the shipping surface when the claim reaches CLI, TUI, browser, worker, storage, auth, secrets, or deployment behavior.
  5. 5Run broader owner gates required by the changed dependency or boundary.
  6. 6Inspect the diff for hidden bypasses, then report only the tier proved.

Required consequences

  • Source change: run the owning package check and focused behavioral tests.
  • Dependency change: run that repository's dependency and cycle gates.
  • Boundary or export change: run its boundary or architecture gate and build or

pack the public artifact.

  • Delete or rename: grep every consumer before removal.
  • CLI/TUI/web change: invoke the real entrypoint; types alone are insufficient.
  • Storage or cloud API change: exercise the owner and at least one borrower path.
  • Workspace or tooling change: run the workspace's canonical check before handoff.

Reject false green

Reopen the work if the change introduces a skipped test, type suppression, silent catch, fixture that mocks the subject, hard-coded passing result, or a comment that defers the requested implementation. Do not delete a failing test; repair the product or rewrite the test against the current contract.

A unit test proves only its execution path. A 200 proves only the request it made. A deploy proves only provider acceptance. Match the evidence to the claim.

Report

Keep the evidence copyable and short:

Claim: <what is now true>
Proof: <command or observation> — exit <n>
Artifact: <real surface exercised>
Unknown: <remaining unproved part, or none>

keep it where your ai can reach it.

innernet is memory your ai tools read live — every skill, every project, every decision, in one place, connected once. save this skill to yours, or publish one of your own as a link like this.

save it to your innernetsee every skill