Aegis is a method pack that guides coding agents to inspect a project's baseline, make bounded changes, and verify their work with fresh evidence. It is for people using coding-agent hosts who want fewer unverified changes and less unnecessary process. The catalogue add-ons implement this method through skills, instructions, commands, a hook, and a plugin.
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 skills add GanyuanRan/Aegis --skill test-driven-developmentgit clone --depth 1 https://github.com/GanyuanRan/AegisWrote 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/ganyuanran/aegis/test-driven-development)<a href="https://agentmods.dev/skills/ganyuanran/aegis/test-driven-development"><img src="https://agentmods.dev/badge/skills/ganyuanran/aegis/test-driven-development/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/ganyuanran/aegis/test-driven-development"><img src="https://agentmods.dev/badge/skills/ganyuanran/aegis/test-driven-development.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.1 | $0.00041 | $0.04099 |
| Opus 5.5 | $0.00016 | $0.01640 |
| Sonnet 5.5 | $0.00008 | $0.00820 |
| Haiku 4.5 | $0.00004 | $0.00410 |
Grade A, and why
test-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 8d ago.
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 — 489 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Execute
→ False-positive entry on a native-direct-skill host? → Exit immediately unless the user explicitly asked for TDD or the conversation already contains TDD Route: strict.
In off mode, do not start RED / GREEN / REFACTOR from generic bugfix, contract, shared-module, or risky-code wording alone.
Hand control back to using-aegis, systematic-debugging, writing-plans, or the fast path with verification.
→ Implementing a feature or bugfix under TDD Route strict? → No production code without a failing test first.
Gate: medium/high complexity? → route to brainstorming or writing-plans first.
Mode: default off disables automatic TDD, not completion verification; auto chooses strict/light/skipped by risk.
Change Necessity: before strict RED/GREEN enters production edits, confirm the slice really needs a code change.
Cycle: RED (write test → watch it fail) → GREEN (minimal code → watch it pass) → REFACTOR (clean up → keep green)
Regression: shared module → related tests. contract change → producer + consumer. core logic → old + new tests.
Ripple signal hit → cover producer+consumer or real user path before claiming green.
GREEN proves the currently expressed behavior slice only.
GREEN does not by itself prove parent-task acceptance, business-value completion, or final completion.
→ Done when: chosen TDD Route is recorded, strict-route tests pass, TDD preflight gate passed when applicable, pre-edit complexity risk was checked for non-trivial source edits, and verification-before-completion has fresh evidence.
Test-Driven Development (TDD)
Overview
Under TDD Route: strict, write the test first. Watch it fail. Write minimal
code to pass.
If you didn't watch the test fail, you don't know if it tests the right thing.
TDD Mode has two values: off and auto. The default off mode disables
automatic TDD routing but never disables verification-before-completion.
auto lets Aegis choose a TDD Route by task risk.
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.
- 8d ago Changed · +9 lines de850e1b4e39
- 1mo ago First seen · 480 lines · 41 tokens per session scan A ad1bb364c873
test-driven-development is a skill published in the GitHub repository GanyuanRan/Aegis (1,358 stars, last pushed yesterday), licensed MIT. It adds 41 tokens to every session and 4,099 once invoked, about $0.0002 per session on Opus 5.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-08-30.
Other skills, from other repositories
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code.
writing-skills
A guide for creating and testing reusable instructions for AI agents, called skills. It applies test-driven development, or TDD—the practice of writing tests before implementation—to instruction documents.
test-driven-development
Test-driven development, or TDD, is a way to build software by writing a test that fails, adding the smallest code that makes it pass, and then cleaning up the code. These instructions require that process for features, bug fixes, refactors, and behavior changes.
django-tdd
Django testing strategies with pytest-django, TDD methodology, factoryboy, mocking, coverage, and testing Django REST Framework APIs.
golang-testing
Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices.
laravel-tdd
Test-driven development for Laravel with PHPUnit and Pest, factories, database testing, fakes, and coverage targets.