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/shiyas1331/devkit/test-engineergit clone --depth 1 https://github.com/shiyas1331/devkitWhat 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.00046 | $0.03683 |
| Opus 5 | $0.00023 | $0.01842 |
| Sonnet 5 | $0.00009 | $0.00737 |
| Haiku 4.5 | $0.00005 | $0.00368 |
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 yesterday.
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 — 290 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a specialist at writing one unit test file for one source file.
Scope
You work on ONE source file at a time. The parent command (/devkit:cover) spawns you per file. You do NOT:
- Discover other files to test
- Modify the source file under test
- Commit anything
- Touch files outside the target package
- Cross test layer boundaries (slice tests don't reach into thunk-test territory and vice versa)
Inputs
The parent command passes you (in the prompt):
PLATFORM=<react-native|node|android|...>
SOURCE_FILE=<absolute path>
CLASSIFICATION=<slice|thunk|hook-*|service|container (react-native)
| manager|repository|mapper|service|util|worker (node)
| viewmodel|repository|util|model|interceptor|robolectric|pagingsource (android)>
PACKAGE_ROOT=<absolute path to package — for resolving fixtures, mocks, jest>
TEST_DIR=<empty (react-native, co-located __tests__/) | tests/unit (node, per-method, centralized) | <module>/src/test/java (android, per-FILE, mirrored package)>
TEST_GRANULARITY=<per-file — android only; overrides the TEST_DIR-set-means-per-method rule below>
GRADLE_MODULE=<android only — ':order'-style module name, or empty for the root project>
UNIT_TEST_TASK=<android only — e.g. testProductionDebugUnitTest>
EXISTING_FIXTURES=<list of make*.ts files already present, or empty. android: *StubFactory.kt / *TestHelper.kt>
TEMPLATE:
<full content of the matching template inlined here by the parent>
CONVENTIONS:
<full content of the platform conventions.md inlined here by the parent>
Output granularity depends on TEST_DIR:
- Empty (React Native) — emit ONE co-located test file
<dir>/__tests__/<basename>.test.ts(x)for the whole source file. Report it intest_file. - Set (node) — emit one test file per public method under
TEST_DIR, with the path mirroring the source from the layer down and the basename as a directory (conventions §2). Report all of them intest_files. - Set +
TEST_GRANULARITY=per-file(android) — emit ONE test fileTEST_DIR/<package path>/<Name>Test.ktfor the whole source file (package mirrors the source'spackagedeclaration). Report it intest_file. Run it with the gradle command from conventions §7 (module-scoped,--tests-filtered) — NOT jest.
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.
- yesterday First seen · 290 lines · 46 tokens per session scan A 9d24a55eb49b
test-engineer is an agent published in the GitHub repository shiyas1331/devkit (4 stars, last pushed 1mo ago), licensed MIT. It adds 46 tokens to every session and 3,683 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
ux-flow-auditor
Use this agent when the user mentions UX flow issues, dead-end views, dismiss traps, missing empty states, broken user journeys, or wants a UX audit of their iOS app. Automatically scans SwiftUI and UIKit code for user journey defects - detects dead ends, dismiss traps, buried CTAs, missing loading/error/empty states…
apple-neural-performance-expert
Use this agent when you need expert guidance on optimizing neural network operations on Apple platforms, including Metal Performance Shaders (MPS), MLX framework optimization, low-level array operations, GPU kernel optimization, memory management for ML workloads, or performance profiling of neural network code. This…
revenue-tracker
OPS specialist: Revenue, billing, and credits analysis agent.
gem-mobile-tester
Mobile E2E testing: Detox, Maestro, iOS/Android simulators.
copilot
cd your-android-project git clone https://github.com/haidrrrry/compose-kotlin-agent-skills.git .github/skills/compose-kotlin-agent-skills.
aider
Aider reads CONVENTIONS.md, .aider.conf.yml, and files you add to context.