Sdd Verify
Run a structured SDD verification pass and emit a PASS / PASS WITH WARNINGS / FAIL report with dimension scores and tool execution results before you treat a change as done.
Overview
sdd-verify is an agent skill for the Ship phase that formats and persists a multi-dimension verification report with tool execution evidence for a spec-driven change.
Install
npx skills add https://github.com/fearovex/claude-config --skill sdd-verifyWhat is this skill?
- Six-dimension summary table: Completeness, Correctness, Coherence, Testing, Test Execution, Build
- Mandatory Tool Execution section with command, exit code, and PASS/FAIL/SKIPPED per row
- Compact verify-report persisted via mem_save with topic_key sdd/{change-name}/verify-report
- Per-dimension detail blocks shown in chat only—not duplicated in the persisted artifact
- CRITICAL vs WARNINGS issue buckets with explicit None when clean
- Six verification dimensions in the summary table
- Mandatory Tool Execution section even when tests are SKIPPED
Adoption & trust: 1 installs on skills.sh; 1 GitHub stars; 2/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You finished an SDD change but have no standardized verdict, dimension checklist, or logged command results to justify shipping.
Who is it for?
Teams running numbered SDD workflows who want engram-persisted verify reports after implementation.
Skip if: Ad-hoc manual QA without the parent SDD skill chain or when you only need a one-off lint without a change name and project scope.
When should I use this skill?
SDD workflow reaches Step 10 and you need to verify a named change and persist verify-report output.
What do I get? / Deliverables
You get a dated verification report with verdict, six dimension statuses, mandatory tool execution rows, and CRITICAL/WARNING issues saved under sdd/{change-name}/verify-report for the next review or release step.
- Compact verification report markdown for engram
- Conversational per-dimension detail blocks
- Verdict PASS / PASS WITH WARNINGS / FAIL
Recommended Skills
Journey fit
Verification is the gate at the end of spec-driven delivery—after build work and before you ship or merge. Testing subphase is where completeness, correctness, coherence, test execution, and build commands are checked against the change.
How it compares
Structured verification artifact for SDD Step 10—not a generic test-runner skill or an MCP server.
Common Questions / FAQ
Who is sdd-verify for?
Solo and indie builders using fearovex claude-config SDD who want agents to close changes with a consistent verify report and memory persistence.
When should I use sdd-verify?
At Ship/testing when a named change is ready for sign-off: after build work, before merge or deploy, as Step 10 of the SDD flow.
Is sdd-verify safe to install?
It defines report templates and persistence shape; review the Security Audits panel on this Prism page and treat mem_save and shell commands in your SDD stack as sensitive.
SKILL.md
READMESKILL.md - Sdd Verify
# sdd-verify — Report Templates > Reference file consumed by `SKILL.md` Step 10. Contains the persisted-to-engram > compact format and the per-dimension detail blocks emitted to the > conversational output. ## Persisted to engram (compact) Saved via `mem_save` with `topic_key: sdd/{change-name}/verify-report`, `type: architecture`, `project: {project}`. Only this content is persisted. ```markdown # Verification Report: [change-name] Date: [YYYY-MM-DD] Verdict: PASS / PASS WITH WARNINGS / FAIL ## Summary | Dimension | Status | |-----------------|---------------------------------| | Completeness | OK / WARNING / CRITICAL | | Correctness | OK / WARNING / CRITICAL | | Coherence | OK / WARNING / CRITICAL | | Testing | OK / WARNING / CRITICAL | | Test Execution | OK / WARNING / CRITICAL / SKIPPED | | Build | OK / WARNING / SKIPPED | ## Tool Execution | Command | Exit Code | Result | |---------------|-----------|----------------------| | [command] | [code] | [PASS/FAIL/SKIPPED] | ## Issues ### CRITICAL - [issue description] [or: "None."] ### WARNINGS - [issue description] [or: "None."] ``` The `## Tool Execution` section is mandatory even when skipped. When skipped: `"Test Execution: SKIPPED — no test runner detected"`. ## Conversational output (NOT persisted) These detail blocks are shown to the user only — they do NOT go in the persisted artifact. They cover Steps 2–9 of the audit and give the user full visibility. ### Completeness block ```markdown ### Completeness | Metric | Value | |----------------------|-------| | Total tasks | [N] | | Completed tasks [x] | [M] | | Incomplete tasks [ ] | [K] | Incomplete tasks: - [ ] [number and description of each one] ``` ### Correctness block ```markdown ### Correctness (Specs) | Requirement | Status | Notes | |-------------|--------------------|---------------------------------------| | [Req 1] | ✅ Implemented | | | [Req 2] | ⚠️ Partial | Missing 401 error scenario | | [Req 3] | ❌ Not implemented | Endpoint /auth/refresh does not exist | ### Scenario Coverage | Scenario | Status | |------------------------------------|--------------------------------------| | Successful login | ✅ Covered | | Failed login — incorrect password | ✅ Covered | | Failed login — user does not exist | ⚠️ Partial — implemented but no test | | Expired token | ❌ Not covered | ``` ### Coherence block ```markdown ### Coherence (Design) | Decision | Followed? | Notes | |---------------------|---------------|----------------------------------------| | Validation with Zod | ✅ Yes | | | JWT with RS256 | ⚠️ Deviation | HS256 used. Dev documented in tasks. | | Repository pattern | ✅ Yes | | ``` ### Testing block ```markdown ### Testing | Area | Tests Exist | Scenarios Covered | |---------------------|-------------|-------------------| | AuthService.login() | ✅ Yes | 3/4 scenarios | | AuthController | ✅ Yes | Happy paths only | | JWT Middleware | ❌ No | — | ``` ### Spec Compliance Matrix ```markdown ## Spec Compliance Matrix | Spec Domain | Requirement | Scenario | Status | Evidence | |-------------|--------------------|-----------------|------------|------------------------------------------------| | [domain] | [requirement name] | [scenario name] | COMPLIANT | [evidence desc