What does this skill do, and when should you use it?
Source-Driven Development is one standalone skill in the addyosmani/agent-skills repository, focused on version-sensitive framework and library work. It instructs an agent to identify dependency versions, retrieve the relevant official documentation, implement documented patterns, and cite the sources. It also requires explicit disclosure when a pattern cannot be verified and requires conflicts between documentation and existing code to be surfaced. It is a good fit for correctness-focused engineering work, but not for tasks where speed is explicitly more important than verification.
Instructs the agent to read dependency files such as package.json, composer.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml, and Gemfile; identify framework and library versions; fetch the specific official documentation for the feature being implemented; follow documented API signatures, recommendations, and migration guidance; provide full-URL citations for framework-specific decisions; flag unverified patterns; and report conflicts between official documentation and existing project code.
- A frontend developer building forms, routing, or data fetching against a specific React, Vue, Angular, or Svelte version needs to avoid outdated APIs.
- A backend developer implementing Django, Flask, Laravel, or Symfony behavior needs to confirm the current version's documented approach.
- A team creating starter code or reusable framework patterns wants each implementation decision to be traceable to an authoritative source.
- A maintainer reviewing framework-specific code needs to check deprecations and migration guidance before changing it.
- A user explicitly requests documented, verified, or current-best-practice implementation rather than code based on memory.
How do you install this skill?
- This assessment is source-only; the workflow, documentation fetching, or generated code was not executed or independently tested.
- Users should confirm dependency versions, access to cited official documentation, and alignment between documentation and the project version.
- Official citations do not prove that the resulting code works; project tests, compatibility checks, and security review remain necessary.
- Network access
- Local filesystem
Install this individual skill with the skills CLI:
npx skills add addyosmani/agent-skills --skill source-driven-development
The repository also supports installing the complete 24-skill collection:
npx skills add addyosmani/agent-skills
The README does not document a universal installation directory for this individual skill across every agent.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/addyosmani/agent-skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/source-driven-development" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Trigger it when implementing or reviewing version-sensitive framework or library code. Example prompt:
Use source-driven-development: inspect the project's dependency versions, find the official documentation for the relevant version and feature, implement the documented pattern, and cite every framework-specific decision with a full URL.
Do not use it for version-independent edits such as renaming variables or fixing typos, or when the user explicitly prioritizes speed over verification.
What are this skill's strengths and limitations?
- Requires dependency-version detection before implementation.
- Makes framework-specific decisions auditable through official full-URL citations.
- Explicitly addresses deprecations, migration guidance, documentation conflicts, and unverified patterns.
- Provides a clear DETECT, FETCH, IMPLEMENT, CITE workflow plus verification criteria.
- Depends on access to the project's dependency files and relevant official documentation.
- Does not include framework-specific documentation, test scripts, or automation tooling.
- Adds documentation lookup and citation overhead to implementation work.
- Is intentionally unsuitable when the user explicitly values speed over verification or when version-specific correctness is irrelevant.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Source-Driven Development this page | 51 · Use with care | ★ 107k | 13d ago | MIT |
| Effect JSDoc Authoring Skill | 77 · Strongly recommended | ★ 28k | 12d ago | MIT |
| OpenAI Developer Docs Assistant ✓ OpenAI · Official | 55 · Use with care | ★ 28k | 4mo ago | — |
| step.parts Catalog Skill | 55 · Use with care | ★ 20k | 15d ago | MIT |
| NVIDIA DOCA Public Knowledge Map ✓ NVIDIA · Official | 54 · Use with care | ★ 3.6k | 12d ago | Apache-2.0 |
How did FollowSkills review this skill?
The skill requires official documentation, explicit version detection, and visible citations; it also asks the user to choose when documentation conflicts with existing code. It does not specify sensitive-data handling, permission boundaries, external-request data flows, rollback, or dependency security, so points are deducted.
The DETECT→FETCH→IMPLEMENT→CITE workflow is internally coherent and addresses missing versions, documentation conflicts, and unverifiable patterns. It provides no executable scripts, abnormal-input tests, or detailed failure feedback, and static review cannot reproduce key paths, so the score is limited to 8.
Trigger and non-trigger scenarios are reasonably clear for framework-specific implementation, review, and version-sensitive correctness. The scope is broad, with no explicit Chinese-language or mainland-China reachability guidance; the core workflow depends on online official documentation, so points are deducted.
The skill has clear overview, trigger, process, rationalization, red-flag, and verification sections; repository context supplies MIT licensing, named maintainers, and CI. The skill itself lacks versioning, changelog, installation notes, explicit maintenance ownership, and troubleshooting guidance, so points are deducted.
For tasks requiring current framework patterns and auditable citations, the workflow can improve transparency and reduce obsolete API usage. There are no representative outputs, runtime verification, or comparative cost-benefit evidence, and results still require user review; under static calibration it receives 6.
The skill defines an official-source hierarchy, deep-link citation rules, and explicit unverified notices, providing some auditability. The supplied CI validates repository structure and general evaluations but does not demonstrate coverage of this skill's key paths or independent corroboration, so points are deducted.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →