# Fix Failing GitHub Actions Checks in a SvelteKit App

Yes. An agent reads the failed step's log, reruns that step in a SvelteKit workspace, fixes the type, lint or Vitest error and opens a pull request.

[Run this on Rush](https://cloud.getrush.ai/run/fix-failing-ci/sveltekit/), in a Project that has your repository.

## What the agent does

A red build in a SvelteKit monorepo can come from three different commands, so the agent starts by finding out which one failed. It reads the event that started the run, calls `gh run view <id> --log-failed`, and maps the failed step back to `.github/workflows/ci.yml`. In sveltejs/svelte.dev the active job is `Lint`: it installs with `pnpm install --frozen-lockfile` on Node 24, runs `pnpm -r package && pnpm check` as the type check, then `pnpm lint`. The `Tests` job is commented out, so a failure there means someone re-enabled it.

Then it sets up the same toolchain in its sandbox. The root `package.json` pins `packageManager` to `pnpm@11.5.3`, and `pnpm-workspace.yaml` covers `apps/*` and `packages/*` with a catalog for `svelte` `^5.57.1`, `@sveltejs/kit` `^3.0.0-next.31`, `vite` `^8.3.1` and `vitest` `^4.1.8`. It also sets `engineStrict`, `minimumReleaseAge: 2880` and `blockExoticSubdeps`, so a dependency bump that pnpm refuses fails at install, before any test runs. The agent installs with the frozen lockfile, exactly as CI does, and reads that error before touching code.

It reproduces the failing step with the command that step ran. A type error reproduces with `pnpm check`, which runs `svelte-kit sync && svelte-check` in each package after `pnpm -r package` builds `packages/site-kit` and `packages/repl`. A formatting failure reproduces with `pnpm lint`, which is `prettier --check .`. A test failure reproduces with `npx vitest run` in the package that owns it: `packages/repl`, `packages/site-kit`, or `apps/svelte.dev`, where the `test` script first runs `node scripts/get_svelte_template.js` to generate the playground's download templates and then `vitest run` picks up files like `src/lib/playground-download.test.ts` and `vercel.test.ts`.

With the error reproduced, it fixes the cause in the route or component the log points at, such as a prop type under `src/routes/(authed)/playground/` or a missing export in `packages/repl`. The repository's `AGENTS.md` asks for `pnpx prettier --write` on every changed file, so the agent runs it before committing; otherwise its own fix could turn the lint step red. It reruns the failing command until it passes, then opens a pull request against the failing branch that quotes the original error.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "The CI workflow failed on the branch docs/new-tutorial. Find the failed run with `gh run list --branch docs/new-tutorial --status failure --limit 1` and read it with `gh run view <run id> --log-failed`. Check out that branch, install with `pnpm install --frozen-lockfile`, and rerun the exact step that failed: `pnpm -r package && pnpm check` for type errors, `pnpm lint` for formatting, or `npx vitest run` in the package whose test failed. Fix the cause in the code; change a test only if the test is wrong, and say so. Run `pnpx prettier --write` on every file you change. Confirm the failing command passes, then open a pull request against docs/new-tutorial that quotes the error and names the step it fixed.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **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.
2. **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.
3. **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 pull request against the branch that failed. Its diff is usually small: a `.svelte` or `.ts` file under `apps/svelte.dev/src/` or one of the `packages/`, plus any formatting Prettier applied to the same files. The description names the failed step (`type check`, `lint` or a Vitest file), quotes the error from the log, and says whether a test was changed and why.

Pushing the branch runs `ci.yml` again, so the pull request carries its own `Lint` check, and a reviewer sees it pass where the original run failed. The session record has the full output of the first command that reproduced the failure and of the last one that passed, which matters in a workspace where `svelte-check` can print hundreds of lines across several packages.

A reviewer checks that the fix touches the file the error named, that no `// @ts-ignore` or `svelte-ignore` comment was added to silence a real type error, and that Prettier changes are limited to files the fix needed. If the failure was an install refusal from `minimumReleaseAge`, the pull request should explain the dependency and its publish date rather than relax the setting.

## Run it on every red CI on a pull request branch

Create an automation in the Project for this repository with the prompt above and a GitHub trigger on `workflow_run.failure`. Every failed workflow run starts one Rush run, and the event that fired it follows the prompt as data, so the agent reads the branch and run id from it instead of searching. Workflows run from forks never fire, so a contributor's pull request from their own fork does not start an agent.

To keep the agent on work your own team pushed, filter the trigger with `authors` (GitHub logins), and cap max runs per hour so a docs sync that fails repeatedly does not start one run per push. When a run ends, the pull request it opened appears on the failing branch, where its author already looks.

## Why run it on Rush?

Reproducing a SvelteKit CI failure locally means matching pnpm 11, Node 24 and a frozen install across a workspace with several packages, then running the build that `pnpm check` depends on. On Rush the agent does this in a sandbox with its own clone, so a `svelte-kit sync` that rewrites `.svelte-kit/` or a template script that writes into `static/` changes nothing on your machine.

The fix comes back as evidence, not a claim. The workflow that failed runs again on the pull request, and the session keeps every command and its output, from `--log-failed` to the passing `pnpm check`. When several branches go red after one bad catalog bump, each failure starts its own run in its own sandbox, and each branch gets its own pull request.

## Frequently asked questions

### Which command does the agent use to reproduce the failure?

The one the failed step ran. In this repository that is `pnpm -r package && pnpm check` for the type check and `pnpm lint` for formatting; for a test job it runs `npx vitest run` in the package that failed. It reads the step from the log rather than running every command.

### Will it reformat my whole repository with Prettier?

No. It runs Prettier on the files it changed, as the repository's `AGENTS.md` asks, so the diff stays limited to the fix. If `pnpm lint` failed on a file the branch already touched, it formats that file and says so in the description.

### Does it need Playwright or a browser to fix my tests?

Only if the failing test does. The sandbox has a browser, so it can install Chromium for a Playwright job; for Vitest unit tests like the ones in `packages/repl` and `apps/svelte.dev`, it runs them headless with `vitest run`.

### What if the failure is a dependency pnpm refused to install?

It reads the install error, finds which package and version broke a rule such as `minimumReleaseAge` or `blockExoticSubdeps`, and fixes the dependency choice in the branch, for example by pinning the previous release. It does not loosen the workspace settings without saying why in the pull request.