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 with this body:
{
"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"
}
]
}- 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 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.
The use case this job follows, with its automation and trigger: Hand off from your terminal.
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.