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/testing-disciplinenpx skills add oleg494/coding-kit --skill testing-disciplinegit 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.00110 | $0.01014 |
| Opus 5 | $0.00055 | $0.00507 |
| Sonnet 5 | $0.00022 | $0.00203 |
| Haiku 4.5 | $0.00011 | $0.00101 |
Grade A, and why
testing-discipline 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 — 61 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Testing discipline: tests as a spec and defining "done"
1. Isolation and structure
- NEVER TOUCH PROD STORE IN TESTS — tests on throwaway storage: env path override + temp file + fresh import. Prod row count unchanged after the suite.
- FRESH IMPORT FOR MODULE-LEVEL SIDE EFFECTS — import-time connect/migrate breaks isolation:
sys.modules.pop+ importlib per test/fixture. - UNIT DOMAIN FIRST, HANDLER WIRING SECOND — business rules without a framework; handlers are thin glue with fakes for I/O. Domain suite green offline in <2s.
- FAKE THE EDGES, NOT THE CORE — mock Telegram/HTTP/API; do NOT mock your own business logic "for convenience". Handler test touches the real temp DB.
2. Names and boundaries
- TEST NAMES ARE THE SPEC —
test_referral_no_self,test_crypto_idempotent— name = rule.pytest --collect-onlyreads like a product checklist. NOT test_1, test_works. - PRODUCT RULES AS NAMED TESTS — the spec lives in tests:
test_free_spent_first,test_cannot_buy_while_paid_remains. A new developer reads the tests = understands the product. - ASSERT THE BOUNDARY CASES — at minimum per function: happy + one edge + one abuse. free→0, paid edge, self-ref, double credit, empty username, overflow.
- WRITE THE ABUSE CASE WHEN YOU WRITE THE GROWTH CASE — referral/promo written with an anti-fraud test in the same PR.
3. Specific tests
- MONEY PATH: double-submit → balance +X not +2X; provider error injection → balance unchanged; reject →
assert not user_exists(...). - LIMITS (cap): test before implementation: cap exhausted → False, user not created; monkeypatch.setenv;
assert cap and invited >= cap. - RATE LIMIT: two consecutive calls → second blocked without external API: mock API → assert len(calls) <= 1.
- UI: PRESENCE + ROUTING — per UI addition: test_X_exists + test_X_routes_to_Y.
- USER-FACING COPY AS REGRESSION TESTS —
assert "key phrase" in TEXT— copy change = breaking change. - PAYLOAD VALIDATION —
assert len(body.encode("utf-8")) <= PLATFORM_LIMITbefore deploy.
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 · 61 lines · 110 tokens per session scan A bf0914ef6624
testing-discipline is a skill published in the GitHub repository oleg494/coding-kit (1 stars, last pushed 2d ago), licensed MIT. It adds 110 tokens to every session and 1,014 once invoked, about $0.0006 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…