CtrlK
BlogDocsLog inGet started
Tessl Logo

source-driven-development

Grounds every implementation decision in official documentation. Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters.

45

Quality

47%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Advisory

Suggest reviewing before use

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/source-driven-development/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

77%

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

This is a well-crafted skill with excellent actionability and workflow clarity. The four-step process is clearly defined with concrete examples, conflict handling, and a verification checklist. The main weakness is moderate verbosity — the 'Common Rationalizations' table and overlapping 'Red Flags' / 'When to Use' sections add bulk without proportional value, and the skill could be tightened by ~30% without losing clarity.

Suggestions

Remove or significantly condense the 'Common Rationalizations' table — Claude doesn't need to be persuaded why verification matters; it just needs the process.

Consolidate 'Red Flags' into the verification checklist (they're largely the inverse of each other) to reduce redundancy.

DimensionReasoningScore

Conciseness

The skill is well-written but includes some unnecessary verbosity. The 'Common Rationalizations' table, while useful, is somewhat preachy and explains things Claude already understands (e.g., why hallucinating is bad). The 'When to Use' / 'When NOT to use' sections and the 'Red Flags' section overlap significantly with each other and with the process steps. The ASCII diagram adds little value. However, the core process steps are reasonably efficient.

2 / 3

Actionability

The skill provides highly concrete, actionable guidance: specific dependency files to check, a clear source hierarchy table, exact examples of good vs bad fetch targets, specific citation formats with real URLs, and concrete conflict-resolution templates. The examples are realistic and copy-paste ready for real workflows.

3 / 3

Workflow Clarity

The four-step process (Detect → Fetch → Implement → Cite) is clearly sequenced with explicit validation checkpoints. Step 3 includes conflict detection and user escalation. Step 4 includes explicit handling of unverified patterns. The verification checklist at the end provides a comprehensive feedback loop. The workflow handles edge cases like version ambiguity, doc conflicts, and missing documentation.

3 / 3

Progressive Disclosure

The content is well-structured with clear headers and sections, but it's a monolithic document at ~200 lines with no references to supporting files. The Common Rationalizations table, Red Flags list, and detailed citation examples could be split into separate reference files to keep the main skill leaner. However, given no bundle files exist, the inline approach is the only option, and the sections are at least well-organized.

2 / 3

Total

10

/

12

Passed

Description

17%

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

This description suffers from vague, aspirational language and an extremely broad scope that would make it nearly impossible for Claude to distinguish from other coding-related skills. It reads more like marketing copy than a functional skill description, using buzzwords like 'authoritative' and 'source-cited' without specifying concrete actions or a clear niche.

Suggestions

Replace vague language with specific concrete actions, e.g., 'Looks up official documentation, validates API usage against current docs, checks for deprecated patterns, and cites documentation sources in code comments.'

Narrow the 'Use when...' clause to specific triggers, e.g., 'Use when the user asks to check documentation, verify API correctness, find the latest syntax for a library, or wants code that follows official best practices.'

Add natural trigger terms users would actually say, such as 'docs,' 'documentation,' 'API reference,' 'deprecated,' 'latest version,' 'official examples,' or 'best practices.'

DimensionReasoningScore

Specificity

The description uses vague, abstract language like 'grounds every implementation decision' and 'authoritative, source-cited code free from outdated patterns.' It does not list any concrete actions (e.g., 'looks up documentation,' 'validates API usage,' 'checks version compatibility'). The capabilities are described in buzzword-heavy, aspirational terms rather than specific operations.

1 / 3

Completeness

It has 'Use when...' clauses, which is good, but the 'what' is extremely vague ('grounds every implementation decision in official documentation') and the 'when' is overly broad ('building with any framework or library where correctness matters'). The triggers are so generic they apply to virtually any coding task, making them ineffective as selection criteria.

2 / 3

Trigger Term Quality

The description lacks natural keywords a user would actually say. Terms like 'authoritative,' 'source-cited,' and 'outdated patterns' are not phrases users naturally use when requesting help. It mentions 'framework or library' which are somewhat relevant but extremely generic. Missing terms like 'docs,' 'documentation lookup,' 'API reference,' or specific framework names.

1 / 3

Distinctiveness Conflict Risk

The description is extremely generic — 'building with any framework or library where correctness matters' could apply to nearly every coding skill. It would conflict with virtually any development-related skill since most coding tasks involve frameworks/libraries and correctness always matters.

1 / 3

Total

5

/

12

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.

Validation11 / 11 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.