Agent skill

Verify Before Done

by WrongStack in WrongStack/WrongStack

Use this skill before telling the user a code change is finished, fixed, or working — to prove it with the project's own checks and report exactly what was and wasn't verified.

MITAuto-check passed

Install Verify Before Done

skills CLI
$ npx skills add WrongStack/WrongStack --skill verify-before-done -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install WrongStack/WrongStack verify-before-done --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/WrongStack/WrongStack.git skills-src && mkdir -p .claude/skills && cp -r skills-src/packages/core/skills/verify-before-done .claude/skills/verify-before-done && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
verify-before-done
GitHub stars
370
Token cost
~1.6k tokens
SKILL.md length
780 words
Files
2
Skills in repo
38
Repo updated
First seen
Licence
MIT

At a glance

Use this skill before telling the user a code change is finished, fixed, or working — to prove it with the project's own checks and report exactly what was and wasn't verified.

  • Works in 8 steps: Re-read the request and check the change… → Review your own diff before reporting —… → Run the checks that apply, cheapest… → …
  • SKILL.md covers Overview, Rules, Record the starting state and Workflow, plus 5 more sections
  • Calls git

What it does

Verify Before Done is an agent skill from WrongStack/WrongStack. Use this skill before telling the user a code change is finished, fixed, or working — to prove it with the project's own checks and report exactly what was and wasn't verified. Triggers: finishing an implementation or fix, writing the final summary of code changes, "done", "is it working", "did you test it", "make sure it works", "verify", "ready to merge".

Its SKILL.md is about 1.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file (for example `SKILL.save.md`).

The repository describes itself as: An AI coding agent that reads your code, edits files, runs commands, and reasons through bugs — across a terminal REPL, a full-screen TUI, and a browser UI, while you keep your… The licence is MIT.

Example prompts

  • “s own checks and report exactly what was and wasn”
  • “is it working”
  • “did you test it”
  • “/verify-before-done”

Workflow steps

