Install any skill in seconds. Free to start, no credit card required.
Get Started Free →ganyuanran/test-driven-development
Use when the user explicitly requests strict or test-first TDD, or when the current conversation already contains an explicit `TDD Route: strict` decision from another Aegis workflow.
Passed 18 of 20 test cases with the skill, and 12 of 20 without it.
and 10 more in the full report
7 fixed13 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.8-flash on 10/19/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are executing a high-complexity strict TDD task requiring process tracking in an Aegis workspace. What standard file path under `work/` should be created for intent and evidence logging?
| Checked | Without skill | With skill |
|---|---|---|
| References the structured directory pattern under `work/YYYY-MM-DD-<task-slug>/` | Missed | Passed |
| Includes standard step files such as intent, checkpoint, and evidence | Missed | Passed |
The instructions your model reads when the skill loads.
→ 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.
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.
On native-direct-skill hosts, automatic entry must stay anchored to literal
conversation markers such as TDD Route: strict, strict TDD, test-first,
or RED / GREEN / REFACTOR, not generic risky-implementation wording.
Only enter this skill after one of these explicit entry signals exists:
TDD Route: strict from another Aegis workflowtest cases passed, vs 12 / 20 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.