| name | source-driven-development |
| description | Use when framework, SDK, or library behavior is unfamiliar or version-sensitive — verify from local authoritative sources (decompiled/SDK code, in-repo docs) before implementing. |
| type | skill |
| license | MIT |
| compatibility | ["claude-code","cursor","codex"] |
| trigger | unfamiliar-api|version-sensitive|sdk-uncertainty|framework-behavior |
| skip_when | well-understood-local-patterns|no-external-dependencies |
| user-invocable | false |
Source-Driven Development
Overview
When framework behavior matters, memory is not enough. Verify unfamiliar APIs against authoritative sources and call out anything that remains unverified.
When To Use
- New or unfamiliar .NET, EF Core, AWS SDK, or package APIs
- Version-sensitive framework behavior
- Performance or security-sensitive framework usage
- Conflicting assumptions between repo patterns and tool memory
When NOT To Use
- Well-understood local code patterns already validated in the repo and unchanged by version differences
- Forward-looking "current best way" questions that need web research → use
research-context
Workflow
- Identify the uncertain API or behavior.
- Check whether the repo already demonstrates the same API safely.
- If not, consult authoritative documentation.
- Distinguish clearly between:
- verified from source
- inferred from local codebase pattern
- still uncertain
- Implement only after the uncertainty is resolved or explicitly surfaced.
Rules
- Do not present guessed framework behavior as fact.
- Prefer authoritative sources over memory.
- If the behavior cannot be verified, state that plainly.
Common Rationalizations
See .claude/skills/context-engineering/SKILL.md for the shared table. Source-driven-specific traps: "this API probably behaves like the last one I used" (similar names cause production bugs — verify the actual contract for this version), and "I'll fix it if it breaks" (source checks are cheaper than post-failure recovery, especially for transaction or security behavior).
Red Flags
- New framework usage with no evidence behind it
- Version-sensitive assumptions stated as certainty
- Security or transaction behavior guessed from memory
Verification
