check-worklisted

# Check Work Verify-phase entry skill. 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 run does not count; "should still work" does not count. **Evidence cache:** tree unchanged since a pass recorded THIS session (same `git status` + `git diff` — check, don't assume) → cite that run's command + output and state "tree unchanged since" instead of re-running the suite; ANY new edit invalidates the cache. 3. UI changes require a browser observation (screenshot, MCP devtools, Playwright). A passing typecheck does not prove the UI works. 4. If you cannot verify, STATE explicitly: what you cannot verify, why, and the risk if you are wrong. 5. NEVER ask the user to take a screenshot for you when you have browser automation available. </EXTREMELY-IMPORTANT> ## When to use - A code, config, or content change is complete - A subagent returned COMPLETED — verify before trusting - A bug fix needs regression-clean confirmation - A UI change needs visual / interactive proof - A spec / plan / docs change needs link and reference proof Skip when: - The change is a no-op (comment, whitespace, docstring) with no behavior risk - The user explicitly said "just commit, I'll verify" ## Boundary Owns: - Fresh evi