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.
73
92%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
#!/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
elif ! find openspec/specs -mindepth 1 -name 'spec.md' -print -quit 2>/dev/null | grep -q .; then
echo "No test runner detected, but no specs exist yet either — this is a fresh bootstrap, not a failure."
echo "Baseline: spec checks passed, test suite SKIPPED (no specs/tests yet)."
else
echo "No test runner detected. Run your test suite manually."
exit 1
fi.tessl-plugin
skills
handoff
handoff-skill
openspec-apply-change
openspec-archive-change
openspec-explore
openspec-propose
openspec-sync-specs
prompt-loop
requirement-gathering
spec-as-source-setup
templates
openspec-schema
spec-as-source
templates
spec-ci-sync
spec-loop
spec-rebuild
spec-verify
spec-writer
work-review