source-driven-development

Enforces the Detect → Fetch → Implement → Cite protocol when implementing against external frameworks or libraries. Invoke when a change touches an external API surface and the edit exceeds the triviality threshold, so implementations come from current official docs rather than stale training-data recall.

10 stars

Best use case

source-driven-development is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Enforces the Detect → Fetch → Implement → Cite protocol when implementing against external frameworks or libraries. Invoke when a change touches an external API surface and the edit exceeds the triviality threshold, so implementations come from current official docs rather than stale training-data recall.

Teams using source-driven-development should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/source-driven-development/SKILL.md --create-dirs "https://raw.githubusercontent.com/raddue/crucible/main/skills/source-driven-development/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/source-driven-development/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How source-driven-development Compares

Feature / Agentsource-driven-developmentStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Enforces the Detect → Fetch → Implement → Cite protocol when implementing against external frameworks or libraries. Invoke when a change touches an external API surface and the edit exceeds the triviality threshold, so implementations come from current official docs rather than stale training-data recall.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# 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` — `/build` orchestrator; 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:

1. The prompt, ticket body, or change context mentions a framework/library by name, OR the files being modified import one.
2. 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` / `using` of a detected framework, measured via `git diff --numstat` post-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:

1. **Manifest scan** — `package.json`, `requirements.txt`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `*.csproj`, `Gemfile`, `pom.xml`.
2. **Import scan** — top-of-file imports in the files being modified.
3. **Ticket body** — explicit framework mentions in the task description.
4. **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

<!-- TRUST: L4 Verify-first — WebFetch result. Verify against project code (L3) before implementing. See skills/getting-started/trust-hierarchy.md (when on main) -->

Fetch via the `WebFetch` tool. Capture the URL and the fetch date (ISO `YYYY-MM-DD`).

**Source hierarchy (DEC-2, high confidence):**

1. **Official docs** — `docs.<framework>.com`, `<framework>.readthedocs.io`, or the canonical `/docs` section on the project's own site (see `detect-stack.md`).
2. **Official blog / release notes** — for recent or breaking API changes.
3. **Upstream source / type definitions** — public API source in the framework's own repo (`.d.ts` files, exported module signatures). Use when docs lag a release.
4. **Web standards** — MDN, W3C, WHATWG specs for browser/platform APIs.
5. **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.

<!-- TRUST: L4 Verify-first — WebFetch result. Verify against project code (L3) before implementing. See skills/getting-started/trust-hierarchy.md (when on main) -->

**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:

1. **Prefer the doc's pattern over in-project precedent** when the project precedent is older than the doc's latest stable release.
2. **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 `/debugging` or a user decision.

<!-- TRUST: L4 Verify-first — WebFetch result. Verify against project code (L3) before implementing. See skills/getting-started/trust-hierarchy.md (when on main) -->

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):

```ts
// 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):** `WebFetch` ingests 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, the `WebFetch(domain:…)` allowlist in `.claude/settings.local.json` grows **incrementally** — one domain per doc host — rather than via a blanket `WebFetch(*)` grant. This keeps the attack surface explicit and auditable.
- Recommend running `crucible:siege` on changes produced through this skill when the change is public-facing, given the external-input surface.

Related Skills

test-driven-development

10
from raddue/crucible

Use when implementing any feature or bugfix, before writing implementation code

worktree

10
from raddue/crucible

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

workshop

10
from raddue/crucible

Tour of the Crucible workshop — the headline orchestrators users invoke directly. Use when the user asks "what skills are available?", "where do I start?", "what should I use for X?", "give me a tour of Crucible", "what are the main commands?", or any onboarding-style question. Also use after onboarding a new user or when someone needs to pick the right tool for a specific task.

verify

10
from raddue/crucible

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

ui-verify

10
from raddue/crucible

Use when verifying Unity UI matches a mockup, after implementing UI from a visual reference, when a user shares a screenshot showing UI drift, when checking theming compliance, or when UI looks wrong. Triggers on "verify", "compare to mock", "does this match", "check the UI", "screenshot shows wrong", "UI looks wrong", "fix the layout", "spacing is off", "colors are off", "doesn't look like the design", "visual bug", or completing any UI implementation task.

test-coverage

10
from raddue/crucible

Audit existing tests for staleness, needed updates, or removal after code changes. Use after any code modification to verify test suite alignment. Triggers on 'audit tests', 'check test alignment', 'stale tests', 'test health', or any task verifying tests match changed code. Technology-agnostic — works with any language and test framework.

temper

10
from raddue/crucible

Iteratively review code changes for production readiness through fresh-eyes review loops. Use when completing tasks, implementing major features, or before merging — including when the user says "review this PR", "review my changes", "code review", "check the diff", or "is this ready to ship". Works on PRs from any forge (GitHub, GitLab, Bitbucket, self-hosted) or on raw git SHA ranges.

temper-eval-collect

10
from raddue/crucible

Live-dispatch phase of temper eval harness. Reads stage-manifest.json from a pre-staged dispatch dir; fans Task-tool reviewer dispatches in parallel (max 6); writes per-seq result files; exits. Single bounded session. Pairs with `python -m skills.temper.evals.run_evals stage` and `score`.

temper-eval-calibrate

10
from raddue/crucible

Wrapper skill that runs k iterations of (stage → collect-behavior → score) for

stocktake

10
from raddue/crucible

Audits all crucible skills for overlap, staleness, broken references, and quality. Quick scan or full evaluation modes.

spec

10
from raddue/crucible

Use when you have a GitHub epic (or equivalent) with child tickets and want to autonomously produce design docs, implementation plans, and machine-readable contracts for each ticket without human interaction. Triggers on /spec, 'spec out', 'write specs for', 'spec this epic'.

skill-selection-evals

10
from raddue/crucible

Eval-only skill for measuring skill routing accuracy. Not invoked directly — contains selection evals that test whether the agent picks the correct skill for a given prompt.