Source-Driven Development
Ground framework and library decisions in current official documentation instead of stale memory.
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.
- 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.
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.
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 do you install this skill?
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.
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.