What the agent does
The agent clones the app into its own cloud sandbox and starts from what the project already has. In an Expo app like obytes/react-native-template-obytes, package.json declares "packageManager": "pnpm@10.12.3", Expo ~54.0.32, React Native 0.81.5, Expo Router ~6.0.22, jest ^29.7.0 with the jest-expo preset and @testing-library/react-native ^13.3.3. jest.config.js maps @/ to src/, loads jest-setup.ts, and lists the packages in transformIgnorePatterns that Jest must still transform. Five files are tested today: button, checkbox, input and select under src/components/ui, and login-form under src/features/auth/components.
Then it lists what has no test and picks the screens and forms that carry logic. src/features/feed/add-post-screen.tsx builds a @tanstack/react-form form validated by a zod schema (title at least 10 characters, body at least 120), shows each field's error through getFieldError, and sets loading on the add-post-button while isPending or isSubmitting. feed-screen.tsx renders EmptyList while usePosts is pending and "Error Loading data" when it fails. post-detail-screen.tsx, settings-screen.tsx and onboarding-screen.tsx have no tests either. The agent writes one test file beside each, using the testID values the components already set (title, body-input, add-post-button).
It reuses the project's test helpers instead of writing new ones. src/lib/test-utils.tsx exports a render and a setup that wraps the tree in BottomSheetModalProvider and NavigationContainer and returns a userEvent instance, and jest-setup.ts and __mocks__/ already stub react-native-reanimated, react-native-mmkv, expo-localization, moti and @gorhom/bottom-sheet. The wrapper has no QueryClientProvider, and the feed hooks in src/features/feed/api.ts call an axios client built from Env.EXPO_PUBLIC_API_URL, so the agent adds a query client to the screen tests and answers the posts and posts/add requests at the HTTP layer, which lets each test drive a loading, empty, error or success state.
Finally it runs pnpm test, then pnpm run test:ci (Jest with --coverage), which is what .github/workflows/test.yml runs, and reads the coverage summary for the files it touched. Every test renders in Node through jest-expo, so no iOS simulator or Android emulator is involved. When a test fails because the screen has a real bug rather than a wrong test, the agent leaves the screen alone and reports it.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Write Jest and React Native Testing Library tests for the screens and form components in this Expo app that have none. Read jest.config.js, jest-setup.ts, __mocks__ and src/lib/test-utils.tsx first and reuse them. For each form, test the validation errors the schema produces, the submit button's loading state and the success and error messages; for each screen that fetches data, test the loading, empty, error and loaded states by answering the HTTP requests rather than mocking the screen's own hooks. Put each test beside its source as <name>.test.tsx and use the testID values the components already have. Run pnpm test and pnpm run test:ci, and open a pull request listing each new test file, what it covers and any bug a test found.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is a pull request with new *.test.tsx files beside the screens and forms they cover, such as src/features/feed/add-post-screen.test.tsx and feed-screen.test.tsx, plus a small change to src/lib/test-utils.tsx if a query client wrapper was needed. Its description lists each file, the states it covers, and any case where a test found real behavior that looks wrong, such as a success message with no navigation afterwards.
The check that counts is the repository's test.yml workflow, which runs pnpm run test:ci with coverage on the pull request and reports through the github-actions Jest reporter. The session's transcript keeps every pnpm test run from the sandbox with its output.
Before merging, a reviewer reads a few tests for what they assert. A good test here types into title, presses add-post-button, and checks the error text a user sees, rather than checking that a mock was called. They also check that no test depends on timing, since flaky screen tests are worse than none.
Run it on every new screen merged
A repository webhook on your server can send this request whenever a pull request that adds a file under src/app or src/features is merged, with the prompt naming the new files. One run per merge keeps each test pull request small and tied to the screen it covers.
With a webhook URL on the API key, Rush posts run.completed when the turn ends. Your handler can post the test pull request's link to the author of the original change, who knows best what the screen is meant to do.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Tests written without running them are guesses. In a Rush sandbox the agent installs the exact pnpm version from packageManager, runs pnpm install against pnpm-lock.yaml, and executes each new test until it passes for the right reason. The transforms in jest.config.js and the native module mocks either work there or fail visibly, the same as they would on CI.
The proof is the record and the checks: every pnpm test run with its output is in the transcript, and the pull request runs test:ci again on GitHub. Several feature folders can get tests at once, each in its own sandbox and branch, so a team can cover an app in parallel rather than one screen at a time.
Frequently asked questions
Do the tests need a simulator or an emulator?
No. jest-expo renders components in Node with the React Native test renderer, and the template's mocks replace native modules such as MMKV and Reanimated. Device-level flows belong in the Maestro flows under .maestro, which this job does not change.
Will it mock my API hooks?
The prompt asks it to answer the HTTP requests instead of replacing the hooks, so the test exercises react-query-kit, axios and the screen together. A test that mocks the hook only proves the mock returns what the test expected.
Does it work with npm or Yarn instead of pnpm?
Yes. The agent reads packageManager and the lockfile and uses the matching tool. The prompt names pnpm because this template uses it; change the commands in the prompt to match your project.
What if my project has no Jest setup at all?
Ask for it in the prompt. The agent adds jest-expo, @testing-library/react-native, a jest.config.js and the mocks the app's native modules need, and the pull request explains each addition.