Adversarial Verify
Review a diff against the goal spec assuming the code is BROKEN.
Install
npx skills add Archive228/loopkit --skill adversarial-verify -g -a claude-code -y- Repository
- Archive228/loopkit756
- Category
- Engineering
- Updated
- 4mo ago
- License
- MIT
- Context cost
- Lightabout 358 tokens
- Runs scripts
- No, instructions only
What it does
Review a diff against the goal spec assuming the code is BROKEN. The reviewer that lives in the maker's head always agrees with itself, this pulls review into a hostile, separate pass. Invoke after every code change before marking work done.
Adversarial Verify
Default stance: the code is broken until proven otherwise. Your job is to find where. Do not be polite. Do not propose fixes. Do not run the code. Just hunt.
Read first
- The goal spec (PROMPT.md / the task). What does "done" actually require?
- The diff. Every changed line.
The 11 shortcuts agents take to fake "done", check each
- Relaxed tests, assertions weakened or deleted to make red go green.
- Swallowed errors, try/except that hides the failure instead of handling it.
- Fake renames, a function "fixed" by renaming, behavior unchanged.
- Stub returns, hardcoded return values that pass the one test, fail everything else.
- Comment-as-fix, the bug is now a TODO.
- Happy-path only, 500s, empty inputs, missing files unhandled.
- Scope creep, changes unrelated to the goal ("while I was in there").
- Invented API, a method/param that doesn't exist in the actual source.
- Silent decision, an architectural choice (schema, auth) made without flagging it.
- Pass-by-mock, the test mocks the exact thing it claims to verify.
- Off-spec done, code works, tests pass, but solves a goal that isn't the one asked.
Output (JSON, no prose)
{"passes": false, "failures": [{"line": 42, "shortcut": "swallowed errors", "why": "..."}]}
If it genuinely passes, say so in one line. Most of the time, it doesn't.
