| name | quality-gates |
| description | Fresh verification before any completion claim. Invoke after implementation, after bug fixes, before saying "done", "fixed", "ready", or "safe to merge", and before commit/PR handoff. Do not infer success from code inspection or an old test run. |
Quality Gates
Completion is a claim about reality, not a feeling about the diff. If you have not run the command that proves the claim in this session, you do not have evidence yet.
This skill answers one question: what fresh verification is required before you can honestly say the work is done?
The Rule
No completion claims without fresh verification evidence.
That applies to all equivalents:
- "done"
- "fixed"
- "ready"
- "should work"
- "safe to merge"
- "all good"
If verification cannot be run, say that directly and state the residual risk. Never blur "not verified" into "complete".
Step 1 - Define the claim
State the exact claim you are about to make, then choose the evidence that proves it:
| Claim | Minimum evidence |
|---|
| Bug fixed | Reproduction or regression test now passes |
| Feature works | Tests for new behavior pass |
| Refactor is safe | Existing tests for touched surface still pass |
| Ready to commit / PR | Repo-appropriate verification suite for touched files passes |
| Build is healthy | Build command exits 0 |
| Lint is clean | Lint command reports 0 errors |
| Types are valid | Typecheck / compile step exits 0 |
Do not substitute one proof for another. Lint is not build. Build is not tests. Old output is not fresh evidence.
Step 2 - Choose the verification set
Start from the changed surface, not from habit.
Always inspect first
- Read the diff
- Identify which files and layers changed
- Detect the project's canonical commands before inventing your own
Prefer project-owned scripts and task runners:
- Node:
package.json scripts via pnpm|npm|yarn|bun run
- Python:
pytest, ruff, mypy, project wrappers like tox or just
- Go:
go test ./..., go vet ./..., gofmt -l
- Rust:
cargo test, cargo fmt --check, cargo clippy -- -D warnings
Escalate verification by change type
| Change type | Usually required |
|---|
| Logic / bug fix | Targeted tests proving the changed behavior |
| Shared library / public API / schema | Targeted tests + broader suite + typecheck/build |
| TS/JS source | Tests + lint + typecheck if scripts exist |
| UI flow | Relevant automated test, or browser/manual verification if no automation exists |
| Build / config / dependency changes | Build/install command that exercises the changed path |
| Only docs / comments | Link check or docs build if present; otherwise explain why no code verification is needed |
Use the smallest set that honestly proves the claim. High-risk or cross-cutting changes need broader verification, not clever wording.
Step 3 - Run commands fresh
Run the full commands now. No partial logs, no stale output, no "it passed earlier".
Good pattern:
- Targeted verification for the exact change
- Project-level gates for the touched surface
- Optional broader sweep if the change is risky
Example sequence:
pnpm test -- --runInBand src/foo/bar.test.ts
pnpm lint
pnpm typecheck
pnpm build
If the repo only exposes one canonical command such as make verify, just check, or npm test, use that instead of reconstructing a custom pipeline.
Step 4 - Read the output, don't pattern-match it
Check:
- exit code
- failure count
- whether the command actually covered the changed area
- whether warnings imply residual risk
Common failure modes:
- command passed, but not the tests that exercise the changed code
- targeted test passed, but typecheck/build was skipped after touching interfaces
- command failed and the failure was omitted from the summary
- output was from before the last edit
If anything fails, report the real state:
- what failed
- whether you fixed it
- what remains unverified
Step 5 - Report with evidence
Completion reports should name the proof, not just the conclusion.
Good:
- "Verified with
pnpm test -- foo.test.ts and pnpm typecheck; both passed after the last edit."
- "I fixed the bug and confirmed the regression with
pytest tests/test_login.py -k expired_token."
- "I have not run the build yet, so I cannot claim this is ready to merge."
Bad:
- "Done."
- "Should pass now."
- "Looks good to me."
- "I think this is fixed."
Minimal exit checklist
Before any completion claim, confirm:
- I know exactly what claim I am making
- I ran the command that proves that claim after the last code change
- The command covered the changed surface
- I read the actual output
- My summary distinguishes verified facts from remaining risk
Miss one box and the gate has not passed.
