# Set Up GitHub Actions CI for a SvelteKit App

Yes. An agent reads your SvelteKit repo, adds a GitHub Actions workflow with pnpm caching, Prettier, svelte-check and the build, and fixes it until it passes.

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

## What the agent does

The agent reads what the repository declares before writing a workflow. In a SvelteKit app like sveltejs/realworld there is no `.github/` directory at all, so nothing runs on a pull request today. `package.json` names `pnpm@10.20.0` in `packageManager`, `.nvmrc` says Node 20, `.npmrc` sets `engine-strict=true`, and the scripts are `dev`, `build`, `preview`, `lint` (`prettier --check .`) and `format`. There is no `test` script, no test runner in `devDependencies`, and no `check` script even though `typescript` `^5.9.3` is installed and `jsconfig.json` extends `.svelte-kit/tsconfig.json`.

It then works out what a useful job can run. `pnpm lint` is the formatting gate the repository already has. `svelte-check` is not installed, so the agent adds `svelte-check` as a dev dependency with `pnpm add -D` and a `check` script of `svelte-kit sync && svelte-check`, which type-checks the `.svelte` and `.js` files under `src/` against the generated `.svelte-kit/tsconfig.json`. `pnpm build` runs Vite with the `@sveltejs/adapter-vercel` adapter from `svelte.config.js`; it needs no environment variable because `src/lib/api.js` hard-codes the API base URL, and no database because the app has none. The `pnpm-workspace.yaml` entry allowing `esbuild` under `onlyBuiltDependencies` means `pnpm install --frozen-lockfile` builds that one dependency in CI without a prompt.

The workflow it writes at `.github/workflows/ci.yml` runs on pull requests and pushes to the default branch: checkout, `pnpm/action-setup` reading the version from `packageManager`, `actions/setup-node` with `node-version-file: .nvmrc` and `cache: pnpm`, `pnpm install --frozen-lockfile`, then `pnpm lint`, `pnpm check` and `pnpm build` as three named steps so a failure points at one of them. Because the repository has no tests, the agent adds the smallest honest test step: Vitest as a dev dependency, a `test` script, and one test of the pagination helper in `src/routes/profile/@[user]/get_articles.js` with a stubbed `fetch`, so the step is real and the pull request description says it was added.

The agent pushes its branch, opens the pull request and watches the new workflow run on it. If `svelte-check` reports an error in existing code, it does not loosen the check; it fixes the file when the fix is clear, or runs `svelte-check` with `--threshold error` and lists the warnings in the description for a later pass. When every step is green, it finishes.

## Start it with one API call

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

```json
{
  "agent": "claude",
  "input": "Add a GitHub Actions workflow at .github/workflows/ci.yml that runs on every pull request and on pushes to the default branch. Read package.json, the lockfile, .nvmrc, .npmrc, pnpm-workspace.yaml and svelte.config.js first: use the package manager and version that packageManager and the lockfile imply, pin the Node version from .nvmrc or engines, set up caching keyed on the lockfile, and install with the lockfile frozen. Run the lint script, a svelte-check type check (add svelte-check and a check script if the repository has none), the tests, and the build. If the repository has no test script, add Vitest and the smallest real test that works and say so in the pull request description. Do not touch existing workflow files. Open a pull request and make sure the new workflow passes on it; if a step fails, fix the cause and push again rather than weakening the check.",
  "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

What comes back is a pull request on its own branch that adds `.github/workflows/ci.yml`, and in a repository shaped like the RealWorld app also adds `svelte-check` and `vitest` to `devDependencies` with the `check` and `test` scripts in `package.json`, the updated `pnpm-lock.yaml`, and one small test file beside the route it covers. The workflow has a single job with pnpm 10 from `packageManager`, Node 20 from `.nvmrc`, a frozen install, and the lint, check, test and build steps named one by one.

The description says which file each pin came from, lists the scripts and dependencies it added because they were missing, and shows the workflow's own run on the pull request with every step green. If `svelte-check` found warnings in existing code that the agent did not fix, they are listed there with file and line.

A reviewer checks that the steps match what they run locally, that the added test covers real code rather than a placeholder, and that the adapter and Node version are the ones their deploy uses. The session read returns the repository and the pull request, and the transcript holds each workflow run the agent watched, including any failed attempt and the fix that followed.

## Run it on every new repository

From your own server, start one run per repository that has no `.github/workflows/` directory: `POST /o/{org}/sessions` with this prompt and the repository in `resources`, one call each. `GET /o/{org}/github` lists every repository the Rush GitHub App installation reaches, so a script can pick the ones without CI and start them in a loop. Each run gets its own sandbox and branch, and opens its own pull request.

Set a `webhook_url` on the key and each run POSTs `run.completed` with its `session_url` when the turn finishes, within about 30 seconds, so the pull request links collect on your side without polling.

## Why run it on Rush?

A workflow has not been set up until it has passed on a pull request, and getting there is a loop of push, wait, read the log and push again. On Rush the agent runs that loop in its own sandbox with the repository's own pnpm and Node, and every attempt stays in the transcript, so the reviewer sees a green run and the fixes it took rather than a YAML file that was never executed.

The choices that make CI reliable are in files the agent reads rather than guesses: `packageManager`, `.nvmrc`, `engine-strict`, the `esbuild` build approval in `pnpm-workspace.yaml`, the missing `check` and `test` scripts. The pull request names the file behind each line of the workflow, so the next change to it has the same reasons in front of it.

## Frequently asked questions

### Will it change my existing workflow files?

No. The prompt says not to touch existing workflows, so the agent adds `ci.yml` beside them. If one already runs lint or the build, say so in the prompt and the new workflow covers only what is missing, such as `svelte-check`.

### Does it work with pnpm, npm, Yarn or Bun?

Yes. The agent reads `packageManager` and the lockfile that exists and uses that manager at that version with its cache. The RealWorld app declares `pnpm@10.20.0` and ships `pnpm-lock.yaml`, so the workflow uses `pnpm/action-setup` and `actions/setup-node` with `cache: pnpm`.

### My app has no tests. What does the test step run?

The smallest real test the agent can write, and the pull request says it was added. In the RealWorld app that is Vitest with one test of the profile pagination helper, which calls the loader with a stubbed `fetch`. If you would rather have no test step, say so in the prompt and the job runs lint, check and build only.

### Does the build need my Vercel project or any secret?

No. `pnpm build` runs the Vite build with the adapter in `svelte.config.js` and produces output without deploying anywhere. The RealWorld app reads no environment variable at build time; an app that does gets a throwaway value in the workflow and a note in the description to add the real one as a repository secret.

### What if svelte-check fails on code that is already in the repository?

The agent fixes the error when the fix is clear and local. When it is not, it keeps the check at the error threshold, lists the remaining warnings with file and line in the pull request, and leaves the decision to the reviewer rather than turning the step off.