A read-only checker for an OpenSpec change, where an OpenSpec change is a set of documents describing planned software work. It validates those documents, runs the repository's verification command, and compares the implemented behavior with each described scenario.

Use it before archiving a change to confirm that its specification is valid, the project's checks pass, and the implementation matches the promised scenarios.

It separates document validity, automated checks, and actual behavior instead of treating one successful command as proof that the change is complete. It reports problems without fixing them.

spec-verify — Skill for Claude Code and Codex by pivoshenko

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Any agent

npx skills add pivoshenko/pivoshenko.ai --skill spec-verify

Clone the repo

git clone --depth 1 https://github.com/pivoshenko/pivoshenko.ai

Made for: Claude Code, Codex.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

README.md

[![agentmods](https://agentmods.dev/badge/skills/pivoshenko/pivoshenko.ai/spec-verify/github.svg)](https://agentmods.dev/skills/pivoshenko/pivoshenko.ai/spec-verify)

Your own site

<a href="https://agentmods.dev/skills/pivoshenko/pivoshenko.ai/spec-verify"><img src="https://agentmods.dev/badge/skills/pivoshenko/pivoshenko.ai/spec-verify/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

Your own site · 80×15

<a href="https://agentmods.dev/skills/pivoshenko/pivoshenko.ai/spec-verify"><img src="https://agentmods.dev/badge/skills/pivoshenko/pivoshenko.ai/spec-verify.svg" alt="Reviewed on agentmods" width="80" height="20"></a>

Per session 182 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.

When invoked 1,910 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.

Origin original No closer match found in the catalogue.

Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

Model	Per session	Once invoked
Fable 5.1	$0.00182	$0.01910
Opus 5.5	$0.00073	$0.00764
Sonnet 5.5	$0.00036	$0.00382
Haiku 4.5	$0.00018	$0.00191

Measured 1mo ago against content hash fd22390f0f89, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

spec-verify scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

skills/spec-verify/SKILL.md · 123 lines

How it starts

The opening of the file, as written. The whole thing — 123 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Spec Verify

change -> validate -> gate -> scenario conformance -> report.

Three independent checks, reported separately, in increasing order of what they prove. openspec validate reads documents. The repo gate runs the code. Scenario conformance is the only one that asks whether the behavior the spec promised exists, and it is the reason this skill is in the set. Never collapse them into one verdict.

Read-only by default. This skill fixes nothing. Why -> a verifier that quietly patches what it finds stops being independent evidence and starts being a second author of the same claim.

Preflight

openspec context --json

no_openspec_root -> stop, offer openspec init --tools claude, wait. Never auto-init, never fall back to the current directory. Use the returned root.path. The user naming a store -> openspec store list --json for ids, then --store <id> on every command below, sticky for the run.

.claude/commands/opsx/verify.md present -> the OpenSpec-side mechanics are its job; invoke it and own only the conformance and gate halves. Absent, which is the usual case -> run the flow below off the CLI directly. Mention the opt-in exactly once, as an offer:

openspec config set profile custom
openspec config set workflows '["propose","explore","apply","update","sync","archive","verify"]'
openspec init --tools claude

Accepted or declined, do not raise it again in this run, and never run it unasked. Why -> the profile is global state shared by every repo on the machine, so this is a machine-wide flip made to satisfy one change in one repo.

Flow

Resolve the change and read its shape:
```
openspec status --change "<name>" --json
```
Keep changeRoot and artifactPaths. Treat every status field as file-existence only - it says an artifact was written, never that it is right. isComplete is the sharpest example: it goes true once all four artifact files exist, so a change with 1 of 3 tasks ticked still reports isComplete: true. Task progress comes from openspec instructions apply --change "<name>" --json instead
Artifact validity. openspec validate <change> --strict --json -> parse items[].issues[], report each with its id and type. This checks the spec documents are well-formed and nothing more. A clean run is not evidence about the code
The repo gate. Find the project's own verify command by reading the justfile or the package scripts - just check here, a test suite elsewhere. Never invent one; nothing found -> ask. Then run it yourself as a shell command. Why -> this is the only check in the set that executes the code; the other two only read documents, and a worker's "tests pass" is a claim, not a result
Scenario conformance. Walk the delta as in Scenarios
Tick audit. Walk tasks.md the other way, as in Ticks
Report as in Report, then hand back as in Handback. Stop. Change nothing

Read the full file on GitHub · 123 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

1mo ago First seen · 123 lines · 182 tokens per session scan A fd22390f0f89

Subscribe to this mod's changes

spec-verify is a skill published in the GitHub repository pivoshenko/pivoshenko.ai (6 stars, last pushed today), licensed MIT. It adds 182 tokens to every session and 1,910 once invoked, about $0.0007 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-16.

OpenSpec Planning Testing agents ai ai-agents ai-skills mcp skills spec verification

comet-verify

A workflow for verifying a Comet change after its coding tasks are complete. Comet is a tool that tracks structured software changes through stages.

rpamis/comet · 30 tokens

story-origin-check

Recover the first public timestamp and canonical major coverage for a newsjacking signal, then decide whether newer coverage is the same story, a different story, or a materially new development.

elvisun/newsjack · 40 tokens

prompt-proximity-architecture

Turn an approved measurement charter, ICPs, and buyer jobs into a budget-aware prompt coverage blueprint across proximity bands, aided status, information acts, journey states, roles, locales, evidence grades, partitions, and measurement lanes. Use before prompt wording to define required, optional, and prohibited…

elvisun/newsjack · 67 tokens

coverage-tracker-setup

Set up a lightweight Google Alerts-style coverage tracker for any number of keywords. Creates a tracker config with each keyword and what it actually means, then hands recurrence to the user's agent harness.

elvisun/newsjack · 43 tokens

realistic-prompt-generation

Generate natural, controlled prompt variants from a target-blind design brief and prompt architecture while preserving approved jobs, acts, journeys, constraints, roles, locales, proximity bands, and evidence language. Use after architecture design and before contamination or semantic QA.

elvisun/newsjack · 55 tokens

reactive-comment

Triage inbound journalist source queries and draft a response only when the user's expertise is a real fit. Runs each query through proven source-request lenses (4-gate fit triage, credential-standing test, deadline read, BLUF/inverted-pyramid drafting), kills weak fits, asks for missing proof, and never auto-sends.

elvisun/newsjack · 70 tokens