What the agent does
The agent checks out the pull request branch in its own cloud sandbox and reads the module before it plans anything. In a module like terraform-aws-modules/terraform-aws-vpc, versions.tf requires Terraform 1.0 or newer and the AWS provider 6.28 or newer, main.tf declares the VPC, subnet, route-table, NAT and other resources, and examples/ holds a dozen runnable configurations (simple, complete, ipv6-dualstack, network-acls and more) that call the module with source = "../../". The .pre-commit-config.yaml lists the checks the project runs: terraform_fmt, terraform_validate, terraform_docs and tflint. The agent installs Terraform and reads which example configurations use the files the pull request changed.
Then it runs the checks the prompt names, scoped to those examples. It runs terraform fmt -check across the diff, terraform init and terraform validate on each affected example, and terraform plan with a local backend and no cloud credentials beyond planning. Because the examples are self-contained, the plan runs without an AWS account standing up anything; it produces the change set Terraform would apply.
It reads each plan for the two things the prompt asks about. First, every resource the change would replace or destroy: Terraform marks these in the plan as -/+ (replace) or - (destroy), and the agent lists each one with the example it came from and the attribute that forced it, so a change that quietly recreates a NAT gateway or a subnet is visible before it merges. Second, new public exposure: a security group rule opening to 0.0.0.0/0, a subnet flipping map_public_ip_on_launch to true, or a change touching aws_default_security_group, each flagged with the file and the resource.
When the examples are planned it posts one review comment on the pull request: the format and validate results, then the destroy-or-replace list and the exposure list, each item naming the example, the resource and the reason. It changes no Terraform and applies nothing; the review is the output, and a reviewer decides from it whether the change is safe to merge.
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. Run terraform fmt -check across the diff, and terraform init, validate and plan for every example under examples/ that uses the changed files, with a local backend and no cloud credentials beyond the plan. Post one review comment: the fmt and validate results, each resource the change would replace or destroy with the example and the attribute that forced it, and any new public exposure (a security group opening to 0.0.0.0/0, a subnet gaining a public IP, a change to the default security group). Apply nothing and change no Terraform.",
"resources": [
{
"url": "https://github.com/your-org/your-module/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 comment on the pull request. It opens with the mechanical checks, terraform fmt -check and terraform validate per affected example, so a reviewer sees first whether the change is even well-formed. Then it lists each resource the plan would replace or destroy, grouped by example, each with the attribute change that forced the replacement.
After that it lists the new public exposure the plan introduces, each item naming the file and resource: a rule opening to the internet, a subnet that now assigns public IPs, a change to the default security group. The session transcript keeps every command, the init, validate and plan for each example, so a reviewer can rerun any plan and see the same change set rather than trusting the summary.
A reviewer reads the comment to decide whether to merge. A destroy on a stateful resource, or a new path to the internet, is the kind of change a plan surfaces and a diff alone hides, so the review turns the pull request into a decision made from the actual change set. Because the agent applied nothing, no cloud resource moved; the only output is the comment.
Run it on every a pull request that touches .tf files
Run it on every change to the module. An automation with a GitHub trigger on pull-request events starts one run per pull request, so the plan and the destroy list are posted as a comment before anyone reviews by eye, the way a plan job in CI would but without wiring Terraform into your pipeline.
Each run reads the current diff and plans only the examples the changed files reach, so the comment reflects the pull request as it stands that moment. A push that adds a commit fires another run, keeping the review in step with the branch.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
Running terraform plan to review a change means a checkout, a matching Terraform version, provider downloads and a clean backend, which is awkward to do for every pull request on a laptop and risky to point at real state. In a Rush sandbox the agent installs Terraform, inits each example against a local backend, and plans on its own disk, so no plan touches your cloud account or your state files.
A Terraform review is only as good as the plan behind it. Because every init, validate and plan is in the session transcript, a reviewer can rerun any example and confirm the destroy list and the exposure list for themselves instead of trusting a summary. Several modules or pull requests can be reviewed at once, one run each, up to the key's concurrent-run limit.
Frequently asked questions
Does it apply any Terraform?
No. It runs fmt, validate and plan only, with a local backend, and applies nothing. The prompt says to change no Terraform and apply nothing, so no cloud resource is created, replaced or destroyed; the plan is read, not executed.
Does it need AWS credentials?
The examples plan against a local backend without standing anything up, so planning needs no live account. Where the provider requires a region or similar to plan, the example supplies it; the agent uses no credentials beyond what a plan needs and applies nothing.
How does it know which examples to plan?
It reads which configurations under examples/ use the files the pull request changed and plans those, rather than every example. The comment names the example each finding came from, so a destroy or exposure is tied to the configuration that produces it.
Can it review a private module?
Yes. Install the Rush GitHub App on the repository; the pull request URL in resources is reachable through that installation. The agent checks out the branch, runs the plans in its sandbox, and posts the review comment through the same App.