verification-before-completion

Name: verification-before-completion
Author: krzysztofsurdy

20installs1forks

How to install verification-before-completion?

krzysztofsurdy/code-virtuoso/verification-before-completion

$npx -y skills add krzysztofsurdy/code-virtuoso --skill verification-before-completion

Installs into the current project.

Summary

Evidence-based completion discipline. Use before claiming any work is 'done', complete, finished, or ready — whether it is code, config, documentation, a migration, or a bugfix. Requires running verification commands (tests, lints, type checks, builds, smoke tests), capturing out

Files · 1

View on GitHub

SKILL.md

1	# Verification Before Completion
2
3	Discipline for proving work is done rather than asserting it. Every completion claim must be backed by captured output from verification commands executed in the current session. This skill exists because the most expensive bugs are not the ones that fail loudly — they are the ones that ship behind a confident "it works."
4
5	## Iron Law
6
7	No "done" without evidence. Assertions are not evidence.
8
9	If you have not run a verification command and read its output in this session, you cannot claim the work passes. "Should work" is not a status. "I believe it's correct" is not a test result. The only acceptable proof is captured output from an executed command.
10
11	## Why This Matters
12
13	False completion is more costly than incomplete work. Incomplete work is visible — someone will finish it. False completion is invisible — it passes review, merges, deploys, and fails in production. Every minute spent on proper verification saves hours of debugging, rollback, incident response, and trust repair. The cost of catching a defect multiplies by orders of magnitude at each stage: local development, code review, staging, production. Verify early, verify often, verify with evidence.
14
15	## Core Principles
16
17	\| Principle \| Meaning \|
18	\|---\|---\|
19	\| Evidence over assertion \| A claim is only as strong as the output backing it. No output, no claim. \|
20	\| Fresh over stale \| Only verification run in the current session counts. Previous runs prove nothing about current state. \|
21	\| Complete over partial \| Running one test file does not verify the suite. Running the linter does not verify the build. Each check covers its own surface. \|
22	\| Captured over remembered \| Paste the output. Do not summarize from memory. Memory lies. \|
23	\| Exit code over log lines \| A command that prints "OK" but exits non-zero has failed. Always check the exit code. \|
24	\| Automated over manual \| A reproducible command beats "I checked it manually" every time. \|
25
26	## Tiered Definition of Done
27
28	Work passes through multiple tiers before it is truly done. Each tier has its own evidence requirements. See [done-definitions](references/done-definitions.md) for the full breakdown.
29
30	\| Tier \| What It Means \| Minimum Evidence \|
31	\|---\|---\|---\|
32	\| Local done \| Works on the development machine \| Tests pass, linter clean, type checker clean, build succeeds — all with captured output \|
33	\| Review-ready done \| Safe for a peer to evaluate \| Local done + changes committed, PR description matches actual changes, no untracked files \|
34	\| Merged done \| Accepted into the main branch \| Review-ready done + CI pipeline green, reviewer approved, no merge conflicts \|
35	\| Deployed done \| Running in a target environment \| Merged done + deployment command succeeded, health check returns expected status \|
36	\| Verified-in-production done \| Confirmed working for real users \| Deployed done + smoke tests pass against live environment, key metrics stable, no new errors in logs \|
37
38	## The Verification Cycle
39
40	Run this cycle before every completion claim.
41
42	### Phase 1: Identify Verification Surface
43
44	Determine what needs to be verified based on what changed.
45
46	- List every file modified, added, or deleted
47	- Map each change to its verification category (code, config, schema, docs, infra)
48	- Identify the minimum set of commands that covers all changed surfaces
49	- If unsure what to verify, verify everything — over-verification costs minutes, under-verification costs hours
50
51	### Phase 2: Run Verification Commands
52
53	Execute every required command. Do not skip any.
54
55	- Run commands in the project root unless they require a specific directory
56	- Use the project's own scripts and configuration — do not invent custom verification
57	- Run the full suite, not a subset, unless the full suite takes more than 5 minutes (then run targeted + note that full suite is deferred)
58	- Capture both stdout and stderr
59
60	### Phase 3: Capture Output
61
62	Record the raw output from every command.
63
64	- Include the exact command that was run
65	- Include the full output (or the summary section for large outputs)
66	- Include the exit code
67	- Timestamp is implicit in the current session — do not fabricate timestamps
68
69	### Phase 4: Compare to Expected
70
71	Verify that the output matches success criteria.
72
73	-

