How do I install the Verify Before Done skill?

Run npx skillmds@latest add adamradek-ux/verify-before-done 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 Before Done 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 Before Done?

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 Before Done free to use?

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

Who published Verify Before Done?

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

Verify Before Done by adamradek-ux — Agent Skill

Name: Verify Before Done
Author: adamradek-ux

Verify Before Done

Completion-check gate to run BEFORE declaring a task done. Walks through success criteria, factual claims (numbers/URLs/features/processes), writing conventions (propose-then-write, frontmatter, naming, no leftover placeholders) and scope creep; explicitly admits what failed or was skipped. Use at the end of every multi-step task, especially before writing into a notes vault. Run BEFORE saying done; recording findings into persistent memory is session-capture's job (runs after completion). Triggers: "done?", "verify before done", "completion check", "before-done", and Czech aliases "hotovo?", "ověř než dokončíš".

adamradek-ux Updated Sep 17, 2026

File contents

Before you say "done", run this checklist. It is not a formality — it is a gate. If anything fails, fix it or report it; never declare the task complete with silent debt.

Checklist

Success criteria — for a multi-step task, did you formulate verifiable criteria at the start (goal-driven execution)? Did you meet every one? Walk through them one by one, not wholesale.
Factual claims — is every number, URL, feature name and process in your output verified against a source (project docs / knowledge base / the live web)? Whatever you did not verify, mark as unverified — do not present it as fact. No invented URLs, functions, or processes.
Notes/vault writes (if you wrote into the user's notes or vault):
- Did the write go through propose → OK → write? (Nothing is written into the vault without an explicit instruction.) This is a human gate — it cannot be delegated.
- Delegate deterministic checks to tooling instead of eyeballing them. If this pack's frontmatter hook (hooks/hook-frontmatter-check.sh) or your own linter is wired up, check its warnings for the touched files: required frontmatter keys (tags/status/created or your project's equivalent), kebab-case file names, and unfilled {{...}} placeholders.
- Anything the linter or hook reports → fix it before saying done.
Scope — did you touch only what the task asked for? No "while I was at it I also improved" neighboring files without instruction.
What did NOT work — what did you skip, what failed, what is only partial? Say it plainly in the conclusion. A test failed → include the output. You skipped a step → admit it. No hedging, no "should work" without verification.

Output

Short summary: what passed, what passed with caveats, what was not met. If anything failed, the task is not finished — go back and complete it, or explicitly escalate to the user with the reason.

Notes

Placeholder syntax ({{...}}) shown inside code fences or inline code is documentation, not a violation — only unfilled placeholders in finished prose count.
Respect your project's declared exceptions (template folders, bulk imports, special files like CLAUDE.md/README.md) instead of flagging them as violations.

---name: verify-before-donedescription: Completion-check gate to run BEFORE declaring a task done. Walks through success criteria, factual claims (numbers/URLs/features/processes), writing conventions (propose-then-write, frontmatter, naming, no leftover placeholders) and scope creep; explicitly admits what failed or was skipped. Use at the end of every multi-step task, especially before writing into a notes vault. Run BEFORE saying done; recording findings into persistent memory is session-capture's job (runs after completion). Triggers: "done?", "verify before done", "completion check", "before-done", and Czech aliases "hotovo?", "ověř než dokončíš".---Before you say "done", run this checklist. It is not a formality — it is a gate. Ifanything fails, **fix it or report it**; never declare the task complete with silent debt.## Checklist1. **Success criteria** — for a multi-step task, did you formulate verifiable criteria at the start (goal-driven execution)? Did you meet **every one**? Walk through them one by one, not wholesale.2. **Factual claims** — is every number, URL, feature name and process in your output verified against a source (project docs / knowledge base / the live web)? Whatever you did not verify, mark as unverified — do not present it as fact. No invented URLs, functions, or processes.3. **Notes/vault writes** (if you wrote into the user's notes or vault): - Did the write go through `propose → OK → write`? (Nothing is written into the vault without an explicit instruction.) *This is a human gate — it cannot be delegated.* - **Delegate deterministic checks to tooling instead of eyeballing them.** If this pack's frontmatter hook (`hooks/hook-frontmatter-check.sh`) or your own linter is wired up, check its warnings for the touched files: required frontmatter keys (`tags`/`status`/`created` or your project's equivalent), kebab-case file names, and unfilled `{{...}}` placeholders. - Anything the linter or hook reports → fix it before saying done.4. **Scope** — did you touch only what the task asked for? No "while I was at it I also improved" neighboring files without instruction.5. **What did NOT work** — what did you skip, what failed, what is only partial? Say it plainly in the conclusion. A test failed → include the output. You skipped a step → admit it. No hedging, no "should work" without verification.## OutputShort summary: what passed, what passed with caveats, what was not met. If anythingfailed, the task is **not finished** — go back and complete it, or explicitly escalateto the user with the reason.## Notes- Placeholder syntax (`{{...}}`) shown inside code fences or inline code is documentation, not a violation — only unfilled placeholders in finished prose count.- Respect your project's declared exceptions (template folders, bulk imports, special files like `CLAUDE.md`/`README.md`) instead of flagging them as violations.

Frequently asked questions