What the agent does
A Vue app's Sentry event names the component or the Pinia action that threw, the page URL, the release and the breadcrumbs of navigation and fetch calls that came before it. The agent reads the alert payload after the prompt, fetches the issue and the latest event through the Sentry connection, and keeps the frames, the breadcrumbs and the tags. Then it opens its clone and reads the store action, the view and the components the frames name.
In a Vue app like the RealWorld example at realworld-apps/vue-realworld-example-app, every API call goes through request in src/common/api.service.js, a fetch wrapper that parses the body as JSON, treats a parse failure as null, and on a non-2xx status throws an Error whose message starts with [RWV] API and carries response.status and response.data. extractErrors in src/common/errors.js reduces any error without a usable body to a single network message. The article store in src/store/article.js assigns data.article and data.comments straight from the response in fetchArticle and fetchComments, refetches in createComment when the server returns no comment, filters locally in destroyComment, and in addFavorite and removeFavorite writes the returned article into both this store and the home store's list. src/views/Article.vue calls both fetches in beforeRouteEnter with .catch(() => null) on each, then renders article.title, article.tagList and parseMarkdown(article.body) through marked and DOMPurify; the profile store in src/store/profile.js retries fetchProfile twice with a delay before it gives up, and src/views/Profile.vue calls it from onMounted and a route watcher. The components Comment.vue, CommentEditor.vue and ArticleActions.vue catch their own calls and show extractErrors output.
The repository tests only end to end: package.json has test as playwright test against bun run serve on port 8080, with the shared RealWorld specs vendored in the realworld submodule, and the playwright.yml workflow installs Chromium and runs bun run test:e2e. That is the wrong tool for a store action, so the agent adds Vitest as a dev dependency and writes a unit test that imports the store with a fresh Pinia, mocks fetch or the service module to return the response the Sentry breadcrumbs show, a 404 with an empty body or an article with tagList missing, and calls the action or renders the view with @vue/test-utils. It runs npx vitest run and keeps the failing output as the reproduction.
Then it fixes the action, the view or the component, reruns the test until it passes, and runs bun run lint, which is ESLint with the Vue plugin's essential rules, bun run format:check for Prettier, and bun run build, matching the lint.yml and release workflows. When the Playwright browsers install in the sandbox it also runs bun run test:e2e, because the article and profile pages are what those specs exercise. The agent does not widen the .catch(() => null) in beforeRouteEnter; where the view should show an error instead of rendering an empty article, it adds that state and says why.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Sentry alert fired for this Vue app; its payload follows this prompt. Use the Sentry connection to read the issue, its latest event, the breadcrumbs and the in-app stack frames. Match the frames to the Pinia stores under src/store, the views under src/views and the components under src/components, starting with src/store/article.js, src/views/Article.vue and the fetch wrapper in src/common/api.service.js. The project only has Playwright specs: add Vitest and @vue/test-utils as dev dependencies, write a unit test that mocks the API response the breadcrumbs show and reproduces the error, then fix the cause until `npx vitest run` passes. Install with bun, run `bun run lint`, `bun run format:check` and `bun run build`, and the Playwright suite if its browsers install. Open a pull request that links the Sentry issue, quotes the frames and the failing test output, and explains the cause. Change nothing unrelated to this error.\n\nAlert payload:\n{payload}",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
],
"connections": [
"sentry"
]
}- 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
The result is a pull request with the fix in one store, view or component, a new unit test beside it, vitest and @vue/test-utils under devDependencies and the updated bun.lock. The description links the Sentry issue, quotes the exception and the frames, names the breadcrumb it reproduced from, shows the test failing before and passing after, and lists the lint, format and build commands with their results.
The session's transcript keeps the Sentry reads, every bun and vitest command with its full output and every file opened, so the reviewer can confirm the Playwright run happened or see why it was skipped. The run.completed webhook carries the agent's final message as data.result and a session_url for the rest.
Before merging, a reviewer checks that the mocked response is the one the breadcrumbs show, that a fix in the store does not mask a failed request by leaving default state in place silently, and that the view still renders the markdown through DOMPurify. A follow-up message to the same session changes the approach on the same branch.
Run it on every Sentry issue alert
Add an alert rule to the Sentry project with a webhook action and point it at a handler on your server. The handler sends this request with the alert's JSON after the prompt and the Sentry issue id as Idempotency-Key, so retries return the run that already started. One issue becomes one sandbox and one pull request.
Give the API key a webhook URL and Rush POSTs run.completed with session_url when the turn finishes, so the handler can comment the pull request link on the Sentry issue. 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.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
A front-end error that depends on one API response is tedious to chase by hand: you reconstruct the response from breadcrumbs, add a unit test runner to a project that only has Playwright, and try not to disturb the branch you were on. In a Rush sandbox the agent does that on its own disk with Bun, keeps every command's output and leaves your checkout as it was.
The pull request carries its proof, the test that failed and now passes, and the transcript shows the lint, build and Playwright commands behind it. Each issue runs separately, in parallel up to the key's max_concurrent limit, so the errors a release leaves on the article and profile pages become small parallel reviews.
Frequently asked questions
Why add Vitest when the project already has Playwright?
The Playwright specs drive the whole app in Chromium against a live backend and cannot feed a store action one specific response. Vitest with a mocked fetch reproduces exactly what Sentry saw in milliseconds. If you prefer a single runner, say so in the prompt and the agent writes a Playwright spec with a route mock instead.
Does it run the RealWorld end-to-end suite?
When the browsers install in the sandbox, yes, with bun run test:e2e against bun run serve as playwright.config.ts sets up. The specs live in the realworld submodule, so the agent clones with submodules. The pull request says whether the suite ran.
What if the error is really a backend problem?
The breadcrumbs show the request and its status. If the API returned a 500, the agent says so, proposes a change only where the front end should have handled that answer, and otherwise opens no pull request so the backend team can take the issue.
Will it change api.service.js for every caller?
Only when the frames point there, for example a 204 reaching response.json(). Because every store uses it, the pull request flags that change and the test covers the exact response that broke, and the reviewer can ask for a narrower fix in a follow-up.