Repository navigation
[Proposal] /opsx:validate command to check code against the living specs #880
Description
The OpenSpec codebase currently has /opsx:verify command that can be used to check implementation against change artifacts (the ones in openspec/changes/<name>/).
However, there's no equivalent for validating the current implementation against the main specs in openspec/specs/. This seems like a gap; why keep 'source of truth' specs when the toolset doesn't provide tools to make direct use of them?
As an example. The 'Contributing' section of the 'README.md' in this repo says for example "Small fixes — Bug fixes, typo corrections, and minor improvements can be submitted directly as PRs." - it seems probable that in any project there will be small changes and adjustments where raising an openspec change is overkill. In that case it would be the living spec where any change could be directly documented (would be on the developers then to decide how or if they want to document the deviation from the archived changes)
This suggestion is for a command like /opsx:validate <spec-name> so users would have both tools:
/opsx:verifyfor checking changes/opxs:validatefor checking current specs
Given that the main spec does not have design or tasks, this command would check correctness only, not completeness or coherence, so would be a less detailed report than/opsx:verify.
Activity
gareth-robinson commentedon Apr 2, 2026
The Contributing section of the README.md says to make a proposal before implementation: but if it helps illustrate the idea I have a change here: main...gareth-robinson:OpenSpec:main
TabishB commentedon Apr 7, 2026
@gareth-robinson When and how often do you validate code against existing specs? (trying to figure out frequency of use here)
I'm not opposed to this, it can most likely end up as an optional skill. Just unsure how often people would use it. I think ideally its the kind of thing that would need some automation behind it to be useful. e.g running it in CI every 5 commits to see if the new code introduced any drift etc? WDYT?
gareth-robinson commentedon Apr 13, 2026
Hi @TabishB - its a hypothetical; I think that there may always be small dev changes to a project where writing a new change spec might seem like overkill; say someone wants to change the default pagination size in some API from 10 items to 20 items, then that might just be altering a constant and a unit test in some code, and updating the main spec to say the default is now 20. The 'philosophy' section of the README.md also mentions brownfield as well as greenfield development, so while adoption is underway there could still be development outside of OpenSpec and
validatewould then be like a regression test to make sure other changes haven't affected the bits that the specs are meant to cover.Perhaps it does have only limited use cases. I guess you could make a counterargument that if it's overkill to use a change spec for everything then maybe its also overkill for OpenSpec to provide skills outside of that flow? i.e. do we consider main specs as an editable entity on their own outside of the OpenSpec flow?
docs(openspec): pin data contracts + digest forward-compat; delineate F…
feat(skills): propose /opsx:update planning-artifact update skill (Fi…
合并英文上游 v1.6.0-beta.1 + 双语解析保住 + 增量汉化 (#5)