Source-Driven Development (SDD) is an AI agent capability that grounds software development decisions in authoritative official documentation rather than relying on potentially outdated training data or hallucinated information. This skill enables AI systems to verify technical requirements, detect software stack configurations, and identify conflicts between proposed changes and existing codebase standards by consulting current source materials in real-time.

Source-Driven Development represents a methodological shift in how AI agents approach software engineering tasks. Rather than generating code solutions based solely on learned patterns, SDD agents actively retrieve and consult official documentation, API references, and technical specifications to ground their recommendations in verified information ¹⁾.

The skill addresses a fundamental challenge in AI-assisted development: the divergence between training data timestamps and current software versions. Official documentation represents the authoritative source for correct behavior, particularly as libraries, frameworks, and languages evolve. By systematically consulting these sources, SDD agents reduce the risk of recommending deprecated patterns, incorrect API usage, or incompatible version combinations.

The SDD skill operates through a multi-stage process beginning with stack detection. When analyzing an existing codebase, the agent identifies relevant technologies, programming languages, frameworks, and their specific versions. This detection may occur through configuration files (package.json, requirements.txt, pom.xml), import statements, build configurations, or dependency specifications ²⁾.

Once the stack is identified, the agent fetches relevant documentation from official sources. This involves constructing appropriate URLs to official documentation sites, API references, and technical specifications that correspond to the detected versions. The agent must maintain awareness of version-specific documentation URLs, as many projects maintain separate documentation branches or archives for different releases.

The conflict flagging mechanism compares proposed development changes against both existing code patterns and official documentation requirements. This includes detecting when suggested code would violate documented constraints, use deprecated APIs, or introduce incompatibilities with existing dependencies.

A complementary sdd-cache hook manages persistent caching of source documents across multiple agent sessions. This optimization layer uses SHA256 hashing of URLs as cache keys, enabling efficient retrieval of previously-fetched documentation without redundant network requests ³⁾.

The caching mechanism respects HTTP standards, particularly the 304 Not Modified response code. When cached content exists for a URL, the agent submits the cached entity tag (ETag) or modification date headers with its request. If the remote server responds with 304 Not Modified, the cached document body is served immediately without re-downloading. This approach minimizes bandwidth consumption while ensuring documentation freshness through standard HTTP semantics.

The cache operates across sessions, meaning documentation fetched during one development task remains available for subsequent tasks, reducing latency for frequently-referenced documentation like popular framework guides or language specifications.

Source-Driven Development proves particularly valuable in several development scenarios. When implementing features in unfamiliar frameworks, agents can immediately consult authoritative guides rather than extrapolating from training data. When upgrading dependencies, agents detect breaking changes by consulting version-specific documentation. When reviewing pull requests, agents flag API misuses by comparing proposed changes against current documentation standards.

The skill enables agents to serve as documentation-aware code assistants, catching errors that might otherwise require human code review. Senior engineers traditionally perform this function by mentally cross-referencing code against their knowledge of official specifications—SDD agents automate this process by consulting actual specifications rather than relying on potentially fallible memory.

The effectiveness of Source-Driven Development depends on the quality and currency of official documentation. Projects with sparse documentation or poorly-maintained specification documents provide limited grounding for agent decisions. Similarly, undocumented or poorly-specified behavior in libraries presents challenges, as official sources may not address edge cases or subtle implementation details.

Documentation accessibility presents another consideration. Some projects require authentication to access documentation, maintain documentation only in formats agents cannot easily parse, or distribute documentation through channels agents cannot reach. Additionally, certain specialized or internal libraries may have no publicly-available official documentation, limiting SDD's applicability.

The approach also requires careful handling of documentation that contains conflicting information, outdated sections, or examples that do not match implemented behavior. Agents must develop heuristics for identifying authoritative sections within documentation and recognizing when documentation diverges from actual implementation.

• Source-Driven Development vs Assumption-Driven Development
• Doubt-Driven Development (Adversarial Fresh-Context Review)
• Test-Driven Development Skill
• AI-Generated Expertise Artifacts
• AI-Generated vs Carefully-Crafted Codebases