# Review Pull Requests Automatically in an Astro Site

Ask Rush to review an Astro pull request with the workspace's real pnpm and Vitest setup, then return file-and-line findings without commits.

[Run this on Rush](https://cloud.getrush.ai/run/review-pull-requests/astro/), in a Project that has your repository.

## What the agent does

The agent reviews a supplied pull request and posts one review backed by actual commands. In a project like withastro/starlight, it first corrects an important setup assumption: package.json:35 declares "packageManager": "pnpm@11.22.0", and pnpm-workspace.yaml:1–4 includes packages, examples and docs. The agent reads pnpm-lock.yaml and uses pnpm install --frozen-lockfile instead of npm install. Review must use the repository's dependency graph rather than creating a different graph before interpreting failures.

It checks out the supplied PR branch and reads the diff with surrounding sidebar and internationalization code. packages/starlight/src/utils/navigation.ts:81–95 distinguishes link, autogenerated, internal-slug and grouped sidebar entries; lines 123–129 add the locale to internal manual links and choose a translated label. A review of a sidebar change needs to inspect those paths as well as the altered line. The agent connects each suspected defect to a specific configuration and user-visible navigation result.

The i18n path has its own constraints. packages/starlight/src/utils/i18n.ts:33–37 rejects simultaneous Astro i18n and Starlight locale configuration, and lines 72–79 calculate prefixDefaultLocale and disable redirectToDefaultLocale. The agent reads the corresponding tests instead of inferring behavior from framework defaults. packages/starlight/__tests__/i18n/routing.test.ts:66–72 asserts that an Arabic fallback route retains its own locale, language and direction. A finding about fallback navigation must explain which of those observable properties changes.

It runs the package's configured suite in non-watch mode with pnpm --filter @astrojs/starlight test --run. packages/starlight/package.json:7 defines the test script as VITE_CONFIG_NATIVE_IGNORE_WARNING=true vitest; packages/starlight/vitest.config.ts:5 discovers projects under __tests__/*/vitest.config.ts. The agent also reads the sidebar project's configuration and the relevant fixture before judging coverage. It reports real failures, distinguishes test setup errors from application defects and posts a review citing the current PR's file and line. It pushes no commits and never treats the public example repository as the review target.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Review the Astro pull request whose URL, base SHA and head SHA the caller appends below. Require the PR identity before proceeding; the repository resource is the caller's application, not the public example. Check out the supplied PR head and verify the revision. Read package.json, the checked-in lockfile, workspace and Vitest configuration. Use the declared package manager; for a Starlight-style pnpm workspace run pnpm install --frozen-lockfile and pnpm --filter @astrojs/starlight test --run. Inspect sidebar navigation and i18n changes with their surrounding implementation, configuration and tests. Post one GitHub review with concrete failure scenarios and current-head file-and-line citations, separating blocking defects from suggestions and including exact test outcomes and setup limitations. If posting is unavailable, return the review and say it was not posted. Do not push commits, approve without evidence or merge.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **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.
2. **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.
3. **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 deliverable is one GitHub review on the caller's pull request, plus the session's verification summary. Each actionable finding identifies a changed line, the surrounding path that makes it fail and a concrete sidebar or locale configuration that demonstrates the failure. Blocking defects and optional improvements are separated. When no defensible defect is found, the review says so without inventing comments to meet a quota.

The maintainer checks that the review refers to the current head revision, that pnpm installed from the checked-in lockfile and that the reported Vitest command entered the correct package projects. A passing suite does not dismiss an untested locale case, and a dependency installation failure does not prove the patch is broken. If GitHub posting is unavailable, the result explicitly contains an unposted review rather than claiming an external action succeeded. No fixing branch or merge is part of this request.

## Run it on every Astro pull request opened

Your GitHub webhook receiver selects pull_request.opened for approved repositories, validates the delivery and appends the PR URL and base/head revisions to input. It calls POST /o/{org}/sessions once for that review job. A later update can start a separate review of the new head, but duplicate deliveries for the same revision should not create repeated reviews. Repository access requires a Rush GitHub App installation that covers your own target.

Keep the review request separate from a fix request. This task explicitly authorizes posting one review and forbids pushing commits. Collect the review link and command summary through the session read or the key's completion webhook. A configured receiver that merely starts a session is not a substitute for checking whether the returned result actually confirms the review was posted.

## Why run it on Rush?

Astro theme review often involves workspace packages, generated virtual modules and several locale fixtures. Rush provides a separate sandbox for the PR's installation and tests, avoiding changes to the maintainer's current pnpm workspace. The agent can read the navigation context and run the configured projects while the reviewer continues working on another branch.

Multiple pull requests can be reviewed independently within the key's concurrency limit. Each session retains command arguments and output, making it possible to inspect whether a review used the correct package or accidentally ran an unrelated root command. The useful evidence is a reproducible configuration, an exact changed line and an honest test result. A long list of diff-only guesses would not establish a sidebar regression.

## Frequently asked questions

### Should the review run npm install and npx vitest run?

The inspected Starlight workspace declares pnpm and configures tests inside its package. The request follows that setup rather than the topic's generic npm assumption. For a different Astro repository, the agent reads its declared package manager and test scripts first.

### Can it review locale behavior when tests pass?

Yes, if a concrete configuration exposes a failure outside existing coverage. The finding must explain the affected locale, route and expected behavior. A passing suite is evidence about tested cases, not proof about every translated navigation path.

### Will it commit fixes while reviewing?

No. This request authorizes a review and command execution, with no pushed commits. A fix belongs in a separate request after the maintainer decides which findings to address.

### How does the agent know which PR to review?

The webhook caller appends the target URL and revision identifiers to input. The agent verifies the checked-out head before reporting line references. The example repository URL is a placeholder for your own installed application.