What the agent does
The agent starts by finding what Argo CD will render. argoproj/argocd-example-apps includes the guestbook as plain manifests, a Helm chart and a Kustomize application. Reviewing those source files as though they were interchangeable YAML misses how values and transformations affect the deployed resources. The agent maps the pull request's changed paths to the affected application directories, reads the chart and overlay inputs, and records the base and head revisions. It leaves unrelated examples out of the review instead of turning a small deployment change into a repository-wide cleanup.
For Helm it reads helm-guestbook/Chart.yaml, values.yaml and the values files actually selected for the application. It renders with helm template review helm-guestbook, adding the same values arguments the deployment uses. The Deployment template already contains readiness and liveness probes, but draws resources from .Values.resources. The default values set resources to an empty object. The review therefore checks the rendered result rather than reporting that the presence of a resources key means limits exist.
For Kustomize it runs kubectl kustomize kustomize-guestbook and reviews the output alongside the raw guestbook manifests. The kustomization adds namePrefix: kustomize- and includes a Deployment and Service. The Deployment's container declares an image and port without probes, resource settings or a security context. The agent runs kubeconform -strict -summary and kube-linter lint against the rendered files, recording tool versions and the target Kubernetes version supplied by your team. Missing custom-resource schemas are reported as incomplete validation, not silently ignored.
It turns tool output into changed-line comments that explain the actual risk. A readiness omission affects service traffic differently from a missing memory limit; runAsNonRoot also depends on the image's user and filesystem requirements. Findings trace a rendered object back to its template or values file and distinguish newly introduced problems from existing demo defaults. The agent suggests the smallest correction but does not edit manifests, apply resources, contact a cluster or trigger an Argo CD sync. This is a review before deployment, with static checks and their limits stated explicitly.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Review the open pull request for the checked-out branch's Kubernetes and Argo CD application changes; ask for its URL if the PR is ambiguous. Identify affected raw YAML, Helm charts and Kustomize directories. Read the Argo application source settings and render with the actual selected values/overlays, asking for target Kubernetes version if it is not declared. Run kubeconform -strict -summary and kube-linter lint on rendered output, recording versions, commands and schema gaps. Comment on changed lines for containers missing CPU/memory limits, readiness/liveness probes or an appropriate non-root security context. Trace rendered findings to source files, distinguish pre-existing issues and explain image compatibility. Do not edit files, apply manifests, sync Argo CD or access a live cluster.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- 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
The existing pull request receives review comments tied to source lines, plus a summary of the render commands and validator output. A comment on an empty Helm resources value names the affected container and values file; it does not falsely flag the probes that the template already supplies. The result also lists any application that cannot be rendered with the available inputs.
A platform reviewer checks whether the proposed limits fit observed workload usage, whether probe endpoints are meaningful and whether the image supports the suggested security context. Schema validation cannot establish that an application becomes healthy after a sync. The retained command output supports the review, while live rollout testing and the decision to merge stay separate from this read-only task.
Run it on every deployment manifest change
Use your pull request webhook handler to select deployment paths and submit the pull request URL as the repository resource. Include the target Kubernetes version and application values selection in the input so later reviews use the same assumptions. Deduplicate delivery retries with an Idempotency-Key, and use a new request when the head revision changes. Your completion handler can read the session answer and attach its review summary to the team's deployment workflow.
The use case this job follows, with its automation and trigger: Review every pull request.
Why run it on Rush?
Helm rendering and Kubernetes validation often depend on tool versions that differ between laptops. A Rush sandbox gives this pull request its own working directory and recorded commands, without borrowing an engineer's current kubeconfig. The request deliberately needs no cluster access, so testing a proposed configuration does not become an accidental production deployment.
Independent runs can review separate applications in parallel within the API key's concurrency limit. The useful output is the source-to-render explanation and the validator evidence, not a generic checklist pasted under every manifest. Read the transcript to see which values files and overlays were actually considered before accepting a finding.
Frequently asked questions
Does the review require access to my Kubernetes cluster?
No, this request renders and validates locally inside the sandbox. Cluster health, admission policies and runtime behavior need a separately authorized check.
Will it flag probes that a Helm template already defines?
The agent reviews rendered objects before commenting. The example guestbook chart supplies both probes, so a finding must identify a real omission rather than infer one from an unrelated values file.
How does it handle CRDs that kubeconform cannot validate?
The result names the missing schemas and the affected kinds. Supply the project's schema locations when available; an unvalidated resource must remain visible as a coverage gap.
Will it change settings or sync the application?
The prompt forbids both source edits and cluster actions. It returns review comments and suggested corrections for a human to assess before merge.