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
verify.shskills/spec-as-source-setup/templates/
#!/usr/bin/env bash
set -euo pipefail
echo "=== Spec Verification ==="
echo ""
bash scripts/check-spec-links.sh
bash scripts/check-target-ownership.sh
python3 scripts/build-spec-manifest.py
echo ""
echo "Spec checks passed. Running test suite..."
echo ""
if [ -f "pytest.ini" ] || [ -f "pyproject.toml" ] || [ -f "setup.cfg" ]; then
pytest tests/ -v
elif [ -f "package.json" ] && grep -q '"test"' package.json; then
npm test
elif [ -f "Cargo.toml" ]; then
cargo test
else
echo "No test runner detected. Run your test suite manually."
exit 1
fi.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