← ClaudeAtlas

check-worklisted

Use after a change is made and before claiming the work is done — prove it with evidence (tests, build, typecheck, curl, logs, screenshot, browser). State limitations explicitly when verification is not possible. Phase = Verify.
nuttaruj/rolepod · ★ 3 · AI & Automation · score 76
Install: claude install-skill nuttaruj/rolepod
# Check Work Prove the change behaves as intended with concrete evidence before claiming done. ## Iron Rule <EXTREMELY-IMPORTANT> 1. NEVER claim done without evidence. "Looks right" is not evidence. 2. Verification must be FRESH — run AFTER the last change to the tree. No run since the last edit → you cannot claim it passes; yesterday's green and "should still work" do not count. **Evidence cache:** tree unchanged since a pass recorded THIS session (same `git status` + `git diff` — neither sees untracked / ignored content, so hash or diff any untracked input the check reads) → cite that run's command + output and state "tree unchanged since" instead of re-running; ANY new edit invalidates the cache. 3. UI changes require a browser observation (screenshot, devtools, Playwright). A passing typecheck does not prove the UI works. 4. Cannot verify → STATE what you cannot verify, why, and the risk if you are wrong. 5. NEVER ask the user for a screenshot when you have browser automation available. </EXTREMELY-IMPORTANT> ## Skip when - A no-op (comment, whitespace, docstring) with no behavior risk · the user said "just commit, I'll verify". ## Boundary Owns: fresh evidence that the change works — tests, build, curl, logs, screenshot / browser — and the risk statement when evidence is impossible. Runner emits JUnit/XUnit XML (`pytest --junitxml` / `--reporter=junit` / surefire)? Prefer it: cite counted totals + failed test names via `rolepod-junit <xml>` (installed launcher)