What the agent does
The agent traces the feed before wiring a gesture. In obytes/react-native-template-obytes, src/features/feed/feed-screen.tsx renders Shopify's FlashList, not a React Native FlatList. Its usePosts() call currently reads data, isPending and isError, and the list uses EmptyList for its initial loading state. The change extends that list with the refresh handler and native indicator rather than replacing the list or introducing a second feed-fetching mechanism.
src/features/feed/api.ts defines usePosts through react-query-kit, with the query key ['posts'] and the existing Axios client requesting posts. src/lib/api/provider.tsx supplies a TanStack QueryClient. The agent uses the query's refetch operation and keeps that cache as the source of feed data. It distinguishes the initial request, a user-requested refresh and any background fetching so the native refresh indicator has a defined lifetime instead of spinning whenever any query happens to run.
The tests exercise a refresh against a controlled test service and the real query path. They hold the response long enough to observe the indicator, then verify that new data appears and the indicator clears after settlement. A rejected refresh must also release the indicator and follow the screen's error policy. The agent checks empty and already-loaded feeds separately, since preserving visible content during a refresh differs from the initial ListEmptyComponent path.
package.json declares pnpm@10.12.3, Expo ~54.0.32, React Native 0.81.5, lint, type-check and a Jest test script. src/lib/test-utils.tsx imports FlashList's Jest setup, which is relevant when mounting this feed. The agent runs pnpm lint, pnpm type-check and pnpm test --runInBand. The repository also declares Maestro flows, but JavaScript tests alone do not establish the feel of a native gesture; any device check is reported separately.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "A Linear issue labeled agent asks for pull to refresh on the feed screen using the existing React Query data path and native refresh indicator. Read src/features/feed/feed-screen.tsx, its usePosts hook and the QueryClient provider first. Preserve the existing FlashList and query cache. Define which state represents a user refresh, invoke the existing refetch operation and ensure the indicator ends after success or failure without confusing initial loading with refreshing. Add tests using the real query hook and a controlled test service, including updated rows, empty feed and rejected refresh behavior. Run pnpm lint, pnpm type-check and pnpm test --runInBand. Open a pull request linking the Linear issue URL supplied in the input. Distinguish recorded JavaScript checks from any native-device verification; never claim an emulator or device check that did not run.",
"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
The result is a PR with a focused feed-screen change and tests for the refresh lifecycle. It explains how the query is refetched, which state drives the indicator, and what happens to existing rows if the refresh fails. Any change to the feed's error display appears explicitly in the diff rather than being hidden inside the refresh wiring. The existing API client remains responsible for requests.
A reviewer checks that the handler uses the same posts query and that the indicator returns to idle on every completion path. The PR includes lint, TypeScript and Jest results with their commands, plus any separate native evidence. If the sandbox has no usable device runtime, that limit is stated plainly. A passing component test supports the data and state behavior; it does not prove that the gesture feels right on every supported device.
Run it on every Linear issue labelled feed-refresh
Configure your own Linear webhook receiver to select feed-refresh issues and place their body and URL into the string input. It sends the request with the installed GitHub repository in resources and an API key in the authorization header. Give each issue revision a stable Idempotency-Key so a repeated delivery does not create parallel implementations. The issue should name the screen and its expected error behavior before the agent starts.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
A refresh change touches UI state, network timing and cached data even when the diff is small. Rush runs that investigation in a separate sandbox, where the agent can run the repository's checks and keep their output without changing your local Expo session. Your working copy stays on its current task while the feed change comes back as a branch for review.
Independent feed tasks can run on separate repositories without sharing a Metro process or query test setup. Each session's transcript records the commands and results, so a reviewer can distinguish a verified state transition from an untested device assumption. After the turn finishes, send a follow-up asking for a different refresh-error policy and the parked sandbox resumes with the same working context.
Frequently asked questions
Does the example use FlatList?
The inspected feed uses FlashList from @shopify/flash-list. The agent extends that component and retains its current card rendering. Replacing the list implementation would be a separate change from adding refresh.
Will pull to refresh bypass the query cache?
The prompt requires using the existing usePosts query's refetch operation. A separate fetch call followed by local component state would split ownership of the feed data. The reviewer can verify the single data path in both the screen diff and the tests.
What happens when the refresh request fails?
The native indicator must stop when the refresh settles, including rejection. The issue should specify whether previously loaded rows stay visible and where the error appears. The PR explains and tests that policy instead of quietly changing the screen's existing error branch.
Do the tests prove the native gesture works?
Component tests can verify the handler, query execution and indicator state. A native gesture check requires a usable device or emulator and is separate evidence. The final answer identifies which of those checks actually ran.