8 steps, taken from the first numbered list in SKILL.md.

  1. Re-read the request and check the change against every part of it, including
  2. Review your own diff before reporting — unintended edits, leftover debug
  3. Run the checks that apply, cheapest first: format and lint, type check,
  4. Exercise the behaviour itself when no test covers it: run the command, call
  5. Read results instead of trusting exit codes. Zero tests run, skipped suites,
  6. Fix failures you caused. Show pre-existing failures are pre-existing (they
  7. Report faithfully: what ran and its outcome, what couldn't be verified and
  8. Lead with an honest outcome. A change whose related checks failed, timed

What it can do on your machine

Read from SKILL.md and the folder at commit 57f6018. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Verify Before Done loads about 1.6k tokens when it runs. Until then it costs about 95 tokens; SKILL.md has 780 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~95
When it runs · the whole SKILL.md, loaded when a task matches
~1.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from WrongStack/WrongStack at commit 57f6018, republished under its MIT licence (© WrongStack). 780 words, ~1,579 tokens.

Download SKILL.mdSave it as .claude/skills/verify-before-done/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
verify-before-done
description
Use this skill before telling the user a code change is finished, fixed, or working — to prove it with the project's own checks and report exactly what was and wasn't verified. Triggers: finishing an implementation or fix, writing the final summary of code changes, "done", "is it working", "did you test it", "make sure it works", "verify", "ready to merge".
version
1.1.0
required-capabilities
filesystem.read
optional-capabilities
verification.run, execution.shell, version-control.manage, code.inspect

Verify Before Done

Overview

"Done" is a claim the user acts on: they merge, deploy, or stop looking. This skill makes the claim evidence-based — the change does what was asked, nothing adjacent broke, and the report says precisely what was checked. It costs minutes; a false "done" costs the user's trust and often an incident.

Rules

  1. Re-read the request and check the change against every part of it, including the easy-to-forget parts: docs, config, migrations, other platforms.
  2. Review your own diff before reporting — unintended edits, leftover debug code, commented-out code, new TODOs, secrets, files from unrelated work.
  3. Run the checks that apply, cheapest first: format and lint, type check, targeted tests, the suites for touched packages, build. Use the project's own commands from package scripts, Makefile, or CI config.
  4. Exercise the behaviour itself when no test covers it: run the command, call the endpoint, open the page. A passing unrelated suite is not evidence.
  5. Read results instead of trusting exit codes. Zero tests run, skipped suites, disabled checks, and cached results are not passes.
  6. Fix failures you caused. Show pre-existing failures are pre-existing (they fail on the base too) and report them; never weaken a check to get green.
  7. Report faithfully: what ran and its outcome, what couldn't be verified and why, and known gaps. Never write "should work" in place of checking, and never claim a check that didn't run.
  8. Lead with an honest outcome. A change whose related checks failed, timed out, or didn't run is "done, verification incomplete" — never "done". When the task defines outcome labels, use them exactly.

Record the starting state

"Pre-existing" is a claim about the past, so capture the past before changing anything: the revision, the dirty paths, and — when the task will end with a suite run — which tests already fail. Comparing against that record is how a failure is shown to be pre-existing without stashing or checking out the base in a working tree others may be using.

Workflow

  1. Requirements — list each requested outcome and the evidence for it.
  2. Diff — git status and the full diff; every hunk belongs to the task. In a shared working tree, other edits may appear in the diff: attribute only your hunks to the change, name the rest as not yours, and never revert them.
  3. Static checks — lint, format, type check (the lint and typecheck tools where available).
  4. Tests — targeted first (the codebase-targeted-test tool finds tests covering changed symbols), then the suites for touched packages. New behaviour has a test.
  5. Behaviour — run it for real when feasible.
  6. Blast radius — for changed signatures and contracts, check callers (the codebase-impact-analysis tool when indexed) and build the dependents.
  7. Cleanup — remove the temporary scripts, fixtures, and logs you created, and only those. If a check failed or cleanup is unsafe, leave them and report their exact path.
  8. Report.
Show full SKILL.md (295 more words)Show less

Minimum evidence by change type

ChangeEvidence
Bug fixThe same reproduction, with unchanged assertions and fixtures, fails before and passes after; its control case passes both times; a regression test in the normal suite, seen red then green
New featureTests for the main path and one error path; the user-facing flow run once
RefactorExisting tests pass without being edited; type check clean
Public API, schema, configConsumers build; migration applied and rolled back locally
UIRendered at the relevant widths; interactive states work; no console errors
Dependency updateClean install from the lockfile, build, full test suite; breaking changes in the changelog reviewed
Docs onlyLinks and code samples still valid

Report

text
Done: charges now retry with an idempotency key, so a timeout can't double-charge.

Verified
- Proof: `node scratch/double-charge.mjs` — exit 1 "FAIL: 2 charge requests" before, exit 0 after
- `pnpm --filter billing test` — 48 passed, including the new retry test (failed before the fix)
- Type check — clean
- `app charge --dry-run` on the fixture order — one charge request with the expected key

Not verified
- End-to-end suite (needs staging credentials)

Notes
- reports.spec.ts fails on main with the same error; unrelated and left untouched.

Anti-patterns

  • "Done — should work" with nothing run.
  • A filtered, cached, or partial run reported as the full suite.
  • Editing or skipping a test to make it pass.
  • A failure buried in the middle of a long summary.
  • "Pre-existing failure" claimed without checking the base.
  • Stopping at "it compiles".
  • A green proof reported as a verified fix while related checks fail.
  • "No bug found" presented as a clean bill of health for code that was only partly inspected.

Before returning

  • Outcome stated first, and "incomplete" wherever any check failed or didn't run
  • Every requested outcome maps to evidence
  • Own diff reviewed; nothing unrelated or left over; others' edits untouched
  • Temporary artifacts you created removed, or their path reported
  • Applicable checks run with the project's commands, results read
  • Behaviour exercised directly where tests don't cover it
  • Report separates verified, not verified, and pre-existing issues

Skills in scope

  • testing — for the tests the evidence needs
  • debugging — when verification turns up a failure with an unknown cause
  • code-review — for a self-review pass on a larger diff
  • git-flow — for committing once the change is verified

© WrongStack, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in packages/core/skills/verify-before-done of WrongStack/WrongStack.

  • SKILL.md
  • SKILL.save.md

Open the folder on GitHubat commit 57f6018

Compare with similar skills

Verify Before Done next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Verify Before Done compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Verify Before Done this skillWrongStack/WrongStack370—~1.6kAutomated safety check: PassMIT
Finishing a Development Branchobra/superpowers296k5 repos~1.9kAutomated safety check: PassMIT
Dos Verify Done Claimssickn33/agentic-awesome-skills47k1 repos~2.1kAutomated safety check: PassMIT
Story DoneDonchitos/Claude-Code-Game-Studios26k—~11kAutomated safety check: NotesMIT
Jobs To Be Done Analysisdeanpeters/Product-Manager-Skills7.2k1 repos~3.5kAutomated safety check: PassCustom licence
React Router PR Finish Lineremix-run/react-router57k—~1.4kAutomated safety check: PassMIT

Similar skills

  • Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.

    296k GitHub starsUsed in 5 repos~1.9k tokens
    DevelopmentAuto-check passed
  • Dos Verify Done Claims

    sickn33/agentic-awesome-skills

    Before accepting an agent's 'done / shipped / fixed' claim, verify it against ground truth (git ancestry + the commit's own diff) using the DOS kernel's dos verify and dos commit-audit — never the…

    47k GitHub starsUsed in 1 repo~2.1k tokens
    Media & CreativeAuto-check passed
  • Story Done

    Donchitos/Claude-Code-Game-Studios

    End-of-story completion review — verifies each acceptance criterion, checks GDD/ADR deviations, prompts code review, updates status.

    26k GitHub stars~11k tokensUpdated 8 days ago
    DevelopmentAuto-check: notes
  • Jobs To Be Done Analysis

    deanpeters/Product-Manager-Skills

    Structures customer jobs, pains and gains in a Jobs-to-be-Done format, to clarify unmet needs, reposition a product or sharpen discovery.

    7.2k GitHub starsUsed in 1 repo~3.5k tokens
    Product & Project ManagementAuto-check passed
  • React Router PR Finish Line

    remix-run/react-router

    Takes a blocked community pull request in React Router and adds the missing tests, change file or docs so it can merge, working on the contributor's branch.

    57k GitHub stars~1.4k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Jobs To Be Done Analyst

    sickn33/agentic-awesome-skills

    Uncover the functional, emotional and social jobs a customer hires a product to do: progress state, hiring trigger, alternatives, success criteria, JTBD map.

    47k GitHub starsUsed in 1 repo~1.6k tokens
    Product & Project ManagementAuto-check passed

