| name | source-driven-development | ||||||
|---|---|---|---|---|---|---|---|
| description | Use when implementing framework-specific or library-specific code — verify non-trivial APIs against official documentation before writing them, and record the source in task notes, docs, or the PR. | ||||||
| metadata |
|
AI agents can confidently generate outdated or deprecated framework code. Source-driven development replaces memory-based implementation with a repeatable loop: detect the version, fetch the official source, implement from that source, then capture the reference in durable notes.
- Writing framework-specific code you have not touched recently
- Using a library that changed versions since the last time you used it
- Implementing middleware, routing, configuration, hooks, or SDK integration
- Seeing deprecation warnings or suspecting API drift
- Asking an AI agent to write code where stale training data could mislead it
| Instead of source-driven-development | Use |
|---|---|
| Writing pure business logic with no framework dependency | spec-driven-development |
| Reusing a stable internal utility with known behavior | implement directly |
| Looking up tool setup for MCP servers | mcp-ecosystem |
- You know which library, framework, or SDK is involved
- You can determine the exact version used in the project
- You have access to official docs, release notes, or migration guides
Do not look up docs before you know what version the project actually uses.
Check package manifests, lockfiles, or module metadata first.
Examples:
- package.json / package-lock.json
- pyproject.toml / requirements.txt
- go.mod
Use this priority order:
- Official documentation site
- Official GitHub repository changelog or migration guide
- Official release notes or blog posts
- MDN for web platform APIs
Avoid secondary tutorials as your primary authority.
Write down the specific API shape before coding:
- function or hook name
- required arguments
- return shape
- error handling behavior
- version-specific caveats
Only write the framework code after you can point to the official pattern it follows.
Implementation rule:
- use the documented API shape
- follow the documented order of operations
- avoid "this is probably how it works" guesses
For non-obvious decisions, record the source in one of:
- task notes
- ADR or design doc
- PR description
- surrounding documentation
Prefer durable project context over scattering source URLs through product code.
1. Confirm the project uses Next.js 15 in package.json
2. Fetch the current official middleware docs
3. Verify the App Router middleware API shape
4. Implement the middleware
5. Note the docs URL and the version-specific behavior in the PR description
use context7
How do I configure middleware in Next.js 15 App Router?
| Rationalization | Reality |
|---|---|
| "I remember how this API works" | Framework APIs drift quietly between versions. |
| "The AI probably knows the current syntax" | Model training data is not a guarantee of version accuracy. |
| "A blog post is good enough" | Secondary tutorials often lag behind the official API. |
| "I'll fix deprecations later" | Deprecations compound and make migrations harder. |
- Guessing parameter order or option names
- Writing code before checking the installed version
- Mixing patterns from multiple major versions
- No durable note for a non-obvious framework decision
- The project version was checked before implementation
- The implementation matches an official source
- Non-obvious API choices were captured in docs, notes, or the PR
- No deprecated or guessed API usage remains
- Use
Context7or direct doc fetches when you need current, version-aware guidance - Pair this with
spec-driven-developmentwhen an interface and a framework decision both matter - If a decision still feels fuzzy after reading docs, stop and isolate the unknown before coding
spec-driven-development— define interfaces and boundaries firstcontext-engineering— provide the right source context to the agentmcp-ecosystem— set up documentation-oriented MCP tools