What the agent does
The agent reads the failed job first. From the workflow_run event it runs gh run view <run id> --log-failed and names the job, because a Phoenix repository like hexpm/hexpm fails in different ways per job. .github/workflows/main.yml has format, which runs mix compile --warnings-as-errors, mix format --check-formatted and mix ecto.setup to prove the seeds still load; test-hexpm, which runs mix test with MIX_ENV=test; test-hex, which clones the Hex client at main, v2.5 and v2.4 and runs its suite with --include integration against this server; and docker, which builds the image. A compile warning, a formatting diff, a broken seed, an ExUnit failure and a client-compatibility break are five different fixes, and the agent quotes the block that says which one it has.
Then it matches the toolchain. The workflow pins Elixir 1.20.4 on OTP 29.1 and starts postgres:18 with user, password and database all postgres; mix.exs requires Elixir 1.20 and depends on Phoenix ~> 1.6, ecto_sql, postgrex, Oban ~> 2.23 and Sentry ~> 13.0. The test alias runs ecto.create --quiet, ecto.load --skip-if-loaded, ecto.migrate and then test, so the database schema comes from priv/repo/structure.sql and needs the pg_trgm and pgcrypto modules the README names. test/test_helper.exs installs the Hexpm.LogLines logger handler, starts the in-memory store from config/test.exs, builds the registry for the hexpm repository and puts the SQL sandbox in manual mode. The agent reproduces with the failing file alone, such as mix test test/hexpm_web/controllers/api/release_controller_test.exs:310, with MIX_OS_DEPS_COMPILE_PARTITION_COUNT set as the workflow sets it.
With the failure on record it reads what the test covers. For publishing that is lib/hexpm_web/controllers/api/release_controller.ex: publish on POST /api/publish and create on POST /api/packages/:name/releases, behind plugs that fetch the body under a size limit, parse the tarball, fetch the package and authorize with the api:write or package domains, with workload identity allowed; publish then reads the release metadata and checksums, logs the tarball under the repository, name and version, and calls Releases.publish. The tests in test/hexpm_web/controllers/api/release_controller_test.exs build tarballs with test/support/tarball_helpers.ex and cover escaping symlinks and paths, more than 10,000 files, unexpected outer files, metadata names over 255 bytes and refusing an unauthenticated caller before the body is read. package_controller.ex with index, show and audit_logs has its own test file beside it. The agent reads the commit that broke the job as well.
The fix goes in lib/. A test is changed only when the test is wrong, and the pull request says so. Before pushing, the agent runs the full mix test, then mix format --check-formatted and mix compile --warnings-as-errors for the format job, and when the change touched a controller the Hex client calls, it clones hexpm/hex as the test-hex job does and runs that suite with HEXPM_PATH=.. and MIX_OS_CONCURRENCY_LOCK=0, so a fix for one job does not break the next.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "The GitHub Actions workflow on this branch failed; the workflow_run event is at the end of this prompt. Read the failed job's log with gh run view <run id> --log-failed, name the job that failed (format, test-hexpm, test-hex or docker) and quote the failing test, warning or diff. Use the Elixir and OTP the workflow pins, start Postgres with the pg_trgm and pgcrypto modules, run mix deps.get, and reproduce the failure with the same command narrowed to the failing file and line first. Fix the cause in lib/ (change a test only if the test is wrong, and say so), then run mix test, mix format --check-formatted and mix compile --warnings-as-errors; if you changed an API controller the Hex client calls, clone hexpm/hex and run its suite with --include integration and HEXPM_PATH set as the test-hex job does. Open a pull request against the failing branch that quotes the error it fixed.\n\nEvent: <workflow_run payload>",
"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
A pull request against the failing branch, with the fix under lib/ and the job and quoted failure in the description. It shows the single test failing and then passing, then the full mix test, the format check and the warnings-as-errors compile, and the Hex client suite when it ran; the session's trajectory keeps every command with its output. The workflow reruns all four jobs on the pull request.
When the failing job is format because mix ecto.setup broke, the pull request fixes the seed or the migration and the description shows ecto.setup passing again. When the failure is only in test-hex for one client version, the description names that version and the request the client sends. When there is no code cause, it opens nothing and its answer explains what the log shows.
A reviewer checks that a change to publish or create still refuses what the tarball tests refuse, that no test lost a @tag or an assertion, and that mix.exs, config/test.exs and the workflow are untouched.
Run it on every failed Phoenix workflow run
Add an automation to the Project with this prompt and a github trigger on workflow_run.failure; each failed run of the CI workflow starts one run with the event under the prompt, and only work by owners, members and collaborators fires it. Or send GitHub's workflow_run webhook to your own server and send this request with https://github.com/<owner>/<repo>/tree/<head_branch> as the resource.
Exclude the agent's own branches so a failed fix does not trigger itself, keep each workflow_run.id with the execution_id to drop redeliveries, and use the run.completed webhook from Rush to post the pull request link on the contributor's pull request.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
A red Phoenix build with a Postgres schema file, a registry build in the test helper and a second repository's suite in the matrix is more setup than most developers keep on a laptop. The agent builds it from the workflow file in its own sandbox, with the pinned Elixir and OTP, and runs the failing file the way the runner did.
What it hands back is checkable: the quoted failure, the trajectory with every mix command and its output, and all four jobs rerunning on the pull request. Failures on several branches each get their own run in parallel, and nothing merges without a reviewer.
Frequently asked questions
Does it run the Hex client's suite every time?
Only when the failing job was test-hex or the fix touched an API controller the client calls. That suite clones a second repository and runs with --include integration, so the agent runs it when it matters and says in the pull request whether it did.
Why does it need pg_trgm and pgcrypto?
Because priv/repo/structure.sql, loaded by the test alias through ecto.load, uses them, and the README says the migrations fail without them. The agent starts a Postgres image that ships both, as the workflow's postgres:18 does.
Will it fix a compile warning by turning off --warnings-as-errors?
No. The flag lives in the workflow, which the prompt leaves alone, and a change there would show in the diff. It fixes the warning in the module that raised it.
Which Elixir and OTP does it use?
The ones the workflow's env pins, Elixir 1.20.4 on OTP 29.1, installed the way erlef/setup-beam installs them. mix.exs requires Elixir 1.20, so an older local version would not even compile.