# Review Pull Requests on a Gatsby Site

Yes. An agent checks out the pull request, builds the Gatsby site in its own sandbox, checks the generated pages and feed, and posts one review citing file and line.

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

## What the agent does

The agent checks out the pull request's branch and reads what the site can prove about itself. In a site shaped like gatsbyjs/gatsby-starter-blog, `package.json` lists `gatsby` ^5.14.6, React 18 and the official plugin set, a `package-lock.json`, and scripts `build`, `develop`, `serve`, `format` and a `test` that only prints a reminder to write tests and exits 1. There is no workflow under `.github/`, so nothing runs on a pull request today; the build is the only check the repository offers, and the agent treats it as the test suite. `.prettierrc` sets `arrowParens: avoid` and `semi: false`, and `npm run format` rewrites files rather than checking them, so the agent runs `npx prettier --check` on the changed files instead.

It runs `npm ci` and `npm run build`. A Gatsby build is where most review findings surface, because the site is assembled from GraphQL queries at build time: `src/pages/index.js` and `src/templates/blog-post.js` each export a `pageQuery`, `src/components/seo.js` uses `useStaticQuery` for `siteMetadata`, and `gatsby-node.js` runs its own `allMarkdownRemark` query in `createPages` and declares the schema in `createSchemaCustomization` with `Frontmatter` fields `title`, `description` and `date`. A diff that reads a new frontmatter field in a template without adding it to that type, renames `siteMetadata.social.twitter` in `gatsby-config.js` without touching `seo.js`, or changes the sort in `gatsby-node.js` so `previousPostId` and `nextPostId` swap meaning, either fails the build with a query error the review quotes or silently changes every post page, which the review catches by reading the generated pages.

After the build the agent starts `npm run serve` and reads the output in `public/`: the home page lists each post under `content/blog` newest first, each post page carries its `h1`, date and `rel="prev"` and `rel="next"` links as the template renders them, `/rss.xml` from `gatsby-plugin-feed` has one `item` per post with the `content:encoded` body the feed's `serialize` builds, and the manifest and `robots.txt` from `static/` are present. It diffs those against the base branch's build where the pull request touches `gatsby-config.js`, `gatsby-node.js`, a template or a component, so a change to the feed query or the `createFilePath` slug shows up as a concrete difference in URLs or items rather than a guess.

The review reads the diff for the things a build cannot judge. `dangerouslySetInnerHTML` is used for post HTML and for the excerpt on the index page, so a change that feeds it anything other than Markdown the site owns is a blocking finding. A new plugin in `gatsby-config.js` must appear in `package.json` and the lockfile. A `Link` replaced by an `a` tag loses prefetching and client-side routing, and an image moved out of the Markdown loses `gatsby-remark-images` processing, both suggestions with the line. The review cites file and line for every finding, separates blocking from suggestion, quotes the build output and the prettier check, and pushes nothing.

## Start it with one API call

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

```json
{
  "agent": "claude",
  "input": "Review the open pull request on this Gatsby site. Check out its branch and read package.json, gatsby-config.js, gatsby-node.js, the page queries in src/pages and src/templates, and the schema in createSchemaCustomization to learn how pages are built. Run npm ci and npm run build; treat a build failure as the test result and quote it. Start npm run serve and read the generated pages: the post list on the home page, each post page with its heading, date and previous and next links, and /rss.xml with one item per post. Where the diff touches gatsby-config.js, gatsby-node.js, a template or a component, build the base branch too and report what changed in the generated output. Run prettier --check on the changed files. Read the diff for frontmatter fields used but not declared in the schema, siteMetadata keys renamed in one place, dangerouslySetInnerHTML fed anything other than the site's own Markdown, plugins added without a package.json entry, and Link replaced by plain anchors. Post one review that cites file and line for every finding, separates blocking findings from suggestions, and quotes the build and prettier output. Do not push commits.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app/pull/1"
    }
  ]
}
```

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

What comes back is one review on the pull request. It opens with the build result quoted from `gatsby build`, the prettier check, and when the diff touched the build inputs, a short list of what changed in the generated output: pages added or removed, a slug that moved, items that left the feed. Findings follow as file and line with a sentence of reason, blocking ones first.

A reviewer checks the generated-output list against the pull request's stated intent, since that is the fastest way to see whether a config change did more than the author meant, and reads any `dangerouslySetInnerHTML` finding with the source of the content in mind. The session's transcript holds the build log and every page the agent read in `public/`.

Nothing is pushed. After the turn has finished, a follow-up message to the same session can ask for a fix, and the agent commits it from the sandbox that already has `node_modules` and the Gatsby cache.

## Run it on every pull request opened or pushed

In the console, add an automation to the Project with this prompt and a GitHub trigger on `pull_request.opened` and `pull_request.synchronize`. Every push starts a run that builds that commit and posts a review; a redelivered event starts nothing. The trigger fires only for pull requests by an owner, member or collaborator, never from forks, and marking the automation read-only keeps a review run from pushing.

To start reviews from your own server instead, send this request with the pull request URL in `resources` and the delivery id as `Idempotency-Key`, and set a `webhook_url` on the API key to receive `run.completed` with the `session_url` when the review has been posted.

## Why run it on Rush?

This site has no CI and a placeholder test script, so the only real check on a change is a full build with image processing, which nobody wants to run twice on a laptop to compare branches. The sandbox builds the pull request and, when it matters, the base branch too, and reads what came out instead of reasoning about what should have.

A Gatsby review is about generated output: a slug, a feed item, a meta tag. The agent reads those from `public/` with the build log beside them, cites the source line that produced each difference, and several pull requests get that treatment at once, each in its own sandbox with its own `.cache`.

## Frequently asked questions

### The test script exits 1 on purpose. What does the review run?

The build. `npm run build` executes every page query, `gatsby-node.js` and the plugins, so a query or schema mistake fails there with a message the review quotes. The review does not run the placeholder `test` script and says so, and suggests a real suite when the diff would have been caught by one.

### Why build the base branch as well?

Only when the diff touches `gatsby-config.js`, `gatsby-node.js`, a template or a shared component, because then the question is what changed in the generated site, and the honest way to answer it is to compare two `public/` directories. For a change to one post or one page the pull request build is enough.

### Does it check the feed?

Yes. `gatsby-plugin-feed` writes `/rss.xml` at build time from the query and `serialize` function in `gatsby-config.js`, and the review reads it for one item per post with the `content:encoded` body. A change to that query that drops the `html` field or the `slug` shows up as an empty or broken item, cited with the config line.

### Will it flag Prettier formatting?

As a suggestion, with the files. `.prettierrc` is the project's style and `npm run format` rewrites files rather than checking them, so the review runs `npx prettier --check` on the changed files and lists what would be rewritten, without pushing the rewrite.