More from WrongStack/WrongStack

All 38 skills in this repo
  • Design Craft

    WrongStack/WrongStack

    Design or substantially improve user-facing interfaces with a product-specific visual direction, content hierarchy, and rendered critique.

    370 GitHub stars~2k tokensUpdated today
    Auto-check passed
  • Design Critique

    WrongStack/WrongStack

    A skill your agent uses to audit an interface that already exists and say precisely why it looks generated, templated, or unfinished — a scored rubric across composition, typography, color, states…

    370 GitHub stars~3k tokensUpdated today
    Auto-check passed
  • Mailbox Bridge

    WrongStack/WrongStack

    A skill your agent uses when external coding agents (Claude Code, Aider, custom scripts) need to participate in the project's shared WrongStack mailbox, or when a user asks to "expose the mailbox"…

    370 GitHub stars~3.9k tokensUpdated today
    Auto-check passed
  • Multi Agent

    WrongStack/WrongStack

    A skill your agent uses whenever work can be split across multiple AI agents running in parallel, or when orchestrating leader/worker patterns in WrongStack.

    370 GitHub stars~3.6k tokensUpdated today
    Auto-check passed
  • Web Platform Baseline

    WrongStack/WrongStack

    Use this skill before asserting that a CSS, HTML or accessibility capability is available, unavailable, or the right tool — it carries dated, refreshable platform facts and refuses to let stale…

    370 GitHub stars~1.6k tokensUpdated today
    Auto-check passed
  • Wrongstack Mailbox

    WrongStack/WrongStack

    A skill your agent uses when the user wants to communicate with WrongStack's shared project mailbox from outside WrongStack — read messages sent by WrongStack agents, send replies, broadcast to all…

    370 GitHub stars~3.5k tokensUpdated today
    Auto-check passed

Questions about Verify Before Done

What does Verify Before Done do?

Use this skill before telling the user a code change is finished, fixed, or working — to prove it with the project's own checks and report exactly what was and wasn't verified. Verify Before Done is an agent skill from WrongStack/WrongStack. Use this skill before telling the user a code change is finished, fixed, or working — to prove it with the project's own checks and report exactly what was and wasn't verified.

How do I install Verify Before Done in Claude Code?

Run `npx skills add WrongStack/WrongStack --skill verify-before-done -a claude-code`. Or copy the skill folder (packages/core/skills/verify-before-done in WrongStack/WrongStack) into .claude/skills/verify-before-done in your project. Claude Code loads it when a task matches its description.

How do I install Verify Before Done in Codex?

Run `npx skills add WrongStack/WrongStack --skill verify-before-done -a codex`. Or copy the skill folder (packages/core/skills/verify-before-done in WrongStack/WrongStack) into .agents/skills/verify-before-done in your project. Codex loads it when a task matches its description.

Can I use Verify Before Done in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add WrongStack/WrongStack --skill verify-before-done -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/verify-before-done, .gemini/skills/verify-before-done, .github/skills/verify-before-done and .opencode/skills/verify-before-done in your project.

What does Verify Before Done need to run?

Going by SKILL.md and its folder, Verify Before Done needs the command-line tools its instructions call (git).

Does Verify Before Done access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Verify Before Done safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Verify Before Done use?

Verify Before Done is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Verify Before Done use?

About 1.6k tokens (SKILL.md is roughly 6.3k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Verify Before Done?

Skills that share tags, products or a category with Verify Before Done: Finishing a Development Branch (obra/superpowers, 296k stars), Dos Verify Done Claims (sickn33/agentic-awesome-skills, 47k stars), Story Done (Donchitos/Claude-Code-Game-Studios, 26k stars) and Jobs To Be Done Analysis (deanpeters/Product-Manager-Skills, 7.2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Verify Before Done?

WrongStack (a GitHub organization) maintains it in WrongStack/WrongStack, which has 370 GitHub stars. The repository holds 38 skills in this directory. The repository was last updated on October 7, 2026.

Source: WrongStack/WrongStack on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.