CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

spec-driven-development

Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when drafting a PRD or requirements document with objectives and scope, or when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying.

78

1.70x
Quality

83%

Does it follow best practices?

Impact

94%

1.70x

2 of 3 eval scenarios. Add 1 more for a full score.

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

73%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 skill body delivers an exemplary gated workflow with explicit validation gates, stop conditions, and verification checklists, plus concrete copy-paste templates. Its main cost is token weight: duplicated precedence disclaimers and frontmatter-repeating sections could be trimmed, and some long inline material could be offloaded to reference files.

Suggestions

Consolidate the two near-duplicate "planning-and-task-breakdown is canonical / takes precedence" blockquotes (Phase 2 and Phase 3) into a single statement, saving a substantial block of repeated text.

Trim the "When to Use" bullet list, which restates the frontmatter description's trigger conditions almost verbatim — one of the two is redundant.

Consider moving the Phase 0 capability-map mechanics and worked example (roughly lines 34–65) into a short reference file, keeping only the detection heuristics inline to reduce the main body's token load.

DimensionReasoningScore

Conciseness

The body is mostly efficient and assumes Claude's competence (no basic-concept explanations), but contains real tightening opportunities: two near-duplicate "planning-and-task-breakdown takes precedence" blockquotes in Phase 2 and Phase 3, and a "When to Use" section that largely repeats the frontmatter triggers. This fits anchor 3 (could be tightened) better than anchor 4's "minor instances".

3 / 5

Actionability

Provides copy-paste-ready templates (spec, capability map, task), concrete command examples, and worked assumption/reframe examples, with only minor gaps — Phase 4 is name-only skill references and a few steps like "Identify the major components" remain high-level. Anchor 4 fits; not 5 because some guidance lacks the concrete depth of the fully-executable anchor.

4 / 5

Workflow Clarity

The four-phase gated workflow has explicit human-review checkpoints at every phase (the ASCII diagram plus "Do not advance to the next phase until the current one is validated"), a CRITICAL stop instruction, and a final verification checklist — matching the anchor-5 pattern of clear sequencing, explicit validation, and checklists.

5 / 5

Progressive Disclosure

A single-file skill with clear section structure and well-signaled one-level-deep cross-skill references (paths like `skills/incremental-implementation/SKILL.md`). At ~260 lines, some inline material (capability-map mechanics, the full spec template) could arguably move to reference files, which keeps it at anchor 4 rather than 5.

4 / 5

Total

16

/

20

Passed

Description

83%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 is strong: it clearly states what the skill does and provides multiple explicit, naturally-phrased trigger conditions. Its only weakness is slightly limited action variety and a few missing synonymous trigger phrases, which keep specificity and trigger coverage just below top marks.

DimensionReasoningScore

Specificity

Names several concrete actions — "Creates specs before coding", "drafting a PRD or requirements document with objectives and scope", "decomposing into a capability map of modules" — but coverage is narrower than the comprehensive anchor-5 example, so anchor 4 fits best.

4 / 5

Completeness

Explicitly answers both what ("Creates specs before coding") and when via three concrete "Use when…" clauses with specific trigger conditions, exactly matching the anchor-5 example pattern.

5 / 5

Trigger Term Quality

Contains natural phrases users would say ("new project", "feature", "requirements are unclear, ambiguous", "vague idea", "PRD") with good coverage, but a few natural variants like "write a spec" or "design doc" are missing, matching anchor 4 rather than 5.

4 / 5

Distinctiveness Conflict Risk

The spec-before-code gating niche is distinct with specific triggers like "no specification exists yet" and "drafting a PRD", but as a process skill it has minor overlap risk with adjacent planning and design skills, fitting anchor 4.

4 / 5

Total

17

/

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

addyosmani/agent-skills

Path

skills/spec-driven-development/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.