agentleFS
Sign inStart free
galandogalando/temper/skills/source-driven-development/SKILL.md

source-driven-development

Skill18 starsChanged 8 months agoMITView on GitHub

Version-aware, source-driven development — fetch official docs before writing framework code

We split this skill into the rules it gives an agent

19 rules. 0 are common, 13 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 61 edited versions we read keep these.

  • 13

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    JavaScript/TypeScript: Read package.json — extract dependencies and devDependencies

    line 40
  2. Very specific:

    Java: Read pom.xml or build.gradle — extract dependency versions

    line 41
  3. Very specific:

    Python: Read pyproject.toml or requirements.txt — extract pinned versions

    line 42
  4. Very specific:

    Go:: Read go.mod — extract module versions

    line 43
  5. Very specific:

    Rust: Read Cargo.toml — extract dependency versions

    line 44
  6. Distinctive:

    If a documentation MCP server such as Context7 is available: resolve the library to its ID, query it for the specific API or pattern you …

    line 50
  7. Very specific:

    If no documentation server is available: web-search {library} v{version} {api} documentation and fetch the official docs page with the …

    line 55
  8. Distinctive:

    When writing framework-specific code, include a citation comment:

    line 61
  9. Distinctive:

    After fetching docs, compare against what you were about to write:

    line 82
  10. Distinctive:

    If a conflict is found:

    line 89
  11. Distinctive:

    BLOCK: if the planned code would use a removed API

    line 90
  12. Distinctive:

    WARN: if the planned code uses a deprecated but still functional API

    line 91
  13. Distinctive:

    SUGGEST: if a newer pattern exists but the old one still works

    line 92
  14. Distinctive:

    When multiple documentation sources conflict, use this hierarchy:

    line 96
  15. Distinctive:

    After writing framework-specific code:

    line 116
  16. Distinctive:

    Did you include a citation comment?: If not, add one.

    line 118
  17. Distinctive:

    Does the cited URL actually contain the API you used?: Verify, don't hallucinate URLs.

    line 119
  18. Distinctive:

    Does the code match the version in the manifest?: Not the latest version — the *installed* version.

    line 120
  19. Distinctive:

    Were there any conflicts surfaced in Step 4?: If so, were they resolved?

    line 121

“Common” is measured: kept by at least 6 in 10 of the 61 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Source-Driven Development

Version: 1.0.0 Last Updated: 2026-05-12

Overview

Source-driven development ensures that framework-specific code is written against current official documentation, not stale training data. AI models often generate code using deprecated APIs, wrong parameter orders, or patterns from older versions. Existing usage in the codebase is not verification either: the codebase may be on an older version, and a passing test proves the code runs, not that the API is current. This skill enforces a verification loop:

Detect version → Fetch current docs → Write code with citations → Surface conflicts

This skill leverages the Context7 MCP server (if available) to fetch version-specific documentation at build time.

When to Use

  • /temper:build or /temper:fix writing framework-specific code (React, Spring Boot, Express, FastAPI, etc.)
  • Adding or updating a dependency
  • Writing code that uses a library API you haven't used recently
  • Whenever the agent says "I believe the API works like..."

Skip when:

  • Writing plain logic (no framework dependency)
  • Writing tests for code you just read (you already have the source)
  • Modifying config files with known structure

Process

Step 1: Read Manifest

Detect the project's dependencies and versions:

  1. JavaScript/TypeScript: Read package.json — extract dependencies and devDependencies
  2. Java: Read pom.xml or build.gradle — extract dependency versions
  3. Python: Read pyproject.toml or requirements.txt — extract pinned versions
  4. Go: Read go.mod — extract module versions
  5. Rust: Read Cargo.toml — extract dependency versions

For the specific library you're about to use, note the exact version installed.

Step 2: Fetch Current Documentation

If a documentation MCP server such as Context7 is available: resolve the library to its ID, query it for the specific API or pattern you need at the installed version, and read the returned snippets. Use the tool names the server exposes in this session rather than assuming them.

If no documentation server is available: web-search {library} v{version} {api} documentation and fetch the official docs page with the fetch tool you have. This is [HEURISTIC] rather than [PROVEN] — note the evidence level.

Step 3: Cite Sources

When writing framework-specific code, include a citation comment:

