Spec Verification

VerifiedSafe

Check implemented work against executable spec.yml by validating acceptance criteria coverage and test evidence.

Sby Skills Guide Bot
TestingIntermediate
7/25/2026
Claude CodeCursorCodex
#spec-driven#acceptance-criteria#verification#traceability#quality-gate

Recommended for

Automated summary

Checks implemented work against an executable spec.yml by validating acceptance-criteria coverage and red/green test evidence.

Strengths

  • Produces a criterion-by-criterion coverage table with status, evidence, and risk level
  • Explicitly separates covered, ambiguous, uncovered, blocked, and waived instead of accepting intent as proof
  • Also gates required assumptions, open questions, and privacy/security criteria
  • Blocks deployment on failure and requires a linked follow-up task or a documented waiver

Limitations

  • Relies on repo-specific scripts (spec_validate.py, spec_verify.py, sessions.py) that must exist and be wired up
  • Does not replace running the tests; it confirms evidence consistency, not the validity of the tests themselves
  • Playwright evidence validation assumes a dev deployment and Vercel Ready state, which is specific to this repository
When to use it

Use it before marking spec-driven work complete or deploying, when an executable spec.yml is the contract of record.

When not to use it

Avoid it as the sole quality gate on projects without a spec.yml and the supporting verification scripts, or when no formal acceptance criteria exist.

Security analysis

Safe
Quality score83/100

The skill is a read-only conformance/verification workflow. It only reads spec.yml, product docs, and runs local python validation scripts, then emits a Markdown report. There are no destructive commands, no curl|sh piping, no base64 payloads, no secret/token exfiltration, and it explicitly refuses to mark work complete or deploy on failure. The only mild concern is unvetted execution of repo-local scripts, which is normal for a repo-internal QA skill.

Findings
  • •Runs repository-local helper scripts (scripts/sessions.py, spec_validate.py, spec_verify.py) via bash without inspecting their contents; benign in intent (read-only validation) but trusts repo scripts implicitly
  • •References a specific deployment target (app.dev.openmates.org) and dev deployment state as a gate condition; informational only, no credentials or tokens handled
How this analysis is made

Examples

Green phase check before deploy
/verify-spec docs/specs/checkout-retry/spec.yml --phase green
Full completion audit
Verify docs/specs/user-export/spec.yml against the implementation and tell me which acceptance criteria lack green test evidence before I deploy.
Document-only review
There's no active session — do a document-only review of docs/specs/billing-webhook/spec.yml and report coverage gaps for each acceptance criterion.

name: verify-spec description: Check implemented work against executable spec.yml before completion or deploy by validating acceptance criteria coverage and red/green test evidence user-invocable: true argument-hint: "docs/specs/<slug>/spec.yml [--phase red|green|complete]"

Instructions

You are performing a conformance check for spec-driven work. This is not a replacement for tests; it confirms that tests and implementation evidence match the executable spec.yml.

Step 1: Read Inputs

Read:

  1. The provided docs/specs/<slug>/spec.yml
  2. The implementation_plan and tasks sections inside that spec
  3. docs/contributing/guides/spec-driven-development.md
  4. Current session status and related test tracking:
    python3 scripts/sessions.py status --json
    python3 scripts/sessions.py check-tests --session <SESSION_ID>
    

If there is no active session, ask for the session ID or perform a document-only review.

Step 2: Build The Coverage Table

First run:

python3 scripts/spec_validate.py docs/specs/<slug>/spec.yml
python3 scripts/spec_verify.py docs/specs/<slug>/spec.yml --phase complete

For every scenario and acceptance criterion, record:

  • Implemented: yes/no/partial/unknown
  • Coverage: covered/ambiguous/uncovered/blocked/waived based on coverage_status, linked tests, and verification_ids
  • Evidence: test file, command, manual verification, code reference, or gap
  • Risk: none/low/medium/high

Step 3: Validate Required Evidence

Pass only when:

  • Every completed acceptance criterion has green evidence.
  • Every required acceptance criterion is covered, waived, or blocked by an accepted user/external dependency; ambiguous and uncovered criteria fail.
  • Every required assumption whose required_before is implementation is confirmed, corrected and applied, waived, or externally blocked.
  • required assumptions with unchecked, checking, or contradicted status fail the implementation gate unless the user accepts a waiver or external blocker.
  • Every required red phase has evidence before implementation. Red evidence may be failed as expected, passed unexpectedly with a reason, missing-test with a reason, skipped with a reason, or not applicable.
  • Every required green/final check has passing, user-confirmed, waived, or accepted-blocker evidence.
  • Privacy/security criteria have concrete code or test evidence.
  • Changed source files have related tests or an explicit skip reason.
  • Open questions are resolved or listed as accepted residual risk.

Failed required checks must not be treated as a summary-only issue. The report must identify the affected acceptance criteria and confirm that follow-up tasks exist or that the user explicitly accepted a waiver/blocker. failed required checks keep the spec active until the linked follow-up work is done or the user accepts a waiver/blocker.

Playwright green evidence is only valid after the implementation has been deployed to dev, Vercel is Ready, and the spec has run against app.dev.openmates.org.

Step 4: Output Report

Use this format:

## Spec Verification

Spec: docs/specs/<slug>/spec.yml
Status: pass | fail | partial

| ID | Status | Evidence | Risk |
| --- | --- | --- | --- |
| S-1 | pass | `frontend/...spec.ts` | none |
| AC-1 | pass | `python3 scripts/tests.py run ...` | none |

Gaps:
- <gap or none>

Deploy note:
- Spec: docs/specs/<slug>/spec.yml
- Tests: <commands/results>
- Residual risk: <none or concise note>

Step 5: Stop On Failure

If status is fail, do not deploy. Fix the gap, update the spec if product intent changed, or ask the user to accept a documented risk.

Rules

  • Do not mark criteria complete based on intent alone.
  • Do not weaken or remove acceptance criteria to make verification pass.
  • Do not mark ambiguous coverage as complete; normalize vague criteria into concrete checks first.
  • Prefer Playwright/pytest/vitest via repo-approved test commands over manual browser checks.
  • Manual verification is allowed only when automation is impractical and the reason is documented.
  • Do not mark a full spec verified while required green evidence is missing.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/spec-verification-mrzxuqlp/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/spec-verification-mrzxuqlp' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/spec-verification-mrzxuqlp/download' --output '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md.part' && mv '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md.part' '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md' && test -s '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/verify-spec' && cp -R '.skill-downloads/spec-verification-mrzxuqlp' '.claude/skills/verify-spec'

Cursor
test -f '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md' && test -s '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/verify-spec' && cp -R '.skill-downloads/spec-verification-mrzxuqlp' '.cursor/skills/verify-spec'

Codex
test -f '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md' && test -s '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/verify-spec' && cp -R '.skill-downloads/spec-verification-mrzxuqlp' '.agents/skills/verify-spec'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/spec-verification-mrzxuqlp'

openskills read 'spec-verification-mrzxuqlp'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/spec-verification-mrzxuqlp/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills