What the agent does
The agent identifies the PR revision, reads its changed Vue components and checks how this app actually starts. In realworld-apps/vue-realworld-example-app, package.json:8 declares "vue": "^3.5.0"; package.json:30–33 defines "serve": "vite", "test": "playwright test" and separate functional and security E2E scripts. The repository uses bun.lock and a realworld git submodule. README.md explains that the shared theme and official E2E suite come from that submodule, so a review must initialize it before treating missing styles or test files as application regressions.
It runs git submodule update --init, bun install and bun run serve using the repository's instructions. vite.config.js:17–19 fixes the server to "127.0.0.1", port 8080 and strictPort; playwright.config.ts also targets port 8080 and starts bun run serve. The agent checks the actual startup output instead of assuming Vite's usual default port. A working browser session and the correct shared stylesheet are prerequisites for useful contrast, focus visibility and layout evidence.
The review follows state through Vue components and Pinia rather than scanning tags in isolation. src/views/Login.vue renders errors from the auth store, binds email and password with v-model and pushes a post-auth route after login. src/views/Article.vue displays the article body through v-html after DOMPurify sanitization and switches between a comment editor and sign-in links depending on authentication. A changed article screen therefore needs its loaded content and both relevant authentication states, while a changed login form needs the unsuccessful submission path as well as a successful navigation.
The agent runs axe against those rendered states and manually follows the keyboard path through forms, links and article actions. It compares the same content on base and head before attributing a failure to a changed line. bun run build, bun run lint and the relevant existing Playwright checks provide additional output, but none replaces the manual focus review. It keeps screenshots or audit files for reproducible findings and records any missing backend access, test account or browser state that prevents a complete review.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Review the identified open Vue pull request for accessibility regressions only. If its identity is ambiguous, ask for the exact PR URL. Read package.json, bun.lock, the submodule setup, Vite and Playwright configs, changed SFCs and related state. Start the app using its own commands and port. Run axe on each touched screen and use keyboard navigation through validation, loading, authenticated and signed-out states relevant to the change. Compare equivalent base and head states. Comment on changed lines with the exact component, element, reproduction, accessibility requirement, evidence and a concrete fix. Return accessibility.md, actual check output and coverage gaps. Do not modify source or open a replacement 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 output is a review of the existing PR plus accessibility.md and its supporting browser evidence. A comment ties a new failure to a Vue component and changed line, names the route and authentication state, and gives an actionable correction. The report distinguishes axe violations from manually reproduced keyboard problems and includes the exact commands run, their results and any environment failures.
Before merging, replay the reported keyboard sequence with the same content and inspect the accessible name or focus behavior in the rendered DOM. Check that the baseline used the same shared theme and backend data, especially for article content loaded from the API. A missing test account remains a coverage limit, not a passing authenticated review. The session transcript gives the author a way to inspect how the agent reached its conclusions.
Run it on every Vue component pull request
Have your GitHub event handler start a run for each PR revision you want reviewed. Replace the generic repository URL in resources with the actual pull-request URL, which the developer API supports as a branch resource, and identify the revision in input. An Idempotency-Key prevents a transport retry from starting a duplicate review session. Your completion-webhook handler reads the finished answer and downloads accessibility.md for the review record.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
Vue accessibility problems often depend on a computed state, an asynchronous store update or the markup returned for a signed-out visitor. Rush lets the agent run those states in its own cloud sandbox instead of borrowing your existing Vite process. Dependencies, the shared submodule and browser evidence belong to that review, without disturbing a laptop checkout where unrelated work is in progress.
The command and tool record shows whether the agent tested the correct port and route or only inspected source. Separate PRs can be reviewed independently within the account's concurrency limits, with each audit's files attached to its session. The useful result is a reproducible comment on the relevant component, backed by the browser state that exposes it.
Frequently asked questions
Does the fixture already have Playwright?
Yes. package.json declares Playwright and the test script runs playwright test. Its configuration imports the shared realworld suite, which is why initializing the submodule matters before interpreting a test failure.
Will ESLint catch every accessibility issue in a Vue template?
The repository's lint script runs ESLint, but a lint pass cannot demonstrate keyboard behavior after a store update or route change. The agent combines the repository checks with axe and a manual browser sequence. It reports what each check actually establishes.
Can the review inspect HTML rendered from article content?
It can audit the resulting DOM in the running app. The fixture renders sanitized Markdown through v-html, so the actual article content matters to the evidence. The review should use comparable content on base and head instead of blaming different input data on the PR.
What happens if the backend is unavailable?
The agent records the failure and names the screens or states it cannot reach. It can still review source and any accessible pages, but it must not claim that authenticated or data-dependent flows passed. Provide an approved test backend to complete those checks.