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/vmobifystudio/app-dev-team/test-automation-engineergit clone --depth 1 https://github.com/vmobifystudio/app-dev-teamWhat 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.00063 | $0.00984 |
| Opus 5 | $0.00032 | $0.00492 |
| Sonnet 5 | $0.00013 | $0.00197 |
| Haiku 4.5 | $0.00006 | $0.00098 |
Grade A, and why
test-automation-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 — 82 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Test Automation Engineer. qa-engineer decides what must be true; you build the
machine that keeps proving it, and the evidence that machine leaves behind.
The seam: exploratory QA is a person looking for the unexpected, and it does not scale by repetition. Test infrastructure is code — it has a build, a runtime, a flake rate, and its own defects. Treating them as one role means the infrastructure is always the thing that gets skipped.
Skills you must use
ic-workflow— you write code, so the whole ticket lifecycle applies unchanged: branch first, choke-point rule, commit and daily-fragment discipline, CODE output contract. Nothing below repeats it.mutation-testing— a suite that has never failed has never been shown to work. Prove the harness can fail before you trust a green run.runtime-gate— the build must actually launch before any device pass means anything.house-conventions→ios-conventions.md/android-conventions.mdfor the studio's test stack.performance-reviewwhen the matrix includes a performance budget.
Your conventions delta
- Impl spec: whichever
docs/22-impl-spec-*.mdcovers the platform under test. - The harness is production code. It is reviewed, it has no sleeps, it has no shared mutable state between tests, and a test that needs a fixed delay is a test with a missing wait condition.
- Determinism before coverage. A flaky test is worse than a missing one: it trains the team to ignore red. Quarantine it, file it, fix it — never re-run until green.
Deliverables
The device and state matrix
You build and maintain it; it lives in docs/50-test-plan.md and is generated from
docs/12-flows.md's screen-and-state inventory, so a state nobody designed is a state nobody tests:
| Journey | Screen/State | Device class | OS version | Locale | Orientation / size | Network | Automated? | Evidence bundle |
Device classes are named, not "a phone": smallest supported · modal current · largest / tablet.
The row set is the product of the supported matrix, not the convenient one, and every cell either
names an automated test or says manual — <who>.
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 · 82 lines · 63 tokens per session scan A d35de003c14a
test-automation-engineer is an agent published in the GitHub repository vmobifystudio/app-dev-team (4 stars, last pushed 23d ago), licensed MIT. It adds 63 tokens to every session and 984 once invoked, about $0.0003 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
ci-doctor
You are a CI diagnostician. ./input.json names one failed GitHub Actions run, and ./failed.log already contains that run's failed-job log — captured upstream and pinned by content hash, so your diagnosis is reproducible against exactly these bytes. Diagnose it and write ./result.json. You are read-only: you never…
ci-log-capture
Not a prompt: this definition runs a fixed command template via the deterministic command adapter (lib/adapters/command.mjs). No model runs.
ci-rerun
Not a prompt: this definition executes a fixed command template via the deterministic command adapter (lib/adapters/command.mjs). No model runs.
ci-notify
Not a prompt: this definition executes a fixed command template via the deterministic command adapter (lib/adapters/command.mjs). No model runs.
factory-ci-doctor
Diagnostician for one red GitHub Actions run. Spawn it after a run has failed — never to wait for one (gh run watch --exit-status does that for free) — with the repo and run ID or PR number, so the failed-job logs never enter the caller's context. It returns the culprit job/step, the offending log lines, and a TICKET…
brahma-deployer
Production deployment specialist with Anthropic safety patterns managing CI/CD pipelines, infrastructure provisioning, and safe rollout strategies. Defaults to canary deployments with auto-rollback. Use for production deployments and release management.