| name | openspec-verify-change |
| description | Use when working with OpenSpec in Hermes: check implementation completeness, correctness, coherence, and evidence before archive. |
| version | 1.0.0 |
| author | TheSmuks + Hermes Agent |
| license | MIT |
| platforms | ["windows","macos","linux"] |
| metadata | {"hermes":{"category":"software-development","tags":["openspec","sdd","spec-driven-development","hermes"],"homepage":"https://github.com/Fission-AI/openspec"}} |
openspec-verify-change
Use this for OpenSpec's /opsx:verify workflow.
Hermes operating rules for OpenSpec
- Work from the user's project root. If unknown, inspect the current directory first.
- Ensure the OpenSpec CLI exists before using it:
openspec --version. If missing, install with npm install -g @fission-ai/openspec@latest.
- Initialize projects with
openspec init --tools none unless the user also wants other AI-tool integrations. Hermes uses these skills, not OpenSpec-generated slash commands.
- Prefer agent-compatible OpenSpec CLI calls with
--json where available: openspec list --json, openspec status --change <id> --json, openspec instructions <artifact> --change <id> --json, openspec validate --all --json.
- Read generated artifacts before editing or implementing. Do not invent OpenSpec state.
- Run validation after changing OpenSpec artifacts:
openspec validate <change> or openspec validate --all.
- Keep changes focused. If user scope diverges, update the existing change only when intent is the same; otherwise create a new change.
Procedure
- Identify the target change.
- Read all change artifacts and main specs touched by the change.
- Run
openspec validate <name>.
- Search the codebase for evidence for every task, requirement, and scenario.
- Run relevant tests or build commands.
- Report CRITICAL issues, WARNINGs, and SUGGESTIONs.
- State whether the change is ready to archive.
Verification dimensions: completeness, correctness, and coherence.