Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/shennawardana23/skillme/source-driven-developmentnpx skills add shennawardana23/skillme --skill source-driven-developmentgit clone --depth 1 https://github.com/shennawardana23/skillmeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/shennawardana23/skillme/source-driven-development)<a href="https://agentmods.dev/skills/shennawardana23/skillme/source-driven-development"><img src="https://agentmods.dev/badge/skills/shennawardana23/skillme/source-driven-development.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00073 | $0.01414 |
| Opus 5 | $0.00036 | $0.00707 |
| Sonnet 5 | $0.00015 | $0.00283 |
| Haiku 4.5 | $0.00007 | $0.00141 |
Grade A, and why
source-driven-development scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 157 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Source-Driven Development
Verify framework-specific patterns against official documentation before writing them, rather than from memory. Training data goes stale, APIs deprecate, and best practices evolve — a pattern that was correct in a training snapshot can be the wrong one for the version actually installed. Every framework-specific decision should trace back to a source the user can check themselves.
When to use
Building boilerplate or patterns that will be copied elsewhere in the project; the user asks for "current," "documented," or "verified" code; implementing something where the framework's recommended approach matters (forms, routing, data fetching, state management, auth); reviewing code that leans on framework conventions; any time about to write framework-specific code from memory.
Skip it for: logic that's version-independent (loops, conditionals, data structures), renames/typo fixes, or when the user explicitly wants speed over verification.
The process
DETECT ──→ FETCH ──→ IMPLEMENT ──→ CITE
1. Detect stack and versions
Read the dependency file — package.json, composer.json,
go.mod, requirements.txt/pyproject.toml, Gemfile — and state what
was found:
STACK DETECTED: React 19.1.0, Vite 6.2.0 (from package.json)
→ Fetching official docs for the relevant pattern.
If a version is missing or ambiguous, ask — don't guess. The version is what determines which pattern is actually correct.
2. Fetch the specific documentation page
Fetch the page for the feature being implemented, not the framework homepage and not a general web search.
| Priority | Source |
|---|---|
| 1 | Official documentation (react.dev, docs.djangoproject.com, pkg.go.dev) |
| 2 | Official blog / changelog |
| 3 | Web standards references (MDN, web.dev) |
| 4 | Browser/runtime compatibility tables (caniuse.com) |
Not authoritative, never cite as primary: Stack Overflow answers, blog posts or tutorials, AI-generated summaries, or your own training data — verifying that training data is the entire point of this skill.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 157 lines · 73 tokens per session scan A 2b701f706b01
source-driven-development is a skill published in the GitHub repository shennawardana23/skillme (2 stars, last pushed 7d ago), licensed Apache-2.0. It adds 73 tokens to every session and 1,414 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
creating-explainers
Use when creating an interactive explainer - a single self-contained HTML page with hand-built Canvas figures. Handles source-file explainers, topic-driven research explainers, and mixed intake where files provide the spine and research adds support. Trigger phrases include "make an explainer", "turn this paper into…
explaining-codebases
Use when creating an interactive explainer about a codebase, repository, or source files. Handles onboarding overviews, architecture maps, and deep-dives on real implementation paths. Trigger phrases include "explain this codebase", "interactive guide to this repo", "walk through how X works in the code", or…
hidden-talents
Interview you in depth to surface overlooked or suppressed talents and write your Personal Talent Manual.
socratic
Diagnose a confusion Socratically, one question at a time, until the question actually worth answering surfaces — then answer that one.
two-layer-explain
Explain a concept twice — for a newcomer and for an expert — then bridge the two layers, flag the likely misunderstandings, and set three check questions.
deconstruct
Reverse-engineer why a finished piece of work succeeds and extract what transfers to your own — rules, a checklist, and a first exercise.