source-driven-development

Source-Driven Development

Do not implement framework-specific code from memory. Training data goes stale, APIs get deprecated, and confident-looking patterns break against current versions. Verify against official docs, cite the source, and flag anything you could not verify.

When It Applies

Always for: framework patterns (forms, routing, data fetching, state, auth), boilerplate that will be copied across a project, and any request for "correct" or "current" implementation. Skip it for version-independent work: renames, typo fixes, pure logic that behaves identically across versions, or when the user explicitly wants speed over verification.

The Process: Detect, Fetch, Implement, Cite

1. Detect stack and versions

Read the dependency file: package.json, pyproject.toml or requirements.txt, composer.json, go.mod, Cargo.toml, Gemfile. State what you found:

STACK DETECTED:
- React 19.1.0 (from package.json)
- Vite 6.2.0
Fetching official docs for the relevant patterns.

Versions missing or ambiguous: ask. The version determines which patterns are correct. Do not guess.

2. Fetch the specific doc page

Not the homepage, not the whole site: the page for the feature you are implementing. Source hierarchy, in order of authority: official documentation, official blog and changelog, web standards references (MDN, specs), compatibility tables (caniuse, node.green).

Never cite as primary sources: Stack Overflow, blog posts, tutorials, AI-generated summaries, or your own training data. Verifying training data is the entire point.

Note deprecation warnings and migration guidance while extracting patterns. If two official sources conflict, surface the discrepancy and verify which pattern works against the detected version.

3. Implement the documented pattern

Use API signatures from the docs, not memory. If the docs show a new way, use it. If the docs deprecate a pattern, do not ship it. If the docs do not cover something, flag it as unverified.

When docs conflict with existing project code, surface it, do not silently pick:

CONFLICT: codebase uses useState for form pending state;
React 19 docs recommend useActionState.
(Source: react.dev/reference/react/useActionState)
A) modern pattern  B) match codebase. Which do you prefer?

4. Cite

Every framework-specific decision gets a full URL, deep-linked with an anchor where possible (anchors survive doc restructuring better than top-level pages). Put citations in code comments for non-obvious choices and in conversation for decisions the user should sanity-check. Quote the passage when it supports a non-obvious call. When you cannot find documentation:

UNVERIFIED: no official documentation found for this pattern.
Based on training data, may be outdated. Verify before production.

Honest uncertainty beats false confidence. Hedged confidence ("this might be outdated") without either a citation or an UNVERIFIED flag is the worst option.

Verification

Before delivering, grep your own output: every framework-specific API used must appear in a fetched doc page or carry an UNVERIFIED flag. Run the project's type check or build (tsc --noEmit, npm run build, or equivalent). Expect a clean pass. A type error on a cited API means you misread the doc or the version: re-fetch and fix before delivering.

Then check the citation list: every URL fully qualified, resolving, and pointing at an official domain. A citation to a blog post or a dead link fails the review.

Good vs Bad

Bad: "I'm confident React handles this with useFormState." Written from memory, the hook was renamed, the signature changed, and the user burns an hour on a hallucinated API before finding the migration note you never read.

Good: Read package.json (React 19.1), fetch the useActionState reference page, implement its documented signature, comment the source URL, and note in conversation why the older pattern was not used.

Footguns

• Confident deprecated patterns. The most dangerous errors look correct because they were correct, two versions ago. Fix: check the migration guide for the detected version whenever a pattern predates it.
• Citing a page you did not fetch. Constructing a plausible docs URL from memory is a hallucinated citation. Fix: only cite pages actually fetched this session.
• Fetching the wrong version's docs. Docs default to latest; the project may be behind. Fix: match the docs version selector to the detected version.
• Boilerplate contamination. One unverified pattern in a starter file gets copied into ten components. Fix: verification effort scales with how much the code will be copied.

Red Flags: Stop and Fetch

• "I'm confident about this API."
• "Fetching docs wastes tokens."
• "The docs won't have what I need."
• "I'll just mention it might be outdated."
• "This is a simple task, no need to check."
• Writing "I believe" or "I think" about an API instead of a citation.

Each phrase means implement-from-memory mode, which is the failure this skill exists to prevent. There is no confidence level that substitutes for a fetched page: verify, cite, or flag as unverified. Those are the only three moves.

Completion Checklist

• [ ] Versions detected from the dependency file and stated
• [ ] Relevant official doc pages fetched for every framework pattern used
• [ ] No deprecated APIs; migration guides checked for the detected version
• [ ] Every non-trivial decision cited with a full, official, working URL
• [ ] Conflicts with existing code surfaced, not silently resolved
• [ ] Everything unverifiable explicitly flagged UNVERIFIED

Any box unchecked: not done. Fix or say so.