What the agent does
The agent starts from the pull request's own branch in a fresh sandbox and works out which CDK app the change touches. In a repository shaped like aws-samples/aws-cdk-examples that matters, because the root holds csharp/, go/, java/, python/ and typescript/, each a folder of independent apps with their own package.json, cdk.json and lockfile. It reads scripts/build-typescript.sh to see how the project itself builds a change: walk up from the changed file to the first package.json, skip the directory if it holds a DO_NOT_AUTOTEST file, run npm ci or yarn install --frozen-lockfile depending on the lockfile, then npm run build, npm run --if-present test, and finally scripts/synth.sh.
It runs that same sequence for each changed app rather than inventing one. scripts/synth.sh copies scripts/fake.context.json into place as cdk.context.json when the app has none and sets AWS_DEFAULT_REGION=us-east-1, which is what lets cdk synth run with no AWS account at all. In an app like typescript/static-site, cdk.json sets the app command to npx tsc && npx tsx index.ts, package.json pins aws-cdk 2.1133.0 and aws-cdk-lib 2.262.1, and there is no test script, so npm run --if-present test does nothing and the synthesized template is the only evidence. In an app like typescript/amazon-mq-rabbitmq-lambda, npm test runs Jest assertions built on Template.fromStack, and the agent reads which properties they pin before deciding whether the change is covered.
Then it synthesizes twice: once on the pull request's base commit and once on its head, and compares the cdk.out/*.template.json files. A logical ID that disappears from one side and appears renamed on the other is a delete and a create, and so is a change to a property CloudFormation cannot update in place, such as a DynamoDB table's key schema or an explicit bucket name. cdk diff --template against the base template gives the same comparison in CDK's own format, again without credentials. This is how the review catches a refactor that moves a construct to a new scope and quietly replaces a table with data in it.
With the templates in hand, the agent reads the change the way a security reviewer would. It looks for grant* calls that widen access (grantReadWrite where the code only reads, grantFullAccess), addToPolicy statements with * resources or actions, and RemovalPolicy.DESTROY with autoDeleteObjects: true, which typescript/static-site/static-site.ts uses with the comment NOT recommended for production code. It checks the result against cdk.json flags such as @aws-cdk/aws-iam:minimizePolicies, which changes how statements are merged in the template, and then posts one review on the pull request with file and line for each finding.
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 repository. For each CDK app the change touches, run the project's own build: npm ci or yarn install from the lockfile, npm run build, npm test if it exists, then cdk synth with scripts/fake.context.json when there is no cdk.context.json. Synthesize the base commit too and compare the templates in cdk.out: list every resource that would be replaced or deleted, every IAM statement that widens access, and every RemovalPolicy.DESTROY or autoDeleteObjects on stateful resources. Post one review that cites file and line for every finding, with the command whose output shows it. Do not push commits.",
"resources": [
{
"url": "https://github.com/your-org/your-cdk-app/pull/123"
}
]
}- 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, not a branch. Each comment sits on the changed line in the stack file (lib/*-stack.ts or the app's entry file) and says what the synthesized template shows: the logical ID that changes and the resource type behind it, the IAM action and resource the new statement grants, or the removal policy a stateful resource now has. Findings are grouped by app when one pull request touches several, and the review summary lists the commands it ran in each directory.
The proof is in the session. Its transcript keeps the output of npm ci, npm run build, the Jest run and both cdk synth runs, plus the template comparison the replacement findings come from, so a reviewer can open the exact output behind any comment. When a change has no test and synth passes, the review says that the template is the only check and names which resource it compared, instead of calling the change safe.
Before merging, a reviewer confirms each replacement is intended or asks for the construct ID to be pinned, checks that widened grants match what the code really calls, and decides whether RemovalPolicy.DESTROY belongs on that resource in a real account. A replacement on a table, a bucket or a user pool is the comment to resolve first.
Run it on every pull request to your CDK app
An automation with a GitHub trigger on pull_request.opened and pull_request.synchronize starts this review on every push to an open pull request, so a force-pushed fix gets a fresh synth and comparison. From your own server, take GitHub's pull_request webhook and send this body with the pull request URL in resources, using the head commit SHA as the Idempotency-Key, so a redelivered webhook returns the run already started instead of reviewing twice.
Set a webhook URL on the API key to get run.completed when the review is posted. If the author pushes a fix, a follow-up message to the same session asks it to synthesize again and re-check its own findings; the parked sandbox wakes with cdk.out and node_modules still in place.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
A CDK change is hard to review from the diff because the risk is in what it synthesizes to. A one-line move of a construct into a new parent changes its logical ID, and the diff shows nothing about a table being replaced. Running npm ci and cdk synth twice for every pull request on a laptop is slow enough that most reviewers skip it. On Rush each review gets its own sandbox with its own clone, so the base and head synths run side by side, and nothing touches your working copy or your AWS profile.
The review is checkable. Every finding points to command output in the session's transcript, and the agent needs no AWS credentials because synth.sh and the fake context file already make synthesis work offline. Reviews for pull requests across many apps in the same repository run at once, each in its own sandbox, and each one either cites the output or says what it could not run.
Frequently asked questions
Does the agent need AWS credentials?
No. cdk synth with the repository's scripts/fake.context.json and a fixed AWS_DEFAULT_REGION builds the CloudFormation templates without calling AWS, and the replacement check compares two local templates. Plain cdk diff against a deployed stack would need credentials, so the agent compares against the base commit's synth instead.
How does it tell a replacement from an in-place update?
It compares the base and head templates resource by resource. A logical ID that vanishes and reappears under another ID is a delete and a create. A changed property that CloudFormation documents as requiring replacement, such as a table's key schema, is flagged with the property name, so the reviewer can check it against the CloudFormation reference.
What if the app has no tests?
Many apps in a repository like aws-cdk-examples have no test script, and npm run --if-present test then does nothing. The review says so and treats the synthesized template as the evidence. It can suggest a Template.fromStack assertion for the resource the change touches, but it does not push one, because the prompt forbids commits.
Does it work for Python, Java, Go or C# CDK apps?
Yes, with that language's build. The repository ships scripts/build-python.sh, build-java.sh, build-go.sh and build-csharp.sh beside the TypeScript one, and the agent reads the script for the language of the changed directory. Name the language and its test command in the prompt if your repository has no such script.
Will it approve or block the pull request?
It posts a review with comments and a summary; the prompt decides whether that review is a plain comment or a request for changes. Branch protection and the human approval rules on your repository stay exactly as they are.