// Ref: React 19 useActionState — https://react.dev/reference/react/useActionState
const [state, submitAction, isPending] = useActionState(async (prevState, formData) => {
  // ...
}, initialState);

Or in Java:

// Ref: Spring Data JDBC 3.4 @Query — https://docs.spring.io/spring-data/jdbc/reference/repositories/query-methods.html
@Query("SELECT * FROM users WHERE email = :email")
Optional<User> findByEmail(@Param("email") String email);

Citation format: {framework} v{version} {api/function} — {url}

Step 4: Surface Conflicts

After fetching docs, compare against what you were about to write:

  1. API signature changed? — parameters added, removed, or reordered
  2. Deprecated pattern? — the pattern you planned to use is now deprecated
  3. New recommended approach? — a better pattern exists in the current version
  4. Breaking change? — the version in the project has a breaking change from what training data suggests

If a conflict is found:

  • BLOCK if the planned code would use a removed API
  • WARN if the planned code uses a deprecated but still functional API
  • SUGGEST if a newer pattern exists but the old one still works

Step 5: Authority Hierarchy

When multiple documentation sources conflict, use this hierarchy:

  1. Official docs (react.dev, docs.spring.io, fastapi.tiangolo.com) — highest authority
  2. Type definitions (DefinitelyTyped, built-in .d.ts) — mechanical truth
  3. Source code (GitHub repo, node_modules) — ground truth but may be internal
  4. Community (Stack Overflow, blog posts) — useful for patterns, not API signatures
  5. Training data (what the model "knows") — lowest authority, always verify

Red Flags

Watch for these signs that source-driven development would have prevented a problem:

  • "Property X does not exist on type Y" — you used an API from a different version
  • "Warning: X is deprecated, use Y instead" — you used training-data knowledge, not current docs
  • Test passes but runtime behavior differs — API contract changed subtly between versions
  • Code works locally but fails in CI — dependency version mismatch between environments
  • Import not found — the module was reorganized in a newer version

Verification

After writing framework-specific code:

  1. Did you include a citation comment? If not, add one.
  2. Does the cited URL actually contain the API you used? Verify, don't hallucinate URLs.
  3. Does the code match the version in the manifest? Not the latest version — the installed version.
  4. Were there any conflicts surfaced in Step 4? If so, were they resolved?

Download now (ZIP)

  • Other versions68 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 68

    1. addyosmani/agent-skills★ 112ksame name
    2. shashankswe2020-ux/whoop-mcp★ 174same name
    3. tranhieutt/software_development_department★ 71same name
    4. drvoss/everything-copilot-cli★ 49same name
    5. vinvcn/addyosmani-agent-skills-zh★ 46same name
    6. jmxt3/gitscape.ai★ 33same name
    7. sampleXbro/agentsmesh★ 24same name
    8. jaskirat1616/grok-skills★ 22same name
    9. HK-hub/AgentSkills★ 6same name
    10. ddddjaak/ae-skills★ 4same name

    58 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use constraint-driven-development, incremental-implementation and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • MrCipherSmithSkill

      constraint-driven-development

      Use when a project needs a persistent, measurable quality bar — starting a project without documented standards, 'set up constraints', or when coverage/perf/a11y thresholds get re-debated per-PR. Produces CONSTRAINTS.md with enforceable numbers, ratchets, and a guard against silent weakening. NOT for throwaway prototypes or a one-off CI setup.

      Also in 13 projects that use this

    • LLl0k0laDSkill

      incremental-implementation

      Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.

      Also in 36 projects that use this

    • barisariburnuSkill

      performance-optimization

      Complete performance optimization guide for Next.js applications including frontend, backend, database, caching, and general optimization strategies. Use when improving performance, reducing bundle size, optimizing queries, or implementing caching.

      Also in 38 projects that use this

    • OpenAISkill

      verification-before-completion

      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

      Also in 6 projects that use this

    • ElasticSkill

      accessibility

      Accessibility guidance for Kibana. Use this skill when working with or reviewing EUI components, resolving a11y-related (@elastic/eui) ESLint issues, and ensuring proper use of ARIA attributes, focus management, keyboard interactions, and accessible naming conventions.

      Also in 3 projects that use this

    • PostHogSkill

      karpathy-guidelines

      Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria. Based on https://github.com/multica-ai/andrej-karpathy-skills.

      Also in 3 projects that use this

  • In this repository5 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free