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 with this body:
{
"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"
}
]
}- 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
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.
The use case this job follows, with its automation and trigger: Review every pull request.
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.