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/shinpr/agentic-code/testingnpx skills add shinpr/agentic-code --skill testinggit clone --depth 1 https://github.com/shinpr/agentic-codeWhat 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.00031 | $0.00618 |
| Opus 5 | $0.00015 | $0.00309 |
| Sonnet 5 | $0.00006 | $0.00124 |
| Haiku 4.5 | $0.00003 | $0.00062 |
Grade A, and why
testing 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 2d 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 — 82 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Testing Rules
Language-Specific References
Read a language reference only when the repository uses that language and the reference affects the current test or check:
- TypeScript/Vitest: references/typescript.md
Repository commands and established conventions take precedence over generic examples.
TDD Process
Use RED → GREEN → REFACTOR when a behavior change can be represented by a focused failing test.
RED
- Write or select a test that observes the required behavior.
- Run it and confirm the current implementation does not satisfy the new expectation.
- If the test already passes, inspect whether the outcome is already satisfied, the test observes the wrong boundary, or implementation work is still required elsewhere.
GREEN
Implement the smallest change that makes the focused proof pass while preserving current contracts and non-goals.
REFACTOR
Improve structure only where the current change supplies evidence that refactoring is needed. Keep the focused proof passing.
VERIFY
Run the focused proof and the repository's applicable established checks. Fix in-scope regressions before completion.
TDD is not required for documentation-only changes, pure configuration without executable behavior, disposable spikes, or a no-change conclusion. Add a test after an emergency fix when the test protects the reproduced failure from recurrence.
Test Boundary
Test observable behavior:
- public or shared contracts;
- outputs, errors, and persisted effects;
- required external calls or side effects;
- named interactions across components or processes.
Keep internal implementation details outside tests unless they are themselves an accepted contract.
Choose the narrowest sufficient level:
- unit or local check for isolated behavior;
- integration for a named interaction boundary;
- E2E for a complete journey required by the acceptance criterion.
Test Design
- Use clear setup, action, and observable expectation.
- Keep test data minimal and free of secrets.
- Prefer deterministic behavior and independent state.
- Mock external I/O at unit boundaries; use real internal collaborators when their interaction is the behavior under test.
- Reuse or extend existing representative coverage before adding another lane.
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.
- 2d ago First seen · 82 lines · 31 tokens per session scan A 4af3e0b47dcc
testing is a skill published in the GitHub repository shinpr/agentic-code (49 stars, last pushed 3d ago), licensed MIT. It adds 31 tokens to every session and 618 once invoked, about $0.0002 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-30.
Other skills, from other repositories
agent-release-manager
Agent skill for release-manager - invoke with $agent-release-manager.
agent-release-swarm
Agent skill for release-swarm - invoke with $agent-release-swarm.
agent-pagerank-analyzer
Agent skill for pagerank-analyzer - invoke with $agent-pagerank-analyzer.
agent-pseudocode
Agent skill for pseudocode - invoke with $agent-pseudocode.
agent-code-analyzer
Agent skill for code-analyzer - invoke with $agent-code-analyzer.
agent-performance-analyzer
Agent skill for performance-analyzer - invoke with $agent-performance-analyzer.