work-verification

Runs fresh verification commands and cites their output before stating completion claims.

3|3|Updated Apr 6, 2026
One-click install
npx skills add https://github.com/philipobenito/elelem --skill work-verification-philipobenito
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: work-verification
Source: https://github.com/philipobenito/elelem/tree/main/skills/work-verification
Command: npx skills add https://github.com/philipobenito/elelem --skill work-verification-philipobenito

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents unverified completion claims by enforcing a gate between making a change and claiming it works, eliminating hedged statements like "should pass" that lack fresh evidence. ## Core Features & Use Cases - Five-Step Gate Function: Identify the proving command, run it fresh, read the output, compare it to the claim, and state the claim only with cited evidence. - Worked Verification Patterns: Covers tests, builds, bug-fix regression cycles (revert-and-restore), subagent handback diff inspection, and requirements checklist validation. - Rationalisation and Red-Flag Guards: Lists common excuses and stop conditions that force verification before commits, PRs, or success statements. - Use Case: After fixing a bug, run the reproducing test, revert the fix to confirm it fails, restore the fix to confirm it passes, then state the claim with the command output cited. ## Quick Start Ask the assistant to verify the latest change by running the relevant test or build command fresh and stating the result with the cited output.

Frequently Asked Questions about work-verification

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a code change before claiming it works?

Name the exact command that proves the claim, run it fresh after your latest change, read the exit code and failure lines, then state the claim with that output cited. Reusing earlier output or partial runs does not count as verification.

How to verify a bug fix with a regression test?

Run the reproducing test against the fix and confirm it passes, then revert the fix and confirm the test fails with the original symptom, then restore the fix and confirm it passes again. A test observed passing only once is not verified.

Can I trust a subagent's success report without checking?

No. Inspect the VCS diff yourself with git status and git diff, then re-run the task's verification commands against the current working tree. Only state the subagent task is complete after the diff matches the spec and verifications pass.

Is a passing linter enough to claim the build works?

No. The linter is not the compiler and not the test suite. Claiming a build succeeds requires running the actual build command fresh and reading its exit code and output in the current message.

When should verification be re-run during a session?

Re-run verification after every change to the code it covers, and always before committing, pushing, or opening a PR. Output from earlier in the session is stale and does not prove the current state.