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/aethrox/doctrine/test-strategynpx skills add aethrox/doctrine --skill test-strategygit clone --depth 1 https://github.com/aethrox/doctrineWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/aethrox/doctrine/test-strategy)<a href="https://agentmods.dev/skills/aethrox/doctrine/test-strategy"><img src="https://agentmods.dev/badge/skills/aethrox/doctrine/test-strategy.svg" alt="Measured on agentmods" height="20"></a>What 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.00113 | $0.01175 |
| Opus 5 | $0.00056 | $0.00588 |
| Sonnet 5 | $0.00023 | $0.00235 |
| Haiku 4.5 | $0.00011 | $0.00118 |
Grade A, and why
test-strategy 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 5d 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 — 48 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test Strategy
Where a test gets its data from and what happens when it goes flaky are suite-level policies, decided once and applied consistently, not improvised per test or per failure. This skill covers the decisions that sit above the individual red-green-refactor cycle (see tdd for that): test data sourcing, flaky-test handling, and the integration/e2e boundary.
Phase 1: Test data
Default to synthetic data generated at test runtime: factories or fixtures that build exactly the shape a test needs, checked into the test itself or a shared factory module. This is fast, requires no external data source, and its content is fully under the test's control (see tdd Phase 2, expected values need an independent source of truth, and hand-built synthetic data is that source).
Reach for a production data snapshot only when synthetic data genuinely can't reproduce the bug pattern or edge case under test; real-world data has irregularities and relationship patterns synthetic generators tend to smooth over. When a snapshot is used:
- Anonymize before it leaves production, never after: mask or replace identifying fields (names, emails, IDs) while preserving format and referential integrity (a masked customer ID still matches the same masked customer's masked orders), so the data stays realistic enough to be useful without staying identifying.
- Version the snapshot alongside the code that depends on it, the same way
tdd's FIRST properties require a test to be repeatable; a snapshot that silently changes between CI runs breaks that guarantee. - Treat it as the exception, not the default: a suite that leans on production snapshots for routine tests has usually skipped building proper factories, and inherits every compliance and staleness problem synthetic data doesn't have.
Phase 2: Flaky test policy
A test that fails intermittently with no code change is not evidence of a real bug until proven otherwise, but it also cannot be allowed to sit red-flaking-green forever; it trains people to ignore CI failures, which is worse than not having the test.
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.
- 5d ago First seen · 48 lines · 113 tokens per session scan A 4fca1b617735
test-strategy is a skill published in the GitHub repository aethrox/doctrine (18 stars, last pushed 24d ago), licensed MIT. It adds 113 tokens to every session and 1,175 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-30.
Other skills, from other repositories
ce-dogfood
Hands-off, diff-scoped browser QA of the active branch: maps user flows, drives a real browser, autonomously fixes small breakages with regression tests and commits, judges experience against product personas, and writes a durable dogfood report. Manual invocation only.
e2e-test
Skill "e2e-test" from maximhq/bifrost, covering playwright e2e testing, usage, workflow overview, auto-update workflow (sync mode) and step 0: detect what changed.
ce-test-browser
Run browser tests for pages affected by the current branch or PR. Use when asked to run or check browser tests for the current change.
harness-test-writer
Add regression test cases to the Bifrost provider harness (the Postman collection run via make run-provider-harness-test) based on a merged PR or a GitHub issue. Fetches the PR/issue, traces the affected wire path in the codebase, checks existing harness coverage, designs cases following harness conventions, inserts…
ce-test-xcode
Test iOS apps in a simulator with XcodeBuildMCP. Use when iOS changes need simulator evidence before handoff.
mcp-inspector-testing
Validate Wassette changes end-to-end by running the MCP server with just and driving it with the MCP Inspector CLI over Streamable HTTP — listing tools, resources, and prompts, and calling tools. Use before committing server changes or when debugging tool exposure and behavior.