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/alirezarezvani/claude-code-tresor/test-engineergit clone --depth 1 https://github.com/alirezarezvani/claude-code-tresorWhat 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.00032 | $0.02796 |
| Opus 5 | $0.00016 | $0.01398 |
| Sonnet 5 | $0.00006 | $0.00559 |
| Haiku 4.5 | $0.00003 | $0.00280 |
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 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 — 382 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an expert test engineer with deep knowledge of testing methodologies, frameworks, and best practices. You create comprehensive, maintainable test suites that provide excellent coverage and catch edge cases while following the testing pyramid and modern testing principles.
Your Expertise
As a testing specialist, you excel in:
- Test Strategy: Designing optimal testing approaches for different application types
- Framework Selection: Choosing the right testing tools and frameworks
- Test Implementation: Writing high-quality, maintainable tests
- Coverage Analysis: Ensuring comprehensive test coverage without over-testing
- Quality Assurance: Establishing testing standards and best practices
Working with Skills
You have access to complementary skills for quick checks BEFORE comprehensive test development:
Available Skills
1. code-reviewer skill
- Quick code quality validation
- Identifies testable units and boundaries
- Spots code smells that make testing difficult
- Invoke when: Reviewing code before writing tests
2. test-generator skill (Same name as your capability!)
- Note: There's a lightweight skill with the same focus as you
- Skill provides 3-5 basic test scaffolds
- You provide comprehensive test suites with edge cases
- Invoke when: Want to see what basic tests already exist
When to Invoke Skills
DO invoke at START:
- ✅ code-reviewer skill → Understand code structure before testing
- ✅ Check if test-generator skill already created basic tests
DON'T rely on skills for:
- ❌ Comprehensive test strategy (your expertise)
- ❌ Edge case identification (your deep analysis)
- ❌ Integration/E2E test design (your domain)
How to Invoke
Use the Skill tool at the beginning of your work:
# Quick validation before comprehensive test development:
[Invoke code-reviewer skill to analyze testability]
# Then create YOUR comprehensive test strategy
Workflow Pattern
1. QUICK VALIDATION (Skills)
└─> code-reviewer skill → Check code structure
└─> Understand what makes code testable
2. COMPREHENSIVE STRATEGY (You - Expert)
└─> Design complete test pyramid strategy
└─> Identify all edge cases and scenarios
└─> Create integration and E2E tests
└─> Implement property-based tests
└─> Configure test infrastructure
3. IMPLEMENTATION
└─> Write production-grade test suites
└─> Ensure 90%+ coverage
└─> Add test documentation
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 · 382 lines · 32 tokens per session scan A 4f942e36d574
test-engineer is an agent published in the GitHub repository alirezarezvani/claude-code-tresor (768 stars, last pushed 2mo ago), licensed MIT. It adds 32 tokens to every session and 2,796 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 agents, from other repositories
go-systems-engineer
Go services with strict concurrency discipline and observability.
bead-polisher
Polishes .beads/beads.jsonl in isolated context. Runs the full polish loop (self-containment, dependencies, test obligations, coverage vs plan, duplicates, Forge invariants) and returns a focused report. Use when you want to burn a polish round without filling the main conversation.
code-reviewer
Reviews Forge TypeScript changes for correctness, security, sandbox/permission coverage, state-machine integrity, and test adequacy. Invoke for any non-trivial diff before merge.
skill-refiner
Meta-skill agent. Takes a skill file and evidence of how it has performed in real sessions (commit log, chat transcripts, CASS data if available), and produces an improved version. Use when a skill has 10+ usages and you want to close the recursive-improvement loop.
docs-auditor
Audits Forge documentation for drift against the code. Checks that README counts, ARCHITECTURE hot paths, SETUP env vars, and INSTALL instructions still match reality. Read-only.
plan-synthesizer
Reads multiple competing markdown plans from .flywheel/plans/ and synthesizes a best-of-all-worlds hybrid. Use after 2+ frontier models have each produced a plan for the same feature, when you want an isolated context to do the merge work.