Verify before done
Skill chipfighter/coding-discipline/plugins/coding-discipline/skills/verify-before-done
Workflow-agnostic guardrails for AI coding agents: spec sync + risk-triggered engineering discipline for Claude Code and Codex.
npx -y skills add chipfighter/coding-discipline --skill verify-before-doneAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 24 days oldThe repository was created 24 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use before claiming "done", "fixed", "tested", or "it runs", and before committing or opening a PR or MR—no task is exempt. Accept only evidence gathered after the last relevant change and just sufficient to prove the claim; do not over-verify small changes.
SKILL.md
3.0 KB, as published. Nobody here has run it
Hard rule: Only evidence gathered after the last relevant change to the code, files, or environment, and directly sufficient to prove the claim, counts.
- Claiming completion without sufficient evidence = lying; running the full test suite for a typo = waste.
- You may reuse evidence just gathered, but state when it was gathered and confirm that no code was changed, nothing was pulled, and the environment was not modified afterward. If you cannot say for sure, check again.
Required checks (before any claim of success or completion)
- What claim must be proven? What check is just sufficient (command output / diff / artifact inspection…)?
- Was the evidence gathered after the last relevant change? Yes—state when. No / uncertain—check again.
- If you ran a command, read all output, inspect the exit code, and count failures. If you inspected a diff or artifact, state what you checked and the result.
- Does the evidence actually prove the claim? Yes—state the conclusion together with the evidence. No—report the true status.
Skipping any step = lying, not verification.
Could not run ≠ skipped
If a command cannot run (missing environment, broken dependencies, timeout), verification failed. Report that verification could not be completed and what blocked it. Do not quietly mark the step green as “skipped,” and do not misreport an environment problem as a product failure.
None of these counts as "verified"
| Claimed evidence | Why it does not count |
|---|---|
| lint / type checks passed | This proves only that the checks pass, not that the project builds, runs, or behaves correctly. |
| A subagent reported "success" | That is its claim. Inspect the diff / actual artifact yourself. |
| The regression test passed once | This does not prove it catches the problem. In a safe, isolated way, temporarily disable this round's fix → the test must fail → restore the fix → the test must pass. Do not do this by reverting or overwriting user files. |
| "Tests are green = requirements are met" | Check each requirement explicitly; green tests alone are not enough. |
| Only part of the suite ran | This does not mean the whole suite passed. |
Hard rules
- Do not substitute "should", "probably", or "looks right" for evidence.
- Do not celebrate ("Done!" / "Fixed!" / "Perfect!") before obtaining evidence.
- Before committing, pushing, or opening a PR or MR after an important change, pass the checks above.
- If this work includes a confirmed change that makes the current source of truth inaccurate, or the work spans sessions but still lacks a source of truth, use spec-sync before claiming it is ready for handoff. If the user explicitly refuses persistence, explain the consequence and follow their latest instruction.