v1truv1us/ai-eng-system

source-driven-development

Ground every framework decision in official documentation. Use when you want authoritative, source-cited code for any framework or library.

First seen May 7, 2026

Installation

$ npx skills add v1truv1us/ai-eng-system --skill source-driven-development

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from v1truv1us/ai-eng-system · top by installs.

npx skills add v1truv1us/ai-eng-system

Browse all from v1truv1us/ai-eng-system

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 8
License LICENSE
Default branch main
Open issues 0
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

More metadata
category
model-invoked

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,374 B
  • docs SUMMARY.md 172 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 2 installs

SKILL.md

Default output: return only the result, blockers, and required evidence. Omit preambles, process narration, repeated context, confidence scores, and follow-up offers. Use at most five bullets unless a required artifact or schema needs more.

Source-Driven Development

Overview

Verify every framework or library decision against official documentation before implementing. Flag any decision that lacks a source. This skill prevents the agent from relying on outdated patterns, hallucinated APIs, or assumptions about library behavior.

When to Use

  • Working with a framework or library you have not used recently
  • When API surface area is large or frequently changing
  • When the cost of a wrong assumption is high (auth, data, security)
  • When documentation lookup tools are available

Process

Step 1: Identify Framework Decisions

Before writing code that depends on a library:

  • List every API call, configuration option, or pattern you plan to use
  • Note which ones you are confident about and which are assumptions

Step 2: Verify Against Official Sources

For each decision:

  • Look up the current documentation
  • Confirm the API exists and behaves as expected
  • Note the version the docs target
  • If you cannot find a source, flag it explicitly

Step 3: Cite Sources

In comments or design docs:

  • Reference the official doc URL or section
  • Note the library version
  • Flag anything that could not be verified

Step 4: Flag Unverified Decisions

Explicitly mark decisions that lack source confirmation:

  • // UNVERIFIED: assuming X based on Y pattern
  • These flags must be resolved before production use

Source Quality Hierarchy

  1. Official documentation (highest)
  2. Official examples and repositories
  3. Well-maintained community guides with dates
  4. Stack Overflow with accepted answers and recent dates
  5. AI-generated suggestions (lowest, must be verified)

Common Rationalizations

Rationalization Reality
"I know this library well enough" Libraries change between versions. Confidence is not accuracy.
"Looking up docs slows me down" Debugging a wrong assumption is slower than verifying upfront.
"The AI already knows the right API" AI training data has a cutoff date. APIs change.

Verification

  • Every framework API call is verified against current docs
  • Unverified decisions are explicitly flagged
  • Library versions are documented
  • No code depends on hallucinated or outdated API behavior

Anti-Rationalization Table

Excuse Counter
"I know this library well enough" Libraries change between versions. Confidence is not accuracy.
"Looking up docs slows me down" Debugging a wrong assumption is slower than verifying upfront.
"The AI already knows the right API" AI training data has a cutoff date. APIs change. Verify against current docs.
"I'll verify after the implementation works" If the API does not exist, the implementation will not work. Verify first.
"Stack Overflow has the answer" Stack Overflow answers may be outdated. Official docs are the source of truth.