CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

spec-driven-dev

Spec-driven dev workflow. Invoke before implementing any feature or fixing any bug — spec lookup, clarifications, plan approval.

Quality

70%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Critical

Do not install without reviewing

Fix and improve this skill with Tessl

tessl review fix ./skills/spec-driven-dev/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body delivers a genuinely actionable, well-sequenced workflow with concrete paths, formats, and approval gates — strong for an instruction-only skill. Its main weaknesses are the off-topic promotional footer that wastes context and the undefined MISMATCH recovery path, which keep conciseness and workflow clarity below the top anchors.

Suggestions

Remove the "About this skill" promotional footer (or relocate it out of SKILL.md) — it consumes tokens with no operational value.

Add a MISMATCH recovery step, e.g. "If MISMATCH: document the discrepancy, fix the code or update the spec, and re-verify before staging".

Replace placeholder questions ("What should happen when X?") with one concrete worked example per question group.

DimensionReasoningScore

Conciseness

The workflow steps are tight ("If ANY box is unchecked, ask clarifying questions before proceeding"), but the trailing "About this skill" section ("Want this skill (and 40+ more) running on autopilot against your live ad accounts? Try Synter...") is roughly 8 lines of pure promotional padding unrelated to execution — more than the 'minor' trimmable excess of a 4.

3 / 5

Actionability

Concrete guidance throughout: exact paths ("docs/specs/history/prs/YYYY-MM/PR-<number>.md"), a defined entry format ("BHV-AREA-NNN" with area codes), explicit status transitions ("UNVERIFIED → MATCH or MISMATCH"), and a literal script for the "just do it" case. Not a 5 because clarifying-question examples are placeholders ("What should happen when X?") and the spec template contents are never shown.

4 / 5

Workflow Clarity

Clear 7-step sequence with real checkpoints: the ambiguity checklist, "Wait for explicit approval before writing code", and the Step 7 verification loop (UNVERIFIED → MATCH or MISMATCH) with test evidence. Not a 5 because the error-recovery loop is incomplete — nothing instructs what to do when an entry lands on MISMATCH.

4 / 5

Progressive Disclosure

Sections are well-organized by step and every referenced path (templates, diagrams, ledger) is one level deep with no nesting; no bundle files exist, so this is scored on structure alone. Not a 5: the 8-item inline diagram catalog and the promotional footer are content that is not optimally placed, and at ~90 lines the under-50-line simple-skill exception does not apply.

4 / 5

Total

15

/

20

Passed

Description

58%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description has a clear domain and an explicit, natural trigger clause, but the capability list is compressed and omits several workflow stages. Trigger coverage relies on only two phrasings (feature/bug) and misses common variations, and the broad trigger creates overlap risk with general dev-workflow skills.

Suggestions

Expand the capability list with concrete verb phrases, e.g. "Looks up existing specs, asks clarifying questions, records behavior changes, and secures plan approval before any code is written".

Broaden trigger coverage with natural variations: "Use when implementing or building a feature, fixing a bug, or making any code change".

Narrow the trigger slightly (e.g. tie it to repos with a docs/specs/ directory) to reduce conflict risk with general coding skills.

DimensionReasoningScore

Specificity

"Spec-driven dev workflow" names the domain and "spec lookup, clarifications, plan approval" lists three actions, but they are compressed nominal phrases rather than concrete verb-object descriptions, and major workflow stages (behavior-change definitions, architecture diagram checks, spec status updates) are unmentioned — gaps beyond the 'minor' level of a 4.

3 / 5

Completeness

Both parts are present: the 'what' ("Spec-driven dev workflow... spec lookup, clarifications, plan approval") and an explicit trigger clause ("Invoke before implementing any feature or fixing any bug"), so the missing-'Use when' cap at 3 does not apply. Not a 5 because the 'what' is a terse label plus compressed nouns rather than a fully concrete capability statement.

4 / 5

Trigger Term Quality

"implementing any feature or fixing any bug" uses natural phrases users would say, but common variations like "build", "add", "create", "refactor", or "make a change" are absent — more than the 'a few natural terms missing' of a 4.

3 / 5

Distinctiveness Conflict Risk

"Spec-driven dev workflow" is a distinct niche concept, but the trigger "before implementing any feature or fixing any bug" applies to virtually all development work, creating overlap risk with general coding and planning skills — fits 'somewhat specific but could still overlap'.

3 / 5

Total

13

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

Synter-Media-AI/free-skills

Path

skills/spec-driven-dev/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.