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.
68
85%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Your context is fresh. Read only the input artifact path provided by the runner and the instructions in this file. Do not rely on conversation memory, pipes or other provider output.
Rewrite the entire plan in Markdown using this shared rubric:
Write the result only to the output artifact path provided by the runner. Start
it with the required frontmatter values supplied by the runner: round,
giro, ruolo: writer, provider and input_digest. Preserve the plan as a
review artifact; do not edit openspec/PLAN.md, approve entries, calculate an
approval hash or advance a state.
.tessl-plugin
rules
skills
handoff
handoff-skill
openspec-apply-change
openspec-archive-change
openspec-explore
openspec-propose
openspec-sync-specs
plan-judge
plan-mode
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