What the agent does
The agent starts from the Linear issue and the repository in its own sandbox, and reads the profile LiveView before adding inputs. In a codebase like fly-apps/live_beats (Phoenix ~> 1.7.1, LiveView from the Phoenix GitHub override, Elixir ~> 1.12), lib/live_beats_web/live/profile_live.ex streams songs with MediaLibrary.list_profile_songs(profile, 50) into #songs, with upload and delete flows but no search box. LiveBeats.MediaLibrary.Song has title and artist fields. Tests in test/live_beats_web/live/profile_live_test.exs cover upload and delete on the owner's profile. config/test.exs points at Postgres database live_beats_test on localhost.
It adds a search input on the profile template with phx-change and a debounce attribute, holds the query in socket assigns, and filters the streamed songs by title and artist (either in list_profile_songs with a query argument or in the LiveView before stream). Empty query restores the full list. It does not disturb presence, the player switch_profile buttons or the upload modal.
It extends profile_live_test.exs with LiveViewTest cases: type a query and assert non-matching rows disappear from the render, clear the query and assert they return. The agent starts Postgres in the sandbox, runs mix test, and fixes flaky stream assertions against the #songs table markup.
Last, it opens a pull request that links the Linear issue, names the LiveView and MediaLibrary touches and points reviewers at the new search tests.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Linear issue labeled agent says: \"Add Live Search to a Phoenix LiveView Page. Add a search box on the profile page that filters songs by title and artist as the user types, debounced, using phx-change.\" Do the work in this repository, add tests for it, run mix test with Postgres started in the sandbox, and open a pull request that links back to the issue.",
"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 on its own branch. The description notes the profile page listed up to 50 songs with no filter, then shows the debounced phx-change search and how filtering applies to title and artist. The Linear issue is linked.
The transcript keeps Postgres startup, mix test and any compilation warnings. Failures from stream DOM ids or missing assigns stay visible in the session record.
Before merging, a reviewer checks debounce timing, case-insensitive matching if promised, that uploads still work with a query active and that the new tests fail when the filter handler is removed.
Run it on every Linear issue labelled agent
In the console, an automation with a linear trigger on linear.issue.labeled and the label agent starts one run per labelled issue, with the issue as its context, in the Project's repository. Changes made by an app integration never fire it, so the agent's own updates do not start new runs.
From your own server, the same run is one POST /o/{org}/sessions per issue: put the repository in resources, and add the issue's https://linear.app/<workspace>/issue/<ID> URL there too to have Rush read it through your Linear connection into the prompt. A webhook on the API key posts run.completed or run.failed when the turn finishes, with the session_url to read the result.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
LiveView tests need a migrated Postgres database and the project's test support fixtures. In a Rush sandbox the agent starts Postgres, runs mix test against live_beats_test and keeps the output, so search regressions do not depend on a developer's local Docker Compose state.
Labelling the Linear issue is enough to get a PR with LiveViewTest proof. Several LiveView issues can run at once in separate sandboxes and branches, up to the key's max_concurrent limit.
Frequently asked questions
Is filtering server-side or only in the browser?
Server-side through the LiveView (phx-change). The agent filters assigns or the MediaLibrary query and restreams #songs; it does not add a client-only JS filter that drifts from the server list.
Does search include transcripts?
The issue asks for title and artist. Transcript text stays out of the filter unless a follow-up issue expands it.
Will it break the 50-song cap?
It keeps the existing list_profile_songs(profile, 50) limit unless the PR explicitly raises it. Search filters within that loaded set or pushes the query into the SQL limit consistently; the PR states which.
Why Postgres in the sandbox?
Because config/test.exs uses the Postgres adapter and Ecto.Adapters.SQL.Sandbox. SQLite would not match how this app's tests are written.