What the agent does
The agent reads the changed SvelteKit routes and the repository's real commands before choosing checks. In sveltejs/realworld, package.json:8–12 defines "dev": "vite dev", "build": "vite build" and "lint": "prettier --check .". It declares pnpm@10.20.0 and has pnpm-lock.yaml; the lockfile resolves SvelteKit 2.52.2 and Svelte 5.55.7. There is no test script in that package file. The review therefore cannot describe a green test suite where the repository only supplies a build and formatting check.
It traces route markup through its server actions and shared components. src/routes/login/+page.svelte:23 uses
The article editor adds a different interaction to review. src/routes/editor/+page.svelte passes an empty article into Editor.svelte; that component handles tag entry on Enter and removes tags using buttons with an aria-label="Remove {tag} tag" attribute at src/routes/editor/Editor.svelte:74. The agent exercises typing a tag, adding it, moving focus to its removal button and removing it. It inspects the title, description and body fields as rendered, and checks any changed transitions without assuming Svelte's compiler warnings cover focus movement or the usable name of a newly added control.
After pnpm install --frozen-lockfile and pnpm run dev, the agent runs axe on the touched routes and manually checks keyboard navigation, error recovery and navigation between pages. It builds both base and head as needed, keeps the same data and viewport for comparisons, and records pnpm run build and pnpm run lint output. Existing unlabeled controls do not become new-PR findings unless the change introduces or worsens the failure. Missing backend access or a failed audit is reported as a limitation, not converted into an accessibility approval.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Review the identified open SvelteKit pull request for newly introduced accessibility failures. Ask for an exact PR URL if more than one target is possible. Read package.json, pnpm-lock.yaml, changed +page.svelte files, related server actions and shared components. Start the app with its documented commands. Audit the changed routes with axe and keyboard navigation, including enhanced form errors, redirects, tag controls and authenticated states where relevant. Compare the same states on base and head. Comment on changed lines with reproduction steps, the affected requirement, audit evidence and a concrete correction. Return accessibility.md with command output and coverage limits. Do not claim nonexistent tests ran, edit source files or create another PR.",
"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
The existing PR receives comments for attributable regressions, and accessibility.md records the routes, interaction states and browser checks covered. Axe findings include the element target and rule output; form and keyboard findings explain the action sequence that exposes the problem. A separate evidence section records build and formatting results without relabeling Prettier as an accessibility test.
The reviewer verifies that each problem appears on the head revision and is absent, or materially different, on the base revision. For forms, reproduce the invalid response as well as the successful redirect. For editor controls, repeat the add-and-remove interaction with the keyboard. The report clearly separates verified findings, routes blocked by backend access and checks that were not performed, so its scope remains useful when deciding whether to merge.
Run it on every SvelteKit route change
Your PR-event handler can submit a session whenever a new revision changes routes or shared UI. Supply the exact pull-request URL as the repository resource for a real review, replacing the generic example, and put the revision being reviewed in input. Reuse its Idempotency-Key for retries of that body, not for later commits. On completion, read the session's answer and artifact list to collect the accessibility report.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
A SvelteKit form spans server actions, hydration and the browser's current focus. Rush gives the agent a sandbox where it can run the actual app and inspect those transitions without occupying your local pnpm workspace. That makes the deliverable a route-specific review supported by browser output, instead of a guessed list of warnings extracted from .svelte files.
The session keeps the setup commands and their results next to the findings, including whether the backend returned an error that the page actually rendered. Separate PR revisions can be investigated independently within concurrency limits. You get an inspectable account of what the agent exercised, which matters when a green production build still leaves a form difficult to navigate.
Frequently asked questions
Are Svelte compiler warnings enough for this review?
Compiler warnings are useful input, but they do not exercise a user's keyboard sequence or the error returned by a server action. This review uses a running browser and axe as well. It does not describe either tool as proof of complete WCAG conformance.
What if this SvelteKit project has no test command?
The realworld fixture has dev, build, preview, lint and format scripts, but no test script. The agent records the available checks and adds a browser audit for this task. It must not invent a unit-test result.
Will pre-existing label problems block every pull request?
The task scopes review comments to new or worsened failures attributable to the diff. A baseline problem stays separate from regression findings. Matching the UI state between base and head prevents misleading comparisons.
Can it review the editor's dynamic tag buttons?
Yes, the prompt calls for real keyboard interaction rather than a static scan alone. In the fixture, Enter adds a tag and a labeled button removes it. The review checks the behavior after those DOM changes and reports only problems it can reproduce.