Turn Sentry Errors Into Fix Pull Requests for a SvelteKit App

A Sentry alert for a SvelteKit app names a server load function or a form action most of the time, and the agent starts there. Through the Sentry connection it reads the issue and its latest event: the exception, the request URL and method, the release, and the in-app frames with their file paths and line numbers. It compares the frames against the route tree in its clone of the repository, so a frame in src/routes/article/[slug]/+page.server.js is matched to the article page's load and its createComment, deleteComment, deleteArticle and toggleFavorite actions before any code is read.

In a SvelteKit app like sveltejs/realworld the agent reads package.json first: SvelteKit ^2.52.2 on Svelte ^5.55.7 with runes: true in svelte.config.js, Vite ^7.3.2, adapter-vercel, marked and sanitize-html, and packageManager set to pnpm 10.20.0 with .nvmrc at 20 and engine-strict in .npmrc. There is no test script and no test runner; the only check is prettier --check . as pnpm lint. Every request goes through src/lib/api.js, whose send fetches https://api.realworld.show/api, returns the parsed body on an ok or 422 response, returns {} on an empty body and otherwise calls SvelteKit's error(res.status). The article loader runs api.get for the article and its comments in a Promise.all, then marked(article.body) and sanitizeHtml. The profile routes under src/routes/profile/@[user]/ load profiles/{user} in +layout.server.js and the author's articles through get_articles.js, which builds limit and offset from page_size in src/lib/constants.js. src/hooks.server.js sets locals.user by JSON.parse(atob(jwt)) on the cookie, which is itself a place a malformed cookie throws.

Because the project has no runner, the agent adds vitest as a dev dependency and a test script, keeping @sveltejs/vite-plugin-svelte that is already installed for Vite. It writes a test that imports the loader or action from the route file and calls it with a hand-built event: params from the event's URL, locals with or without a user, and a mocked fetch or a mocked $lib/api.js that returns the body the Sentry event implies, such as {} from an empty response or an article with no body. It runs npx vitest run and keeps the failing output, which shows the same exception type and message as the Sentry event.

Then it fixes the cause in the loader or action, reruns the test until it passes and runs pnpm lint and pnpm build so the Vercel adapter still builds. If the frame was in +page.svelte rather than a loader, it reads the component with data from $props() and fixes what the template assumes about the data, such as data.article.author, with a test for the loader that feeds it. It does not wrap the loader in a blanket try that hides the status; +error.svelte already renders a 404 and a generic page, and the fix keeps that behaviour.

The result is a pull request with a small diff: the route file where the exception started, a new test file beside it, vitest under devDependencies with a test script in package.json, and the updated pnpm-lock.yaml. The description links the Sentry issue, names the loader or action and the line, shows the test failing before and passing after, and explains in plain words why the code threw, for example that an empty API response reaches marked as undefined.

The session holds the full record: the Sentry queries, the pnpm install, vitest, lint and build commands with their output, and the files the agent read. Its final message, the result on the session and data.result in the run.completed webhook, is the short account a reviewer reads first; the transcript is where they check it.

Before merging, the reviewer confirms the test calls the same code path Sentry reported, that a fix which now throws error(404) or error(502) chooses the status the API answer deserves rather than hiding it, and that nothing in src/lib/api.js changed for routes that were working. A different approach is a follow-up message to the same session, and the agent amends the same branch.

Add an alert rule in Sentry for the SvelteKit project that fires when a new issue is created, with a webhook action aimed at a handler on your server. The handler sends this request with the alert's JSON after the prompt and the issue id as the Idempotency-Key, so Sentry's retries map to one run. Every new issue gets its own sandbox, its own test and its own pull request.

Give the API key a webhook URL and Rush POSTs run.completed when the turn ends, with session_url to read the pull request from. Or have that handler call a webhook trigger on an automation in the Project with this prompt: it forwards the alert's JSON as the body with the trigger's secret as Authorization: Bearer, because Sentry signs its own webhooks and cannot send that header. The body becomes the event text after the prompt, and max_runs_per_hour caps an issue that keeps firing.

A SvelteKit loader fails on an API answer that is hard to get a browser to produce again, so reproducing it on a laptop means stubbing fetch by hand and wiring a test runner into a project that never had one, all while something else is half-done on your branch. In a Rush sandbox the agent sets up Vitest on its own disk, mocks exactly the response the Sentry event shows and leaves your working tree alone.

What you get back can be checked instead of trusted: the test that failed, the test that passes and the transcript of every command the agent ran. Each Sentry issue runs on its own, in parallel up to the key's max_concurrent limit, so a release that opened several issues gets several reviewed fixes rather than one person triaging them in order.

The project has no tests. Does the agent still write one?

The Sentry frames point into the Vercel build. Can it still find the line?

Which package manager does it use?

Will it change src/lib/api.js?