CtrlK
BlogDocsLog inGet started
Tessl Logo

source-driven-development

Grounds every implementation decision in official documentation. Use when you want to verify an approach against the official docs before implementing it, or when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters.

65

Quality

78%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/source-driven-development/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

81%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.

A strong instructional skill: the workflow is unambiguous, heavily templated, and includes explicit validation and a verification checklist, plus sensible prompt-injection hygiene for fetched docs. The main cost is length — motivational prose, a diagram, and a rationalizations table spend tokens re-arguing the skill's premise rather than instructing, and some of that material belongs in a separate reference file.

Suggestions

Cut the motivational framing (the Overview's staleness narrative, "Honesty about what you couldn't verify is more valuable than false confidence") and the ASCII pipeline diagram — Claude needs the directives, not the rationale for them, which would lift conciseness to the 4-5 anchors.

Move the 'Common Rationalizations' table into a short reference file (e.g. references/rationalizations.md) and keep a one-line pointer in SKILL.md, improving both conciseness and progressive disclosure.

Fold the 'Red Flags' list into the closing verification checklist to remove the duplication between the two sections (several items appear in both).

DimensionReasoningScore

Conciseness

Mostly efficient process guidance, but it includes padding Claude does not need: motivational framing ("Training data goes stale, APIs get deprecated, best practices evolve", "Honesty about what you couldn't verify is more valuable than false confidence"), the ASCII pipeline diagram, and a six-row rationalizations table that re-argues the skill's premise. This fits 'mostly efficient but includes some unnecessary explanation or could be tightened' rather than the minor-trimmings-only 4 anchor.

3 / 5

Actionability

Guidance is fully concrete and copy-paste ready: a dependency-file→stack mapping table, a prioritized source hierarchy, BAD/GOOD fetch examples, ready-made output templates ("STACK DETECTED:", "CONFLICT DETECTED:", "UNVERIFIED:"), an in-code citation example with a real URL format, and explicit citation rules. Per the rubric's code-vs-instruction note, the absence of executable code is not penalized because the directive guidance covers the common cases, matching the 5 anchor.

5 / 5

Workflow Clarity

The four-step process (Detect → Fetch → Implement → Cite) is clearly sequenced with explicit checkpoints: ask the user when versions are ambiguous, surface doc/codebase conflicts with an options template, flag unverifiable patterns, ignore injected directives in fetched content, and a closing nine-item verification checklist. This matches the 5 anchor (clear sequence, explicit validation, feedback loops, checklist) rather than the 4 anchor, which allows minor validation gaps — none are evident.

5 / 5

Progressive Disclosure

The single-file skill has no bundle directories (references/, scripts/, assets/ are absent) and is well organized with clear, purposeful sections (When to Use / Not, four step sections, Red Flags, Verification checklist); the one cross-skill pointer to `security-and-hardening` is clearly signaled and is not a nested bundle reference. It sits above the 3 anchor (structure present but content that should be separate is inlined) but below the 5 anchor, since the Common Rationalizations table and extended examples are inline material that could be split into a reference file at this ~215-line length.

4 / 5

Total

17

/

20

Passed

Description

75%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.

A well-formed description with an explicit what and multiple concrete 'Use when' triggers in appropriate third-person voice. Its weaknesses are an abstract capability statement that never enumerates the specific actions performed, and an overly broad 'correctness matters' trigger that raises conflict risk with general coding skills.

Suggestions

Enumerate the concrete actions in the opening sentence (e.g. "Detects the project's stack and versions from dependency files, fetches the relevant official documentation pages, implements against documented patterns, and cites full source URLs") so specificity reaches comprehensive coverage.

Replace or qualify the broad trigger "any framework or library where correctness matters" with narrower phrasing tied to the skill's actual use cases (e.g. "when writing framework-specific code from memory" or "when the user asks for verified, documented, or current best-practice implementations").

Add common synonym phrasing users would naturally say, such as "best practices", "up to date", or "check the docs first", to broaden natural trigger coverage.

DimensionReasoningScore

Specificity

"Grounds every implementation decision in official documentation" and "authoritative, source-cited code free from outdated patterns" name the domain and 1-2 concrete actions (verify against docs, cite sources), matching the anchor for domain-plus-limited-actions. It does not list several distinct concrete operations the way the score-4/5 anchors require (e.g. extract, fill, merge), so it stays at 3.

3 / 5

Completeness

The 'what' is explicit ("Grounds every implementation decision in official documentation") and the 'when' is given twice with concrete triggers ("Use when you want to verify an approach against the official docs before implementing it", "Use when building with any framework or library where correctness matters"), matching the anchor that clearly and explicitly answers both with concrete trigger phrases. It is not the 4 anchor, where the 'when' is present but only generically stated.

5 / 5

Trigger Term Quality

Natural phrases users would say are present — "verify an approach against the official docs", "source-cited code", "outdated patterns", "framework or library", "correctness" — giving good keyword coverage. A few common variations are missing (e.g. "best practices", "up to date", "check the docs"), which keeps it below the comprehensive-synonym coverage of the 5 anchor.

4 / 5

Distinctiveness Conflict Risk

The core behavior (doc verification with citations) is a recognizable niche, but the trigger "any framework or library where correctness matters" is broad enough that most coding tasks could match it, creating overlap risk with general coding and review skills. This fits 'somewhat specific but could still overlap with similar skills' rather than the 'mostly distinct' 4 anchor, whose scope is tightly bounded.

3 / 5

Total

15

/

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
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.