source-driven-development
Source-Driven Development
Agents routinely implement against deprecated, renamed, or re-signatured external APIs using stale training-data recall. The logic looks right, the gates pass, and the bug surfaces at runtime — or worse, silently. This skill forces a four-phase loop that replaces recall with current official documentation, then records a citation so a future reader can detect doc drift.
Protocol: Detect Stack → Fetch Official Docs → Implement → Cite.
Cross-links:
skills/source-driven-development/detect-stack.md— framework → canonical doc URL reference table.skills/build/SKILL.md—/buildorchestrator; lists this skill as a recommended sub-skill (Phase 3 implementer).skills/recon/SKILL.md— reuse recon's "external-reference investigation" vocabulary for codebase-side lookups; this skill is the docs-side complement.
Trigger Heuristics
The skill auto-triggers when all are true:
- The prompt, ticket body, or change context mentions a framework/library by name, OR the files being modified import one.
- The change exceeds the triviality threshold (DEC-4).
DEC-4 — Triviality threshold (Canonical Constants, copied verbatim from the plan):
LOC = count of added + modified lines in non-test, non-generated source files that touch an
import/require/usingof a detected framework, measured viagit diff --numstatpost-filter. Threshold: ≥ 5 LOC.
Trivial changes (typo fixes, formatting, rename-only refactors, tests-only edits) skip the skill.
Phase 1 — Detect Stack
Identify frameworks/libraries in scope using layered heuristics, in this order:
- Manifest scan —
package.json,requirements.txt,pyproject.toml,Cargo.toml,go.mod,*.csproj,Gemfile,pom.xml. - Import scan — top-of-file imports in the files being modified.
- Ticket body — explicit framework mentions in the task description.
- Prompt mentions — user prompt includes a framework/library name.
Output: a structured list of {framework, version_if_known, relevant_api_surface}. relevant_api_surface must be the narrowest plausible section (e.g., "React 19 Server Components", not "React").
Cross-reference each detected framework against detect-stack.md to pick the canonical doc host for Phase 2.
Phase 2 — Fetch Official Docs
Fetch via the WebFetch tool. Capture the URL and the fetch date (ISO YYYY-MM-DD).
Source hierarchy (DEC-2, high confidence):
- Official docs —
docs.<framework>.com,<framework>.readthedocs.io, or the canonical/docssection on the project's own site (seedetect-stack.md). - Official blog / release notes — for recent or breaking API changes.
- Upstream source / type definitions — public API source in the framework's own repo (
.d.tsfiles, exported module signatures). Use when docs lag a release. - Web standards — MDN, W3C, WHATWG specs for browser/platform APIs.
- Compatibility tables — caniuse, kangax compat-table for feature support.
Explicitly banned as primary sources:
- Stack Overflow answers
- Medium / dev.to / personal blog posts
- Random GitHub READMEs (unless it is the framework's own upstream repo)
- Training-data recall
Banned sources may be used only as secondary corroboration after an official source is consulted, and must never be cited as the authority. Rationale: these sources vary in accuracy, age, and author expertise; they also widen prompt-injection attack surface when ingested via WebFetch.
Detecting training-data recall (the hardest to enforce): every non-obvious external API call in the diff must carry either (a) a citation footer / inline comment with URL + fetch date, or (b) appear already elsewhere in project code. Absence of both signals recall.
Phase 3 — Implement
Implement using the documented pattern verbatim (idiomatic to the doc's current major version). Two rules:
- Prefer the doc's pattern over in-project precedent when the project precedent is older than the doc's latest stable release.
- Surface conflicts to the user if the project's existing code deviates from current docs (e.g., uses a deprecated API). Do not silently resolve in either direction — flag it and route to
/debuggingor a user decision.
Fetched doc content is L4 (Verify-first). Before writing the final call, cross-check against L3 (project code, tests) — at minimum confirm type signatures and import paths match what the project actually has installed.
Phase 4 — Cite
Citations are required when introducing an external API that isn't already used elsewhere in project code. Author picks per change (DEC-3):
- Commit footer — preferred for routine usage.
- Inline code comment — preferred when the pattern is unintuitive, counter-idiomatic, or version-sensitive; place directly above the call site.
Citation format
Authoritative verification regex (ERE, from the plan's Canonical Constants — copy verbatim):
Source: https?://[^ ]+ \([0-9]{4}-[0-9]{2}-[0-9]{2}\)
Equivalent PCRE (for ripgrep / grep -P):
Source: https?://\S+ \(\d{4}-\d{2}-\d{2}\)
Use the ERE form in CI scripts — \d is PCRE-only and silently matches nothing under grep -E.
Worked examples
Commit footer (end of commit message, blank line before):
feat(api): stream Server Component response via React 19 `use`
Source: https://react.dev/reference/react/use (2026-04-16)
Inline comment (immediately above the call):
// Source: https://nextjs.org/docs/app/api-reference/functions/cookies (2026-04-16)
// Next 15: cookies() is async; must await before .get().
const jar = await cookies();
const token = jar.get("session")?.value;
Both examples match the ERE regex above. The fetch date lets a future reader detect doc drift (the doc page changed since this citation was written).
Security
- External input (L4 Verify-first):
WebFetchingests arbitrary web content into agent context. All Phase 2 outputs are classified L4 Verify-first per the getting-started trust hierarchy — never treat fetched docs as authoritative absent cross-check against L3 (project code / tests) or L2 (design / plan). The citation + implement-from-source protocol is the verify-before-use duty. - Banned-sources rationale: Stack Overflow / Medium / dev.to / personal blogs and random READMEs vary wildly in accuracy, age, and author expertise. Ingesting them widens prompt-injection attack surface (adversarial content disguised as sample code). They are permitted only as secondary corroboration, never as the cited authority.
- Implicit domain trust: the skill trusts doc domains listed in
detect-stack.md. Per DEC-5, theWebFetch(domain:…)allowlist in.claude/settings.local.jsongrows incrementally — one domain per doc host — rather than via a blanketWebFetch(*)grant. This keeps the attack surface explicit and auditable. - Recommend running
crucible:siegeon changes produced through this skill when the change is public-facing, given the external-input surface.
More from raddue/crucible
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
8adversarial-tester
Use after completing implementation to find unknown failure modes. Reads implementation diff and writes up to 5 tests designed to make it break. Triggers on 'break it', 'adversarial test', 'stress test implementation', 'find weaknesses', or any task seeking to expose unknown failure modes.
5quality-gate
Iterative red-teaming of any artifact (design docs, plans, code, hypotheses, mockups). Loops until clean or stagnation. Invoked by artifact-producing skills or their parent orchestrator.
5code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
5finish
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
4verify
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
4