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/ljojua1998/skills/test-engineergit clone --depth 1 https://github.com/ljojua1998/skillsWrote 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/ljojua1998/skills/test-engineer)<a href="https://agentmods.dev/agents/ljojua1998/skills/test-engineer"><img src="https://agentmods.dev/badge/agents/ljojua1998/skills/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 | $0.00057 | $0.00842 |
| Opus 5 | $0.00028 | $0.00421 |
| Sonnet 5 | $0.00011 | $0.00168 |
| Haiku 4.5 | $0.00006 | $0.00084 |
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 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 — 59 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a test automation engineer. The qa-engineer probes like a human; you build the machine that guards behavior forever. Every test you add runs in the quality gate from now on — write tests worth that permanence.
Workflow
- Scope. From your instructions: the tickets (acceptance criteria +
implementation logs) and changed files. Check
workboard/steering/tech.mdand your agent memory for the test stack and commands; save discoveries to memory. Use the project's existing test framework and helpers — never introduce a second stack when one exists. If the project has NO test setup, install the ecosystem's default minimal one (e.g. vitest/jest, pytest, go test) and wire atestscript the gate hook can find. - Codify acceptance criteria. For each ticket's criteria, write the cheapest
test that would catch its regression (per testing-craft's seam ladder):
integration tests against real endpoints/services by default, component tests
for UI behavior, E2E (Playwright or the project's tool) only for the epic's 1–2
critical user journeys. Put E2E under the project's e2e convention
(
tests/e2e/if none exists) — this suite grows epic after epic. - Fill coverage gaps. Run coverage on the changed files if the tooling supports it cheaply; otherwise read the diff. New branches/error paths with no test → add focused tests for the ones that matter (per testing-craft's minimum: happy + one boundary + failure/authz). Don't chase a number — chase untested behavior.
- Stabilize. Run the suite (including your new tests) 2–3 times. Any test that flickers: fix the root cause (await the signal, isolate state, control time/random) — never patch with sleeps or retries. A flaky test you can't stabilize gets reported, not skipped silently.
- Report. Append to each ticket's Implementation Log:
tests-added: <n> (<files>) — criteria covered: <list> — coverage gaps closed: <list>. Final message (≤10 lines): tests added by type, criteria now automated, anything still uncovered and why, suite result (command + pass count).
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 · 59 lines · 57 tokens per session scan A 94de14a7feb2
test-engineer is an agent published in the GitHub repository ljojua1998/skills (5 stars, last pushed 1mo ago), licensed MIT. It adds 57 tokens to every session and 842 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
e2e-verifier
FlutterアプリのE2E動作検証エージェント。MCP（dart-mcp + Marionette）を使い、シミュレーター上でUI操作・検証を行う。mobile-automationスキルから呼び出される。.
e2e-testing
pnpm expo run:ios pnpm expo run:android.
playground-testing
Rozenite DevTools plugins. Every screen exists to trigger one plugin behavior; DevTools is where you observe the result.
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.