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/claude-code-workflows/testing-principlesnpx skills add shinpr/claude-code-workflows --skill testing-principlesgit clone --depth 1 https://github.com/shinpr/claude-code-workflowsWhat 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.00040 | $0.00811 |
| Opus 5 | $0.00020 | $0.00405 |
| Sonnet 5 | $0.00008 | $0.00162 |
| Haiku 4.5 | $0.00004 | $0.00081 |
Grade A, and why
testing-principles 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 — 58 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Language-Agnostic Testing Principles
Test-Driven Development (TDD)
Use this cycle for new or changed executable behavior and reproducible bug fixes. For a behavior-preserving refactor, first confirm existing tests pass or add passing characterization tests, then refactor and rerun the same regression evidence.
RED: confirm the new test fails for the intended reason. GREEN: implement the smallest passing change. REFACTOR: improve structure while the test remains green. VERIFY: run the repository's applicable regression checks.
Quality Requirements
- Treat coverage as a diagnostic signal for finding untested areas, not a target — a target gets gamed into trivial tests (Goodhart's Law)
- Concentrate tests on critical paths, business logic, and behavior whose regression would matter
- Prioritize meaningful assertions over the coverage number; any CI threshold is the project's config, not a quality goal in itself
- Use project-configured speed budgets when present. Otherwise investigate test speed only when observed feedback or CI cost is material to the current outcome; retain slower tests when their proof boundary requires it
Test Design Rules
- Structure each test as Arrange, one Act, and Assert; multiple assertions may prove one behavior.
- Follow the repository's test naming convention and name the condition and observable outcome.
- Exercise behavior through a public or integration boundary. Assertions verify return values, outputs, errors, or state changes rather than private implementation.
- Use independently derived literal, property, approved snapshot, or fixture expectations. An implementation-derived oracle cannot detect the same implementation defect.
- Keep each test's expected outcome unconditional. Table-driven or property-based cases are acceptable when each case is reported distinctly and uses an independent oracle.
- Cover accepted boundary and error behavior; derive cases from the contract instead of adding generic edge-case permutations.
- Each test creates and cleans up its own state, passes in isolation and any order, and controls time or randomness that affects its result.
- Keep tests executable. Fix or remove tests that no longer describe accepted behavior; restore tests disabled only to bypass a failure.
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 · 58 lines · 40 tokens per session scan A 3da24a71e449
testing-principles is a skill published in the GitHub repository shinpr/claude-code-workflows (675 stars, last pushed 4d ago), licensed MIT. It adds 40 tokens to every session and 811 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
dynamic-workflows
Ultracode / Max-Parallel mode — dynamic workflows fan work out across tens–hundreds of adversarially-verified parallel subagents for large, decomposable jobs (codebase-wide audits, big migrations, cross-checked research). Opt-in; higher token spend.
cost-efficiency
Smart Routing — the DEFAULT CCGodMode routing policy. Risk-based, minimal-agent paths that preserve required safety gates for the changed scope.
agent-teams
Experimental Agent Teams orchestration — run CCGodMode agents as parallel teammates with SharedTaskList coordination (requires CLAUDECODEEXPERIMENTALAGENTTEAMS=1).
quality-gates
Parallel quality gate orchestration — @validator and @tester run simultaneously after @builder, with mandatory decision matrix for pass/fail routing.
sprint-planning
Plan-first orchestration (ADR-004): comprehensive PLAN.md, sprint files with write-scope ownership, preflight checks, serialized integration, and the release sprint. Use for any non-trivial or multi-part request BEFORE dispatching agents.
workflows
CCGodMode Full-Gates workflow definitions — used for high-risk work and when Smart Routing escalates. Default routing is Smart Routing (skills/cost-efficiency/).