Hi, my team and I have adopted OpenSpec as our standard development workflow — it's been instrumental in helping us
ship reliable code faster.
As we've scaled our usage, one area where we still spend significant time is code review and verification. The specs
already capture what the system should do in a structured, reviewable way, which feels like a natural foundation for
generating tests too — if we can extract requirements from specs and expand them into test scenarios before coding
begins, verification becomes largely automated and traceable back to the spec.
The idea is that this would be an entirely optional step in the workflow:
propose → [test-plan → review → test-write → review] → apply → archive
Developers who don't need it skip it — zero behavior change. For those who want it, the specs they've already written
become the source of truth for both implementation and verification, reducing the manual review burden.
Rough concept
- A planning step that reads specs, extracts requirements (RFC 2119 keywords, Given/When/Then), expands scenarios
across multiple test dimensions, and produces a reviewable plan with traceable scenario IDs
- A writing step that turns the approved plan into executable test files in the project's test directory, tagged with
those IDs for traceability
- Optionally, apply could track test progress during implementation when a test plan exists
The scenario IDs would trace across plan → test code → traceability report, so reviewers can verify coverage at a
glance.
Questions
I saw the discussion in #557 about keeping OpenSpec lightweight by default while making it configurable for power
users through the schema system. Would something like this be better suited as:
- Built-in optional workflows (in
ALL_WORKFLOWS, not CORE_WORKFLOWS)?
- A custom schema extension?
- Something else?
I'm currently working on adding these optional steps for our own use. I'd love to know if this is a direction you're
interested in expanding toward — happy to share my current draft as a starting point for discussion.
And if this isn't something you'd consider adding, I'd genuinely appreciate hearing your concerns or the
decision behind not going in this direction — it would help me spot blind spots in my own thinking. Also curious
about where you see the customization surface heading — are there plans to extend schema customization further (e.g.,
beyond artifacts and instructions), or is the current scope roughly where it'll stay?
Thanks!
Hi, my team and I have adopted OpenSpec as our standard development workflow — it's been instrumental in helping us
ship reliable code faster.
As we've scaled our usage, one area where we still spend significant time is code review and verification. The specs
already capture what the system should do in a structured, reviewable way, which feels like a natural foundation for
generating tests too — if we can extract requirements from specs and expand them into test scenarios before coding
begins, verification becomes largely automated and traceable back to the spec.
The idea is that this would be an entirely optional step in the workflow:
propose → [test-plan → review → test-write → review] → apply → archive
Developers who don't need it skip it — zero behavior change. For those who want it, the specs they've already written
become the source of truth for both implementation and verification, reducing the manual review burden.
Rough concept
across multiple test dimensions, and produces a reviewable plan with traceable scenario IDs
those IDs for traceability
The scenario IDs would trace across plan → test code → traceability report, so reviewers can verify coverage at a
glance.
Questions
I saw the discussion in #557 about keeping OpenSpec lightweight by default while making it configurable for power
users through the schema system. Would something like this be better suited as:
ALL_WORKFLOWS, notCORE_WORKFLOWS)?I'm currently working on adding these optional steps for our own use. I'd love to know if this is a direction you're
interested in expanding toward — happy to share my current draft as a starting point for discussion.
And if this isn't something you'd consider adding, I'd genuinely appreciate hearing your concerns or the
decision behind not going in this direction — it would help me spot blind spots in my own thinking. Also curious
about where you see the customization surface heading — are there plans to extend schema customization further (e.g.,
beyond artifacts and instructions), or is the current scope roughly where it'll stay?
Thanks!