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/oleg494/coding-kit/test-driven-developmentnpx skills add oleg494/coding-kit --skill test-driven-developmentgit clone --depth 1 https://github.com/oleg494/coding-kitWhat 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.00050 | $0.00703 |
| Opus 5 | $0.00025 | $0.00351 |
| Sonnet 5 | $0.00010 | $0.00141 |
| Haiku 4.5 | $0.00005 | $0.00070 |
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 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 — 85 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test-Driven Development
Overview
Write a failing test before writing the code that makes it pass. For bug fixes, reproduce the bug with a test before attempting a fix. Tests are proof — "seems right" is not done.
The TDD Cycle
RED GREEN REFACTOR
Write a test Write minimal code Clean up the
that fails ──→ to make it pass ──→ implementation ──→ (repeat)
│ │ │
▼ ▼ ▼
Test FAILS Test PASSES Tests still PASS
Step 1: RED — Write a Failing Test
Write the test first. It must fail. A test that passes immediately proves nothing.
Step 2: GREEN — Make It Pass
Write the minimum code to make the test pass. Don't over-engineer.
Step 3: REFACTOR — Clean Up
With tests green, improve the code without changing behavior. Extract shared logic, improve naming, remove duplication. Run tests after every refactor step.
The Prove-It Pattern (Bug Fixes)
Bug report → test that reproduces bug → test FAILS → fix → test PASSES → full suite
The Test Pyramid
╱╲
╱ ╲ E2E Tests (~5%)
╱ ╲ Full user flows
╱──────╲
╱ ╲ Integration Tests (~15%)
╱ ╲ Component interactions, API boundaries
╱────────────╲
╱ ╲ Unit Tests (~80%)
╱ ╲ Pure logic, isolated, milliseconds
╱──────────────────╲
Writing Good Tests
Test State, Not Interactions
Assert on the outcome of an operation, not on which methods were called internally.
DAMP Over DRY in Tests
In tests, DAMP (Descriptive And Meaningful Phrases) is better than DRY. Each test should tell a complete story.
Prefer Real Implementations Over Mocks
Preference: Real implementation > Fake > Stub > Mock. Use mocks only when real is too slow, non-deterministic, or has side effects you can't control.
Use Arrange-Act-Assert
// Arrange: Set up the test scenario
// Act: Perform the action being tested
// Assert: Verify the outcome
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 · 85 lines · 50 tokens per session scan A c1a7f81af13f
test-driven-development is a skill published in the GitHub repository oleg494/coding-kit (1 stars, last pushed yesterday), licensed MIT. It adds 50 tokens to every session and 703 once invoked, about $0.0003 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-08-31.
Other skills, from other repositories
run
Execute a named agent role with optimized instructions. Explicit invocation only ($run). Never trigger implicitly.
tip
Deliver a transformative life perspective shift and a productivity tip. Use when the user invokes /tip or wants non-technical inspiration or a fresh mental model.
agentic-security-review
Run a security and dependency audit for agent systems, tool-using AI apps, MCP/A2A integrations, or security-sensitive AI-generated code. Check slopsquatting risk, tool shadowing, rug pulls, memory/context poisoning, secrets, unsafe permissions, and common CWE patterns. Use when asked for security review, dependency…
agentic-spec
Create a structured specification before agentic coding work. Assemble the six context types, scale rigor for prototype/internal/production tasks, produce SPEC.md, and configure focused AGENTS.md boundaries. Use when asked to write a spec, plan a feature, design an agent/system, define architecture, or create…
agentic-evals
Design evaluation contracts and test plans for agentic systems. Create deterministic tests, trajectory evals, quality dimensions, gold-set criteria, and CI gates before or after implementation. Use when asked for tests first, an eval plan, success criteria, non-deterministic testing, LLM-as-judge setup, or…
agentic-production-readiness
Prepare an AI agent system for production operation. Cover SHIELD controls, sandbox/canary/production rollout, OpenTelemetry observability with GenAI semantic conventions, Agent Card drafting, governance, and post-deploy monitoring. Use for production readiness checks, go-live checklists, agent monitoring, agent…