How do I install the Verify skill?

Run npx skillmds@latest add sethdford/verify in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Verify safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Verify?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Verify free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Verify?

sethdford (@sethdford) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Verify by sethdford — Agent Skill

Name: Verify
Author: sethdford

Verify

Prove that work actually behaves correctly by spawning the verifier agent to run the code and capture evidence. Use before claiming a task complete, before commit, when in doubt about whether tests prove the right thing. Triggers on /verify, "prove it works", "verify this", "did the change actually work".

sethdford 9ef5c45 2.3 KB Updated Sep 17, 2026

File contents

/verify — Prove behavior, don't infer it

/verify [target] spawns the verifier agent to actually execute the code and capture evidence.

When to invoke

About to mark a task complete
About to commit
After any non-trivial change
When the user asks "does it work?" or "did that fix it?"
After a Stop hook flagged unverified behavior

What you do

Identify the target. If target is given, that's the change/area to verify. Otherwise, infer from recent context: the file you just edited, the task you just claimed done, the bug you just fixed.
Compile the contract. List 3–8 testable behaviors the change is supposed to satisfy. If you can't list them, the work isn't ready to verify — clarify the contract first.
Spawn the verifier. Use the Agent tool with subagent_type: verifier. Pass:
- The target (files, commands, URLs)
- The list of expected behaviors
- Any known test commands (pnpm test, pytest path/to/file.py, curl ...)
- Any constraints (don't hit prod, run only local)
Read the verifier's output. It will end with one of:
- RESULT_verifier=PASS — proceed with whatever you were about to do
- RESULT_verifier=FAIL — STOP. Surface the failed behaviors. Do not claim done.
- RESULT_verifier=INCONCLUSIVE — STOP. Surface the blocker. Verification couldn't complete.
Never override. If the verifier says FAIL or INCONCLUSIVE, you do not say "I think it's fine anyway." You either fix the issue or surface it to the user.

Anti-patterns to refuse

Calling /verify without a clear contract — don't ask the verifier to prove "this works" with no specifics.
Calling /verify and then ignoring the result.
Spawning the verifier and then doing the verification yourself in parallel.

Composition with other skills

After /eval: run /verify on any newly-built skill before promoting it
Before commit-commands:commit: /verify the change first
Inside /team: every agent's task closure runs /verify before TaskUpdate marks it done

---name: verifydescription: Prove that work actually behaves correctly by spawning the verifier agent to run the code and capture evidence. Use before claiming a task complete, before commit, when in doubt about whether tests prove the right thing. Triggers on /verify, "prove it works", "verify this", "did the change actually work".---# /verify — Prove behavior, don't infer it`/verify [target]` spawns the **verifier** agent to actually execute the code and capture evidence.## When to invoke- About to mark a task complete- About to commit- After any non-trivial change- When the user asks "does it work?" or "did that fix it?"- After a Stop hook flagged unverified behavior## What you do1. **Identify the target.** If `target` is given, that's the change/area to verify. Otherwise, infer from recent context: the file you just edited, the task you just claimed done, the bug you just fixed.2. **Compile the contract.** List 3–8 testable behaviors the change is supposed to satisfy. If you can't list them, the work isn't ready to verify — clarify the contract first.3. **Spawn the verifier.** Use the `Agent` tool with `subagent_type: verifier`. Pass: - The target (files, commands, URLs) - The list of expected behaviors - Any known test commands (`pnpm test`, `pytest path/to/file.py`, `curl ...`) - Any constraints (don't hit prod, run only local)4. **Read the verifier's output.** It will end with one of: - `RESULT_verifier=PASS` — proceed with whatever you were about to do - `RESULT_verifier=FAIL` — STOP. Surface the failed behaviors. Do not claim done. - `RESULT_verifier=INCONCLUSIVE` — STOP. Surface the blocker. Verification couldn't complete.5. **Never override.** If the verifier says FAIL or INCONCLUSIVE, you do not say "I think it's fine anyway." You either fix the issue or surface it to the user.## Anti-patterns to refuse- Calling /verify without a clear contract — don't ask the verifier to prove "this works" with no specifics.- Calling /verify and then ignoring the result.- Spawning the verifier and then doing the verification yourself in parallel.## Composition with other skills- After `/eval`: run /verify on any newly-built skill before promoting it- Before `commit-commands:commit`: /verify the change first- Inside `/team`: every agent's task closure runs /verify before TaskUpdate marks it done

Frequently asked questions