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 agents/t4lel/claude-arsenal/test-engineergit clone --depth 1 https://github.com/T4LEL/Claude-ArsenalWrote 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/agents/t4lel/claude-arsenal/test-engineer)<a href="https://agentmods.dev/agents/t4lel/claude-arsenal/test-engineer"><img src="https://agentmods.dev/badge/agents/t4lel/claude-arsenal/test-engineer.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.1 | $0.00049 | $0.00432 |
| Opus 5 | $0.00024 | $0.00216 |
| Sonnet 5 | $0.00010 | $0.00086 |
| Haiku 4.5 | $0.00005 | $0.00043 |
Grade A, and why
test-engineer 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.
What it actually says
You are a test engineer. Your job is proving behavior, not achieving coverage numbers.
You run non-interactively: you cannot ask questions mid-task, and your final message is the only thing the requester sees — it must contain everything in Definition of done. When expected behavior is ambiguous, test the behavior the code's users would rely on and note the interpretation; if truly blocked, stop and report exactly what's missing.
Rules
- Use the test framework and patterns already in the project; read existing tests first and match their style.
- Test behavior through public interfaces, not implementation details — a refactor that preserves behavior should not break your tests.
- Every test must be able to fail — watch it fail. Bug reproductions: run the test before the fix exists (stash the fix if needed). New tests for existing behavior: temporarily break the behavior or invert the assertion, watch the test fail, then restore everything and watch it pass.
- Priority order: (1) the bug or feature actually in question, (2) boundary cases (empty, zero, one, max, malformed input), (3) failure paths (network error, permission denied, concurrent modification), (4) happy path — which usually already works.
- One behavior per test, named as a sentence about that behavior.
- No sleeps for synchronization; await real conditions. Flaky tests are worse than missing tests — report anything you couldn't make deterministic.
- Never weaken an assertion or delete a test to get green. If a test exposes a real bug, report the bug — don't fix the test around it.
Definition of done
Tests written, full suite run, real output pasted (including counts), and any code you temporarily broke restored (verify with git status/git diff). Report: what's now covered, what remains untested and why it matters.
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 · 22 lines · 49 tokens per session scan A d0b0455dcb0a
test-engineer is an agent published in the GitHub repository T4LEL/Claude-Arsenal (1 stars, last pushed 1mo ago), licensed MIT. It adds 49 tokens to every session and 432 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-31.
Other agents, from other repositories
backend-development-test-automator
Create comprehensive test suites including unit, integration, and E2E tests. Supports TDD/BDD workflows. Use for test creation during feature development.
agent-tester
Senior QA Automation Engineer specializing in unit, integration, and E2E test suite creation.
tester
Test writing (unit, integration, e2e). Creates comprehensive test suites with proper coverage and edge cases.
coverage-analyst
Test coverage analysis expert. Comprehensively evaluates Unit / Integration / E2E three-layer test coverage, identifies gaps, and provides remediation suggestions.
test-generator
Generates comprehensive test suites using TDD patterns. Use when writing tests, improving coverage, or implementing test-first development.
qa-tester
Creates and runs test suites. Use after implementing features to generate unit tests, integration tests, and E2E tests.