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
Use it before marking spec-driven work complete or deploying, when an executable spec.yml is the contract of record.
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
SafeThe 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.
- •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
Examples
/verify-spec docs/specs/checkout-retry/spec.yml --phase greenVerify docs/specs/user-export/spec.yml against the implementation and tell me which acceptance criteria lack green test evidence before I deploy.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:
- The provided
docs/specs/<slug>/spec.yml - The
implementation_planandtaskssections inside that spec docs/contributing/guides/spec-driven-development.md- 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, andverification_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_beforeisimplementationis 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 filesThis 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.mdFrom 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 installationopenskills 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 syncManual 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.
ClickHouse Performance Comparison
Testing
Evaluate ClickHouse performance test results, check PR performance changes, compare with history, and assess whether a result is actionable.
Analyze CI Performance Reports
Testing
Analyze CI performance comparison reports for a ClickHouse PR. Cross-references master history to distinguish real regressions from flaky tests.
Santa Method
Testing
Multi-agent adversarial verification with two independent reviewers. Output is checked twice and iteratively fixed until both pass before shipping.