People who liked this also viewed

6 picks

Type

verification-before-completion

20installs1forks

View on GitHub

How to install verification-before-completion?

krzysztofsurdy/code-virtuoso/verification-before-completion

$npx -y skills add krzysztofsurdy/code-virtuoso --skill verification-before-completion

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Verification Before Completion
2
3	Discipline for proving work is done rather than asserting it. Every completion claim must be backed by captured output from verification commands executed in the current session. This skill exists because the most expensive bugs are not the ones that fail loudly — they are the ones that ship behind a confident "it works."
4
5	## Iron Law
6
7	No "done" without evidence. Assertions are not evidence.
8
9	If you have not run a verification command and read its output in this session, you cannot claim the work passes. "Should work" is not a status. "I believe it's correct" is not a test result. The only acceptable proof is captured output from an executed command.
10
11	## Why This Matters
12
13	False completion is more costly than incomplete work. Incomplete work is visible — someone will finish it. False completion is invisible — it passes review, merges, deploys, and fails in production. Every minute spent on proper verification saves hours of debugging, rollback, incident response, and trust repair. The cost of catching a defect multiplies by orders of magnitude at each stage: local development, code review, staging, production. Verify early, verify often, verify with evidence.
14
15	## Core Principles
16
17	\| Principle \| Meaning \|
18	\|---\|---\|
19	\| Evidence over assertion \| A claim is only as strong as the output backing it. No output, no claim. \|
20	\| Fresh over stale \| Only verification run in the current session counts. Previous runs prove nothing about current state. \|
21	\| Complete over partial \| Running one test file does not verify the suite. Running the linter does not verify the build. Each check covers its own surface. \|
22	\| Captured over remembered \| Paste the output. Do not summarize from memory. Memory lies. \|
23	\| Exit code over log lines \| A command that prints "OK" but exits non-zero has failed. Always check the exit code. \|
24	\| Automated over manual \| A reproducible command beats "I checked it manually" every time. \|
25
26	## Tiered Definition of Done
27
28	Work passes through multiple tiers before it is truly done. Each tier has its own evidence requirements. See [done-definitions](references/done-definitions.md) for the full breakdown.
29
30	\| Tier \| What It Means \| Minimum Evidence \|
31	\|---\|---\|---\|
32	\| Local done \| Works on the development machine \| Tests pass, linter clean, type checker clean, build succeeds — all with captured output \|
33	\| Review-ready done \| Safe for a peer to evaluate \| Local done + changes committed, PR description matches actual changes, no untracked files \|
34	\| Merged done \| Accepted into the main branch \| Review-ready done + CI pipeline green, reviewer approved, no merge conflicts \|
35	\| Deployed done \| Running in a target environment \| Merged done + deployment command succeeded, health check returns expected status \|
36	\| Verified-in-production done \| Confirmed working for real users \| Deployed done + smoke tests pass against live environment, key metrics stable, no new errors in logs \|
37
38	## The Verification Cycle
39
40	Run this cycle before every completion claim.
41
42	### Phase 1: Identify Verification Surface
43
44	Determine what needs to be verified based on what changed.
45
46	- List every file modified, added, or deleted
47	- Map each change to its verification category (code, config, schema, docs, infra)
48	- Identify the minimum set of commands that covers all changed surfaces
49	- If unsure what to verify, verify everything — over-verification costs minutes, under-verification costs hours
50
51	### Phase 2: Run Verification Commands
52
53	Execute every required command. Do not skip any.
54
55	- Run commands in the project root unless they require a specific directory
56	- Use the project's own scripts and configuration — do not invent custom verification
57	- Run the full suite, not a subset, unless the full suite takes more than 5 minutes (then run targeted + note that full suite is deferred)
58	- Capture both stdout and stderr
59
60	### Phase 3: Capture Output
61
62	Record the raw output from every command.
63
64	- Include the exact command that was run
65	- Include the full output (or the summary section for large outputs)
66	- Include the exit code
67	- Timestamp is implicit in the current session — do not fabricate timestamps
68
69	### Phase 4: Compare to Expected
70
71	Verify that the output matches success criteria.
72
73	-

People who liked this also viewed

6 picks

Type