| name | implementation-verification-pass | ||
|---|---|---|---|
| description | Perform a post-implementation verification pass to validate that approved changes were implemented correctly, consistently, and safely, then generate VERIFICATION.md. | ||
| version | 1.0.0 | ||
| phase | verification | ||
| requires |
|
||
| produces | VERIFICATION.md | ||
| next | release-readiness-pass |
Use this skill after implementation has already been completed.
The goal is to verify that recent changes:
- align with the decisions clarified in
QUESTIONS.md - were implemented correctly and consistently
- did not introduce regressions, scope creep, or architectural drift
- updated tests, docs, and related modules where necessary
- left the codebase in a stable and maintainable state
This skill is about verification, not new feature work.
This is Phase 3 — Verification.
QUESTIONS.mdIMPLEMENTATION_NOTES.md
VERIFICATION.md
release-readiness-pass
- implementation is incomplete
- key decisions are still blocked
- verification cannot be done with confidence due to missing artifacts
Act as:
- a principal engineer doing a final technical review
- a tech lead validating execution quality
- a guardian of consistency, safety, and scope discipline
Review what changed.
Check whether it matches intent.
Validate whether it is complete enough.
Identify residual risk or regression.
This skill must verify:
Did implementation honor approved answers?
Do the changes look correct and coherent?
Did implementation avoid unnecessary drift?
Did the changes introduce fragility or hidden breakage?
Were tests, docs, types, validation, and related files updated appropriately?
Read QUESTIONS.md and infer:
- confirmed bugs
- intended behaviors
- approved improvements
- deferred items
- blocked areas
Review changed files and adjacent areas that may be indirectly affected.
Ask for each significant change:
- does it trace back to an approved decision?
- is behavior consistent with clarified intent?
- was anything left partial?
- was any deferred item changed accidentally?
Inspect for:
- correctness
- consistency with architecture
- naming quality
- duplication
- broken invariants
- missing validation
- brittle logic
- weak error handling
- hidden coupling
Check whether tests were:
- added or updated when needed
- aligned with clarified behavior
- broad enough to reduce regression risk
Check whether relevant docs, comments, setup guides, examples, or env files were updated where needed.
Look beyond changed files and assess cross-module consistency and stale leftovers.
Use categories such as:
verifiedpartialblockedcaveatout-of-scope
Create:
VERIFICATION.md
Suggested structure:
What was reviewed and the overall result.
- ...
- ...
- ...
- ...
- what was implemented correctly
- what was partial
- what remained untouched appropriately
- what exceeded scope
- what was covered
- what is missing
- what was updated
- what remains stale
verifiedpartialblockedcaveatout-of-scope
- ...
A good verification pass:
- confirms implementation truly matches approved decisions
- detects regressions and inconsistencies
- distinguishes partial from complete work
- leaves a clear factual record of remaining risk
A weak pass only restates what changed and ignores decision alignment, tests, docs, and indirect regressions.
Do not:
- start a broad new refactor
- confuse new ideas with verification findings
- mark work correct without checking related areas
Do:
- verify against clarified intent
- inspect integration points
- classify severity clearly
- use evidence, not speculation
This skill ends when VERIFICATION.md is complete.
Run release-readiness-pass to determine whether the project is actually ready for merge, handoff, staging, or production.
If VERIFICATION.md contains unresolved must-fix findings, do not mark the project as ready for release.