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 writer artifact path provided by the runner and the instructions in this file. Do not rely on conversation memory, pipes or other provider output.
Judge the rewrite 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: judge, provider and input_digest. Carry forward the
current rewritten plan with the review so the next writer reads one 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