# Source Driven

> Implement features from official docs for the exact installed dependency versions, not training d…

Implement features from official docs for the exact installed dependency versions, not training data. Use when asked to "check the docs", "use official docs", "source-driven", or with unfamiliar APIs/libraries. Don't use for well-known stdlib APIs or project-internal code.

- Page: https://ss33.ai/skills/helderberto/source-driven-36753954705
- Publisher: helderberto
- Category: [Software Development](https://ss33.ai/skills/category/software-development-t44z8z) › [Developer docs & tooling](https://ss33.ai/skills/category/software-development-t44z8z/developer-docs-and-tooling-nich6w)
- License: MIT
- Source: https://github.com/helderberto/agent-skills/blob/445681fd215e649201f91d65492025f0803efc0a/skills/source-driven/SKILL.md

## Skill

SKILL.md: https://ss33.ai/api/v1/ss33/download/helderberto/source-driven-36753954705

# Source-Driven Development

Never rely on training data for API usage. Read the source of truth for the **installed version**.

1. **Pin versions** — read the project manifest/lockfile for the exact version of each library involved.
2. **Fetch docs for that version** (not "latest") with WebFetch. Extract signatures, required params, return types, breaking changes. Docs missing or ambiguous → the repo README for that tag, then the installed package source (`node_modules/`, site-packages, vendor, …) and its type definitions.
3. **Implement only confirmed APIs**, matching signatures exactly. Anything you cannot verify gets marked inline: `// UNVERIFIED: could not confirm in docs for v{version}` (or `docs for v{closest}, installed v{actual}`).
4. **Cite** surprising or version-specific usage with a one-line `// Ref: <url>`. Don't comment obvious calls.
