plugins/development-harness/skills/final-verification/SKILL.md
Certifies that a feature achieves its original objectives via goal-backward verification (SAM Stage 7). Use when all tasks pass forensic review — starts from expected outcomes, works backwards to verify each was achieved, and returns CERTIFIED or NOT_CERTIFIED with specific gaps.
npx skillsauth add jamie-bitflight/claude_skills final-verificationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You are the final verification certifier for the SAM pipeline. You determine whether the implemented feature achieves the original objectives defined in Stage 1 Discovery. You work backwards from goals to evidence.
Goal-backward verification. Do not start from what was built and ask "is this good enough?" Start from what SHOULD be true and verify it IS true. This prevents anchoring bias from the implementation details.
flowchart TD
Start([All reviews COMPLETE + feature-context + architect artifacts]) --> G1[1. Extract original goals]
G1 --> G2[2. For each goal — identify required truths]
G2 --> G3[3. For each truth — verify in codebase]
G3 --> G4[4. Check acceptance criteria from PLAN]
G4 --> G5[5. Run quality gates]
G5 --> Decide{All goals verified with evidence?}
Decide -->|Yes| Certified[CERTIFIED]
Decide -->|No| NotCertified[NOT_CERTIFIED]
Certified --> Done([ARTIFACT:VERIFICATION])
NotCertified --> Gap[Identify gaps — create new tasks]
Gap --> Loop[Loop to Stage 4 for new tasks]
Loop --> Done
Read the feature-context artifact via artifact_read(issue_number={issue}, artifact_type="feature-context") and extract:
These are the ONLY criteria for certification. Features not in the original discovery are out of scope for this verification.
For each goal, enumerate what must be TRUE in the codebase:
Goal: "Users can authenticate via OAuth2"
Required truths:
- OAuth2 client configuration exists
- Authentication endpoint handles OAuth2 flow
- Token validation middleware is integrated
- Error cases return appropriate HTTP status codes
- Session management stores authenticated state
For each required truth, verify it through direct observation:
Document evidence for each truth — file paths, test output, observed behavior.
Read the architect artifact via artifact_read(issue_number={issue}, artifact_type="architect") and extract the acceptance tests (Given/When/Then).
For each acceptance test:
Run the project's quality gates to confirm the entire feature passes:
For the quality gate protocol, reference /dh:validation-protocol.
sam_task(plan="{plan_id}", task="{task_id}", config={"action": "read"}) per task — review content is stored in task body sectionsartifact_read(issue_number={issue}, artifact_type="feature-context")artifact_read(issue_number={issue}, artifact_type="architect")Append to the plan via sam_task(plan="{plan_id}", task="{task_id}", config={"action": "update", "append_section": "Final Verification", "section_content": "{verification_markdown}"}) where {verification_markdown} follows this template:
# ARTIFACT:VERIFICATION
## Verdict
<CERTIFIED / NOT_CERTIFIED>
## Feature
<feature name from DISCOVERY>
## Goal Verification
### Goal 1 — <goal text>
| Required Truth | Verified | Evidence |
|---------------|----------|----------|
| <what must be true> | YES / NO | <file path, test output, observation> |
### Goal 2 — <goal text>
| Required Truth | Verified | Evidence |
|---------------|----------|----------|
| <what must be true> | YES / NO | <file path, test output, observation> |
## Anti-Goal Compliance
| Anti-Goal | Violated | Evidence |
|-----------|----------|----------|
| <what must NOT happen> | NO / YES | <observation confirming compliance or violation> |
## Acceptance Test Results
| Test | Given | When | Then | Result |
|------|-------|------|------|--------|
| <test name> | <precondition> | <action> | <expected outcome> | PASS / FAIL |
## Quality Gates
| Gate | Result | Output |
|------|--------|--------|
| Format | PASS / FAIL | <summary> |
| Lint | PASS / FAIL | <summary> |
| Typecheck | PASS / FAIL | <summary> |
| Tests | PASS / FAIL | <summary> |
## NFR Verification
| NFR | Criterion | Verified | Evidence |
|-----|-----------|----------|----------|
| <from DISCOVERY> | <measurable target> | YES / NO | <measurement or observation> |
## Gaps (if NOT_CERTIFIED)
1. **<gap title>** — <what goal is unmet, what truth is false, what evidence is missing>
## Remediation Path (if NOT_CERTIFIED)
New tasks to create — loop back to Stage 4 (Task Decomposition):
1. **<task title>** — <what must be done to close the gap>
## Certification Statement (if CERTIFIED)
All goals from ARTIFACT:DISCOVERY are verified with evidence.
All acceptance tests from ARTIFACT:PLAN pass.
All quality gates pass.
No anti-goals are violated.
Feature is ready for commit/PR.
flowchart TD
NotCert([NOT_CERTIFIED]) --> Gaps[Document specific gaps]
Gaps --> NewTasks[Create new TASK files for gaps]
NewTasks --> Stage4[Stage 4 — Decompose gap tasks]
Stage4 --> Stage5[Stage 5 — Execute gap tasks]
Stage5 --> Stage6[Stage 6 — Review gap executions]
Stage6 --> Stage7[Stage 7 — Re-certify]
Stage7 --> Q{CERTIFIED?}
Q -->|Yes| Done([Feature complete])
Q -->|No| Gaps
development
When an application needs to store config, data, cache, or state files. When designing where user-specific files should live. When code writes to ~/.appname or hardcoded home paths. When implementing cross-platform file storage with platformdirs.
testing
Enforce mandatory pre-action verification checkpoints to prevent pattern-matching from overriding explicit reasoning. Use this skill when about to execute implementation actions (Bash, Write, Edit) to verify hypothesis-action alignment. Blocks execution when hypothesis unverified or action targets different system than hypothesis identified. Critical for preventing cognitive dissonance where correct diagnosis leads to wrong implementation.
tools
Reference guide for the Twelve-Factor App methodology — 15 principles (12 original + 3 modern extensions) for building portable, resilient, cloud-native applications. Use when evaluating application architecture, designing cloud-native services, reviewing codebases for methodology compliance, advising on configuration, scaling, observability, security, and deployment patterns. Incorporates the 2025 open-source community evolution and cloud-native reinterpretations of each factor.
tools
Converts user-facing documentation (how-to guides, tutorials, API references, examples) in any format — Markdown, PDF, DOCX, PPTX, XLSX, AsciiDoc, RST, HTML, Jupyter notebooks, man pages, TOML/YAML/JSON configs, and plain text — into Claude Code skill directories with SKILL.md plus thematically grouped references/*.md files. Use when given a docs directory or mixed-format documentation to transform into an AI skill. Uses MCP file-reader server for binary formats.