How do I install the Validate Completion skill?

Run npx skillmds@latest add ronniepinnell/validate-completion 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 Validate Completion 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 Validate Completion?

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 Validate Completion free to use?

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

Who published Validate Completion?

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

Validate Completion by ronniepinnell

Name: Validate Completion
Author: ronniepinnell

Validate Completion

Single-task completion verifier. When an implementer claims a task or feature is finished, establish whether the goal was genuinely achieved — by executing it when possible, by rigorous inspection when not. Compiling, existing, or green tests are not proof. Use immediately on any "done" claim, before the status is recorded.

File contents

/validate-completion — Prove One Claim

Thin entry point: this is /completion-audit --task <id> — the same audit scoped to a single claim, kept as its own name because it fires at a different moment (the instant "done" is declared) and returns a binary approve/reject. Procedure detail lives in completion-audit/SKILL.md steps 2–4; report format, ruling grammar, severity tiers, JSON trailer, and routing table live in _shared/audit-report-contract.md.

Invocation

/validate-completion {task_prefix}-123        # verify a tracked task's claim
/validate-completion the CSV export works     # verify an ad-hoc claim

Depth modes (state which was used)

Execution mode (runnable environment available) — everything in inspection mode, plus: invoke the feature for real; feed it invalid input and confirm graceful failure; UI renders with zero console errors; expected DB state changes happen; trace input → output end-to-end.

Inspection mode (no runnable environment) — artifacts exist and are non-empty; no TODO/FIXME/placeholder markers or empty bodies; imports resolve to real modules; tests exercise the real code path (not just mocks); no hardcoded values that should be configurable; the new unit is actually registered/wired — a file nothing imports is incomplete. Inspection-only caps the verdict at inconclusive if the primary claim couldn't be executed.

What disqualifies a claim

Mocked/stubbed implementations passed off as complete; tests that pass regardless of behavior; integrations wired to fake endpoints or hardcoded responses; silently swallowed errors; missing supporting artifacts (config, migrations, deps); security/validation shortcuts; orphaned unreachable code.

Output

APPROVE / REJECT on the claim, with per-claim CONFIRMED/REFUTED/UNVERIFIED rulings and executed evidence (adversarial posture: build the breaking input first, per /refute).
Blocking problems (severity + file:line), missing components, non-blocking quality concerns, concrete next steps.
Out-of-scope failures routed per the shared contract's routing table (complexity → pragmatism-audit; requirement confusion → spec-audit; rule breakage → rules-audit; whole-project reality → completion-audit).
JSON trailer per the shared contract, and the verdict line logged via /verdict:

AUDIT: validate-completion | <task id> | <pass|fail|inconclusive> | <blocking>/<total> findings

Judgment weave

The core of this skill IS /refute pointed at one claim — run its 5 steps.
REJECT verdicts worth remembering → /verdict; recurring rejection causes → a hook or domain line per judgment/MANUAL.md §4.

Composes with

/completion-audit — the parent audit; this is its --task scope.
/issue done, /epic close — call this before recording Done.
claim-evidence hook — blocks evidence-free done-claims; this produces the evidence.

---name: validate-completiondescription: Single-task completion verifier. When an implementer claims a task or feature is finished, establish whether the goal was genuinely achieved — by executing it when possible, by rigorous inspection when not. Compiling, existing, or green tests are not proof. Use immediately on any "done" claim, before the status is recorded.---# /validate-completion — Prove One ClaimThin entry point: this is `/completion-audit --task <id>` — the same auditscoped to a single claim, kept as its own name because it fires at a differentmoment (the instant "done" is declared) and returns a binary approve/reject.Procedure detail lives in `completion-audit/SKILL.md` steps 2–4; reportformat, ruling grammar, severity tiers, JSON trailer, and routing table livein `_shared/audit-report-contract.md`.## Invocation```/validate-completion {task_prefix}-123 # verify a tracked task's claim/validate-completion the CSV export works # verify an ad-hoc claim```## Depth modes (state which was used)**Execution mode** (runnable environment available) — everything in inspectionmode, plus: invoke the feature for real; feed it invalid input and confirmgraceful failure; UI renders with zero console errors; expected DB statechanges happen; trace input → output end-to-end.**Inspection mode** (no runnable environment) — artifacts exist and arenon-empty; no TODO/FIXME/placeholder markers or empty bodies; imports resolveto real modules; tests exercise the real code path (not just mocks); nohardcoded values that should be configurable; the new unit is actuallyregistered/wired — a file nothing imports is incomplete. Inspection-onlycaps the verdict at `inconclusive` if the primary claim couldn't be executed.## What disqualifies a claimMocked/stubbed implementations passed off as complete; tests that passregardless of behavior; integrations wired to fake endpoints or hardcodedresponses; silently swallowed errors; missing supporting artifacts (config,migrations, deps); security/validation shortcuts; orphaned unreachable code.## Output- **APPROVE / REJECT** on the claim, with per-claim CONFIRMED/REFUTED/UNVERIFIED rulings and executed evidence (adversarial posture: build the breaking input first, per /refute).- Blocking problems (severity + file:line), missing components, non-blocking quality concerns, concrete next steps.- Out-of-scope failures routed per the shared contract's routing table (complexity → pragmatism-audit; requirement confusion → spec-audit; rule breakage → rules-audit; whole-project reality → completion-audit).- JSON trailer per the shared contract, and the verdict line logged via `/verdict`:```AUDIT: validate-completion | <task id> | <pass|fail|inconclusive> | <blocking>/<total> findings```## Judgment weave- The core of this skill IS `/refute` pointed at one claim — run its 5 steps.- REJECT verdicts worth remembering → `/verdict`; recurring rejection causes → a hook or domain line per `judgment/MANUAL.md` §4.## Composes with- `/completion-audit` — the parent audit; this is its `--task` scope.- `/issue done`, `/epic close` — call this before recording Done.- `claim-evidence` hook — blocks evidence-free done-claims; this produces the evidence.

Frequently asked questions