← ClaudeAtlas

vkm-verifylisted

Prove a green check actually ran, covered the change, and can fail. Use before claiming done / tests pass / CI green / committed / deployed, when a guard or lint has never once fired, or when a pass contradicts a symptom the user still sees. NOT for writing tests or debugging a known-red failure.
Vahlame/create-vkm-kit · ★ 4 · AI & Automation · score 61
Install: claude install-skill Vahlame/create-vkm-kit
# vkm-verify — the green that proves nothing Installed by create-vkm-kit (vkm-kit). One job: **turn "it passed" into "it passed, and it would have failed."** A check reports two different things with the same green: _your code is correct_, and _nothing was examined_. The second is the expensive one, because it looks exactly like the first and it removes the very alarm you were relying on. Every entry below is a real incident, not a category invented for symmetry: - a lint that walks the tree for an antipattern goes **green forever** the day its regex stops matching — zero matches is a pass; - a CI job that is **skipped** counts as success, so a release published without ever touching npm reported all-green (twice); - `gh pr checks` exited **0 with zero jobs**; - a matrix's `fail-fast` cancelled two legs mid-suite, which then reported "fail" for tests that never ran — the mirror image, and just as wrong; - a validator printed **nothing and exited 0** on Windows: indistinguishable from a pass for anyone reading the exit code; - 415 unit tests passed while the installer they cover wired every MCP server the wrong way, because **no test ran the installer**; - a substitution script "fixed" 8 files and matched **nothing**, because the patterns had accents and the files did not; - a file was created, verified locally, and "committed" — `.gitignore` swallowed it in silence and the commit message claimed it was there. ## The four questions Ask them in order. The fir