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 skills/jyotiraditya-chauhan/test-kit/react-native-testingnpx skills add jyotiraditya-chauhan/test-kit --skill react-native-testinggit clone --depth 1 https://github.com/jyotiraditya-chauhan/test-kitWrote 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/skills/jyotiraditya-chauhan/test-kit/react-native-testing)<a href="https://agentmods.dev/skills/jyotiraditya-chauhan/test-kit/react-native-testing"><img src="https://agentmods.dev/badge/skills/jyotiraditya-chauhan/test-kit/react-native-testing.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.00128 | $0.02744 |
| Opus 5 | $0.00064 | $0.01372 |
| Sonnet 5 | $0.00026 | $0.00549 |
| Haiku 4.5 | $0.00013 | $0.00274 |
Grade A, and why
react-native-testing 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 — 217 lines — stays where its author put it; the contents beside it link to each section on GitHub.
React Native Testing
Writes unit, component, and E2E-flow tests for React Native projects, covering Expo (managed and bare) and plain React Native CLI in one skill, branching on whichever is actually detected. Writing the test files is the deliverable. Running the suite and verifying it — including the fault-injection self-check — is a separate, optional step this skill offers but never runs without being asked. See Step 6.
Progress checklist
Copy this into your response and check items off as you go:
- [ ] 1. Detect stack (scripts/detect_stack.sh)
- [ ] 2. Audit project structure and existing test conventions
- [ ] 3. Ask the user what to test (layer + scope) — do not assume
- [ ] 4. State the test plan explicitly
- [ ] 5. Generate tests following AAA, boundary-only mocking
- [ ] 6. Report what was written; offer to run + verify — do not run yet
- [ ] 7. Only if asked: run tests, fault-injection self-check, report results
Step 1 — Detect stack
Run scripts/detect_stack.sh from the project root. It confirms this is a
React Native project (the script errors out and points to react-testing
if react-native isn't declared), identifies which of the three workflows
applies — Expo managed, Expo bare, or plain React Native CLI — and reports
the existing test runner preset, React Native Testing Library (RNTL),
state-management library, expo-router presence, E2E tooling, and test file
convention already in use.
The workflow determines the correct Jest preset: jest-expo for both Expo
managed and Expo bare, the plain react-native preset for RN CLI without
Expo. Never mix these up, and never introduce a second, competing test
runner into a project that already picked one.
Step 2 — Audit project structure
Before writing anything:
- Classify the target: a pure function (formatter, selector, hook logic with no native calls) vs a screen/component that renders and handles user interaction vs a native-module-touching piece of code (camera, location, clipboard, notifications). See reference/component-testing.md and reference/native-module-mocking.md.
- If
expo-routeris present, check whether the target is a route file underapp/. Route-level behavior (navigation, params, deep links) needsexpo-router/testing-library, not a plain component render — see reference/expo-router-testing.md. Never place a test file insideapp/itself; expo-router treats every file there as a route. - Match the existing test file convention (
__tests__/vs co-located*-test.tsx/*.test.tsx) from Step 1. - Identify the state-management library in use (Zustand, Redux Toolkit, Jotai, MobX, or none) from Step 1 — see reference/state-management.md for how to set up or bypass a real store per library.
- Flag critical paths — authentication, payment, any data-write operation — for elevated rigor even if the user's request was narrower. State this flag out loud; do not silently expand scope.
What ships with it
8 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 217 lines · 128 tokens per session scan A e1379f835199
react-native-testing is a skill published in the GitHub repository jyotiraditya-chauhan/test-kit (4 stars, last pushed 14d ago), licensed MIT. It adds 128 tokens to every session and 2,744 once invoked, about $0.0006 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 skills, from other repositories
test-flutter
Flutter App のテスト実行・静的解析・フォーマット・テスト記述ガイド.
setting-up-host-vs-device-tests
Use this skill to choose between host (Robolectric/JVM) and device (instrumentation) tests for Jetpack Compose, and to configure each correctly. Covers the androidHostTest (a.k.a. src/test/) vs androidDeviceTest (a.k.a. src/androidTest/) source set split, what each flavor can and cannot drive (RenderThread…
testing-strategy
适用：编写或审查 Dart 单测、Flutter Widget 测试、Route 测试、集成测试、Fake 或 Mocktail Mock。不适用：Kotlin/Swift 测试框架，也不替代生产实现。触发词：testWidgets、flutter test、Mocktail、Fake、Get.reset、integrationtest、coverage、flaky。.
flutter-tester
Use when creating, writing, fixing, or reviewing tests in a Flutter project. Covers unit tests, widget tests, integration tests, Riverpod provider testing, and Mockito mocking. Provides Given-When-Then patterns, layer isolation strategies, and test setup for GetIt, SharedPreferences, and FakeDatabase.
flutter-testing
Use when defining automated testing strategies, organizing test pyramids, or establishing test naming conventions across Flutter apps.
flutter-testing
Flutter + NestJS 多区域项目测试规范 — Flutter 单元测试（Notifier/Provider + ProviderContainer override）、widget 测试、golden 测试、★ flavor 条件编译测试（cn 不含 Firebase / overseas 不含 JPush 的静态与运行时验证）、多租户隔离测试、AI 扣费 refund 测试、NestJS service 单测（mock Prisma）、e2e（supertest + 测试库）、mocktail/jest mock 约定、覆盖率门禁。.