spec-driven-devlopment/spec-as-source
Spec-driven development on OpenSpec, with mechanical spec-as-source enforcement: a custom 'spec-as-source' OpenSpec schema adds file-ownership (targets) and test-verification ([@test]) metadata to every capability spec, three scripts (link check, ownership check, manifest build) keep code and specs from drifting apart, plus requirement-gathering, spec-writer, work-review, and a session-handoff skill with a proactive context-warning hook.
71
89%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
generated-file-header.mdrules/
generated-file-header
Every file listed in the targets: field of an OpenSpec capability spec (openspec/specs/<capability>/spec.md) must begin with this header:
For Python files:
# GENERATED FROM SPEC — DO NOT EDIT DIRECTLY
# Source: openspec/specs/<capability>/spec.mdFor JavaScript/TypeScript files:
// GENERATED FROM SPEC — DO NOT EDIT DIRECTLY
// Source: openspec/specs/<capability>/spec.mdFor other file types, use the appropriate comment syntax.
Add the header as the very first line(s) of the file (after shebang or doctype if present) before writing any other content. Replace <capability> with the actual capability directory name (the parent folder of the spec.md that declares this file as a target).
.tessl-plugin
skills
handoff
openspec-apply-change
openspec-archive-change
openspec-explore
openspec-propose
openspec-sync-specs
requirement-gathering
spec-as-source-setup
templates
openspec-schema
spec-as-source
templates
spec-ci-sync
spec-rebuild
spec-verify
spec-writer
work-review