How do I install the Verify And Finish skill?

Run npx skillmds@latest add lawzava/verify-and-finish 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 And Finish 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 And Finish?

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 And Finish free to use?

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

Who published Verify And Finish?

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

Verify And Finish by lawzava — Agent Skill

Name: Verify And Finish
Author: lawzava

Verify And Finish

Use to verify a completed outcome before claiming success, handing off, committing, merging, publishing, deploying, or closing a task. Do not use for an intermediate update, an isolated test run, or merely naming an oracle command.

lawzava Updated Sep 17, 2026

File contents

Verify and Finish

Start with the cheapest fresh state or oracle that can establish whether the requested outcome already holds. If it shows no change or effect remains and no review or manual gate is pending, report a verified no-op and stop before broad checks. An external no-op needs an external readback; local proof cannot establish an external state or effect.

Evidence precedes every load-bearing claim. Run each acceptance oracle fresh against the current artifact, read the whole result, and state only what it proves. A focused test does not prove the full suite; artifact inspection does not prove runtime behavior.

Check the original command's exit status and the raw evidence supporting each claim. A filtered summary alone cannot establish success or rule out hidden failures. Missing or truncated evidence needed for a claim leaves it unverified until recovered.

Label artifact inspection and inference instead of presenting either as an executed check. Bind stale-prone results to the artifact identity and commit. Separate declared configuration from effective runtime behavior.

Separate local verification from external proof. A local build cannot prove a deployment, published package, API effect, or user-visible result. When the criterion requires an external oracle, exercise the real boundary and record the environment and correlation identity. If a required tool or environment is unavailable, report the criterion as unverified rather than substituting a nearby check.

For a user-facing product, run the real journey. If an agreed substitute is necessary, name what it cannot prove.

Reconcile each affected repository-owned specification with verified behavior. Resolve every requirement to fresh evidence or a remaining gap; a plan is not implementation evidence.

Account for every requested review, including queued and running requests. Join them and resolve credible findings. One approval does not cancel another pending review. Bind checks and gates to the current artifact, and reassess after changes. A pending review remains open work.

Before a handoff, commit, PR, merge, or release, run canonical checks and inspect the diff and workspace. Remove generated excess. Confirm a named target branch before committing. Do not commit, publish, merge, delete a branch, or remove a worktree without authority for that destination. Destructive cleanup requires target confirmation and ownership evidence.

Open the report with VERIFIED: <claim> only when every required criterion has fresh oracle evidence. Otherwise use NOT VERIFIED. Remaining: <gap>.

---name: verify-and-finishdescription: Use to verify a completed outcome before claiming success, handing off, committing, merging, publishing, deploying, or closing a task. Do not use for an intermediate update, an isolated test run, or merely naming an oracle command.---# Verify and FinishStart with the cheapest fresh state or oracle that can establish whether therequested outcome already holds. If it shows no change or effect remains and noreview or manual gate is pending, report a verified no-op and stop before broadchecks. An external no-op needs an external readback; local proof cannotestablish an external state or effect.Evidence precedes every load-bearing claim. Run each acceptance oracle freshagainst the current artifact, read the whole result, and state only what itproves. A focused test does not prove the full suite; artifact inspection doesnot prove runtime behavior.Check the original command's exit status and the raw evidence supporting eachclaim. A filtered summary alone cannot establish success or rule out hiddenfailures. Missing or truncated evidence needed for a claim leaves it unverifieduntil recovered.Label artifact inspection and inference instead of presenting either as anexecuted check. Bind stale-prone results to the artifact identity and commit.Separate declared configuration from effective runtime behavior.Separate local verification from external proof. A local build cannot prove adeployment, published package, API effect, or user-visible result. When thecriterion requires an external oracle, exercise the real boundary and recordthe environment and correlation identity. If a required tool or environment isunavailable, report the criterion as unverified rather than substituting anearby check.For a user-facing product, run the real journey. If an agreed substitute isnecessary, name what it cannot prove.Reconcile each affected repository-owned specification with verified behavior.Resolve every requirement to fresh evidence or a remaining gap; a plan is notimplementation evidence.Account for every requested review, including queued and running requests.Join them and resolve credible findings. One approval does not cancel anotherpending review. Bind checks and gates to the current artifact, and reassessafter changes. A pending review remains open work.Before a handoff, commit, PR, merge, or release, run canonical checks and inspectthe diff and workspace. Remove generated excess. Confirm a named target branchbefore committing. Do not commit, publish, merge, delete a branch, or remove aworktree without authority for that destination. Destructive cleanup requirestarget confirmation and ownership evidence.Open the report with `VERIFIED: <claim>` only when every required criterion hasfresh oracle evidence. Otherwise use `NOT VERIFIED. Remaining: <gap>`.

Frequently asked questions