What the agent does
The agent clones the repository into its own cloud sandbox and reads how the panel is put together before it writes anything. In a Filament app like filamentphp/demo, composer.json requires filament/filament ^5.0 on Laravel 12 with Pest 3 for tests, and the test script runs pest --parallel followed by phpstan analyse. The orders table is not defined in the resource itself: app/Filament/Resources/Shop/Orders/Tables/OrdersTable.php builds it in a static configure() method, and its only bulk action today is a DeleteBulkAction inside groupedBulkActions().
Filament already has the export plumbing, and the demo already uses it. app/Filament/Exports/Shop/BrandExporter.php extends Exporter with a list of ExportColumns and a completion notification, ListBrands.php wires it up through ExportAction::make()->exporter(BrandExporter::class), and the migrations include the exports, job_batches and notifications tables the exporter needs. So the agent follows the same pattern: a new app/Filament/Exports/Shop/OrderExporter.php with columns for number, customer.name, status, total_price, shipping_price, shipping_method and created_at, matching the fields on the Order model and the columns the table already shows.
Then it adds ExportBulkAction::make()->exporter(OrderExporter::class) beside the delete action in OrdersTable.php, limited to CSV with ->formats([ExportFormat::Csv]). The admins-only part needs a decision, because the repository has no notion of an admin: User::canAccessPanel() returns true for everyone and the users table has no role column. The agent reads that, picks the smallest change that makes the rule enforceable, such as an is_admin boolean with a migration and a factory state, puts ->visible() on the action, and writes the choice and its alternative into the pull request description so the reviewer can swap it for the team's real authorization.
Tests go where the existing ones are. tests/Filament/Resources/Shop/Orders/Pages/ListOrdersTest.php already drives ListOrders through Livewire with TestAction::make(...)->table($record), and tests/Pest.php signs in a fresh user before every test in Filament. The agent adds cases that an admin can call the bulk export on selected orders and that a non-admin cannot see it, runs composer setup steps the tests need (an .env, an app key, the SQLite database), runs vendor/bin/pest, and fixes what fails before it pushes a branch.
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 a Bulk Export Action to a Filament Table. Add a bulk action on the orders table that exports the selected orders to CSV with Filament's exporter, available to admins only.\" Do the work in this repository, add tests for it, run the Pest suite, and open a pull request that links back to the issue.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
},
{
"url": "https://linear.app/your-workspace/issue/ENG-42"
}
]
}- 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. In a panel shaped like the demo, the diff adds app/Filament/Exports/Shop/OrderExporter.php, changes app/Filament/Resources/Shop/Orders/Tables/OrdersTable.php to register the export next to the existing delete action, and extends ListOrdersTest.php. If the app had no admin flag, the migration, the User change and the factory state that introduce one are in the same diff, called out in the description. The description quotes the issue and links back to it.
A reviewer checks four things before merging: the exported columns are the ones the business wants in the CSV (and nothing sensitive from the customer record slipped in), the visibility rule matches how the team already decides who is an admin, the export runs on the queue the app uses in production rather than only the sync queue phpunit.xml sets for tests, and the new Pest cases fail if the action is removed or made visible to everyone.
The session keeps the record behind the pull request: every command the agent ran with its output, from composer install to the Pest run, and its reasoning about the admin rule. The session read returns the repository and the pull request, so the run and its result stay linked.
Run it on every Linear issue labelled agent
In the console, add an automation on the Project with a Linear trigger on linear.issue.labeled, filtered to the agent label. Each issue that gains the label starts one run with the issue as its context, in its own sandbox, and opens its own pull request. Changes made by an app integration never fire the trigger, so only a person adding the label starts work.
Without an automation, a server that receives Linear's webhook can send the same request with the issue's URL in resources. Set a webhook URL on the API key and Rush POSTs run.completed when each turn finishes, with the session_url to read the pull request from.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
A Filament change like this needs PHP 8, Composer, a migrated database and a seeded app key before a single Pest test can run, and the demo's test script runs PHPStan straight after Pest. Each run on Rush sets that up in its own sandbox, runs the real commands and keeps their output, so the reviewer reads the actual test run instead of a claim that tests passed.
Labelled issues do not wait for each other. Ten small admin-panel requests labelled in one triage session become ten runs, each in its own sandbox on its own branch, each ending in a pull request with checks, and nobody has to switch their checkout between them.
Frequently asked questions
My app has no admin role. What does the agent do with "admins only"?
It reads how panel access is decided, in canAccessPanel() and any policies, and uses the existing rule if there is one. If there is none, as in the Filament demo, it adds the smallest enforceable rule and says so in the pull request, so the reviewer can replace it with the team's own authorization before merging.
Will it use Filament's exporter or write its own CSV code?
The issue asks for Filament's exporter, and the agent follows the pattern already in the codebase: an Exporter subclass with ExportColumns, attached through ExportBulkAction. That keeps the export on Filament's queue jobs and its completion notification instead of a hand-written stream.
Exports run on a queue. Does the test actually produce a file?
The demo's phpunit.xml sets QUEUE_CONNECTION to sync, so the export job runs inside the test. The agent's tests assert that the action can be called on selected records and is hidden from the wrong users; the reviewer should still try one export on a real queue worker before release.
Does it run PHPStan too?
The prompt asks for the Pest suite, and the agent runs it. When the repository's composer test script also runs phpstan analyse, as the demo's does, the agent can run that script instead, and the record shows which command ran and what it printed.