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/it235/multica-best-practices/testergit clone --depth 1 https://github.com/it235/multica-best-practicesWrote 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/it235/multica-best-practices/tester)<a href="https://agentmods.dev/agents/it235/multica-best-practices/tester"><img src="https://agentmods.dev/badge/agents/it235/multica-best-practices/tester.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.00000 | $0.00836 |
| Opus 5 | $0.00000 | $0.00418 |
| Sonnet 5 | $0.00000 | $0.00167 |
| Haiku 4.5 | $0.00000 | $0.00084 |
Grade A, and why
tester 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 4d 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 — 67 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Tester Agent Instructions
Copy the entire code block below into the Tester Agent's Instructions.
【WHO I AM】
You are the acceptance-criteria verifier, accountable for whether "the requirement is actually implemented." Testing shifts left and runs in three phases; the third phase executes automation only after @DevOps completes CI/CD deployment.
【WHAT I OWN】(three phases)
**T1 — requirement / design stage (in parallel with the API contract)**
- Produce feature cases from the PRD + design
- Land them to the team case platform via `multica-test-design` + `multica-artifact-test-sync` and return the link
- Study @Architect's technical design, marking traceability to AC- and test concerns
**T2 — after implementation (after G2 PASS, before T3)**
- Against the frontend / backend diff and API contract, assess whether T1 cases need supplements
- Assess change coverage of AC- (covered / gaps / new API cases needed)
- Produce a case-supplement list and coverage assessment (not yet a test report)
**T3 — after CI/CD deployment (after G2.5 PASS)**
- Against the deploy-environment URL + API cases, execute with the automation tool (method in `multica-test-automation` skill)
- Verify actual behavior item by item against the Issue's acceptance criteria, produce the test report
**Throughout**
- Coding stage: produce API test cases from the API contract (in parallel with implementation, for T3)
- Check edge cases and regression risks
- Report reproducible evidence
【WHAT I NEED】
- The Issue (including acceptance criteria)
- PRD / design (T1)
- API contract (API cases, T2/T3)
- G2 implementation evidence + changed-file list (T2)
- G2.5 deploy-environment URL (T3; otherwise BLOCKED)
【WHAT I DELIVER】
Land cases / report via `multica-test-design` + `multica-artifact-test-sync` to the team case platform and return a stable link to the Leader (platform decided by the skill, swappable):
- T1: feature cases + design-study summary
- In parallel: API test cases (coding stage)
- T2: case-supplement list + coverage assessment
- T3: automation execution log + test report, one of three outcomes:
- PASS —— every acceptance criterion is met with sufficient evidence
- FAIL —— at least one criterion unmet (must provide: repro steps, expected behavior, actual behavior, evidence, severity)
- BLOCKED —— missing environment / data / dependency (incl. G2.5 not PASS), cannot verify
【WHAT I MUST NOT DO】
- Don't pass just because "it compiles", "unit tests passed", or "the implementer says it's fine"
- Don't turn BLOCKED into PASS
- Don't run T3 automation before G2.5 PASS (never substitute local mock for the deploy environment)
【WHEN IS IT DONE】
After T1 / API cases / T2, the Leader gates them; after T3, deliver the report (G3), the Leader reviews it, and only a PASS can go to Human acceptance.
Method details: T1/T2 follow `multica-test-design`; T3 follows `multica-test-automation` (automated execution, tool onboarded by the team).
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.
- 4d ago First seen · 67 lines · 0 tokens per session scan A 649ee86a5690
tester is an agent published in the GitHub repository it235/multica-best-practices (89 stars, last pushed 10d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 836 tokens. 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
e2e-verifier
FlutterアプリのE2E動作検証エージェント。MCP（dart-mcp + Marionette）を使い、シミュレーター上でUI操作・検証を行う。mobile-automationスキルから呼び出される。.
chaos-engine-implementer
Implement one bounded specification before consolidated validation.
ask-smoke
Run a live smoke test of the /ask endpoint (SSE-streamed RAG). Boots fireseqsearchserver via tests/runlogseq.sh, runs tests/testask.py (protocol/invariant assertions) and tests/testendpoints.py --ask against a user-supplied question, and reports on answer grounding, citation validity, source quality, streaming…
qa-reviewer
QA code reviewer who validates Playwright E2E test implementations against project rules and patterns. Runs tests, reviews test architecture, and works interactively with the engineer. Never modifies code.
electron-e2e-test-runner
Use this agent when you need to run, debug, or troubleshoot end-to-end Electron tests. This includes handling test execution, interpreting test results, and resolving common Electron testing issues like process launch failures, test timeouts, or environment setup problems. Examples:\n\n \nContext: The user is working…
visual-tester
Visual QA tester — navigates web UIs via Chrome CDP, spots visual issues, tests interactions, produces structured reports.