What the agent does
The agent starts by finding every app Argo CD could sync, because a GitOps repository rarely says which directories are apps. In a repository shaped like argoproj/argocd-example-apps it finds kustomization.yaml in kustomize-guestbook, sock-shop (28 resources under base/) and pre-post-sync, a Chart.yaml in helm-guestbook, helm-dependency, blue-green and apps, Jsonnet in jsonnet-guestbook, plain manifests in guestbook, helm-hooks and sync-waves, and ApplicationSet objects under applicationset/. It reads apps/values.yaml too, since that app-of-apps chart lists the paths Argo CD is actually pointed at, and uses it to check that every listed path exists.
Then it writes scripts/validate.sh, which renders each app the way Argo CD would: kustomize build <dir> for Kustomize apps, helm dependency build and helm template <dir> for charts, once per values file where a chart ships more than one (helm-guestbook has values.yaml and values-production.yaml, helm-dependency has values-nomaria.yaml). It pipes each render into kubeconform -strict -summary with a pinned Kubernetes version, so an apiVersion the cluster no longer serves fails here instead of at sync time. Apps that are plain YAML go straight to kubeconform.
Custom resources need their own schemas, and this is where most validation scripts quietly pass everything. blue-green renders an Argo Rollouts Rollout and apps renders argoproj.io/v1alpha1 Application objects, which have no schema in the default kubeconform registry. The agent adds the community CRD catalog as a second -schema-location so those kinds are checked, and lists any kind still unmatched rather than passing -ignore-missing-schemas for the whole repository.
It runs the script in its sandbox before writing any workflow, and records what each app does. In this repository that turns up real findings to report: pre-post-sync/kustomization.yaml still uses the deprecated bases: field, helm-dependency pulls wordpress 9.0.3 from https://charts.helm.sh/stable, the archived stable repository, and plugins/kustomized-helm expects an all.yaml its .gitignore excludes, because a config management plugin generates it at sync. Then it adds .github/workflows/validate.yml to run the same script on pull requests.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Add validation to this GitOps repository so every app renders and passes schema checks before Argo CD syncs it. Find every Kustomize app (kustomization.yaml), Helm chart (Chart.yaml, rendered once per values file) and plain manifest directory. Write scripts/validate.sh that renders each one with kustomize build or helm template and validates the output with kubeconform -strict against a pinned Kubernetes version, using the CRD schema catalog for Argo CD and Argo Rollouts kinds; list any kind that still has no schema instead of ignoring missing schemas globally. Add .github/workflows/validate.yml that runs the script on pull requests and pushes to the default branch. Run the script, and in the pull request description list every app with its result and the exact error for any that fail. Do not change the apps themselves. Open a pull request.",
"resources": [
{
"url": "https://github.com/your-org/your-gitops-repo"
}
]
}- 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 a pull request that adds scripts/validate.sh and .github/workflows/validate.yml and changes nothing under the app directories. The workflow installs pinned versions of kustomize, Helm and kubeconform, runs the script, and fails the job if any app fails to render or validate. Each app is its own labelled section in the log, so a red run points at one directory.
The description is the report: a table of every app with how it was rendered (Kustomize, Helm with which values file, plain YAML, skipped plugin), its result, and the exact error for each failure, such as a chart repository that no longer serves an index or a kind with no schema. The session's trajectory keeps every kustomize build, helm template and kubeconform call the agent ran with its output.
Before merging, a reviewer checks that the pinned Kubernetes version matches the clusters Argo CD deploys to, that apps skipped as plugins are really generated at sync, and whether a failing app should be fixed in a follow-up or excluded on purpose. Once the workflow is green, make it a required check so an unrenderable app cannot reach the branch Argo CD watches.
Run it on every Argo CD sync failure
Argo CD notifications can call a webhook when an Application's sync fails. Point that at your server and have it send a request naming the app's path, asking the agent to render it, find why it no longer validates and open a pull request with the fix. Each failure gets its own sandbox and its own pull request, and the validation script from this page is the check that proves the fix.
Set a webhook URL on the API key and Rush POSTs run.completed or run.failed when the turn finishes, with the session URL, so the same server can post the pull request link back to the channel that saw the sync alert.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Validating a GitOps repository well means rendering every app with the tool versions CI will use, pulling chart dependencies from repositories that may have moved, and finding schemas for CRDs. On a laptop that is a pile of local Helm caches and kubeconform flags that pass because something was skipped. In its own sandbox the agent installs pinned tools from nothing, renders each app, and shows exactly which ones it could not validate and why.
The proof is the workflow running on its own pull request plus the per-app table, and the trajectory has the raw output behind every row. Because each run is independent, the same request can add validation to every GitOps repository your teams keep, each with a pull request a platform engineer reviews before it becomes a required check.
Frequently asked questions
Will it change my manifests or charts?
No. The request tells it to add only the script and the workflow, and to report failing apps instead of fixing them. If you want the fixes too, send a follow-up on the same session naming the apps, and it changes them on the same branch where you can review each diff.
How does it handle CRDs like Rollout and Application?
It adds the community CRD schema catalog as a second schema location for kubeconform, so argoproj.io kinds are validated against real schemas. Any kind that still has no schema is listed in the pull request by name, rather than being hidden by a global -ignore-missing-schemas.
What about Helm charts with dependencies from old repositories?
The script runs helm dependency build before helm template, so a dependency whose repository is gone fails visibly. In argocd-example-apps that is helm-dependency, which still points at charts.helm.sh/stable; the pull request names the chart, the repository and the error.
Does it need access to my cluster?
No. Rendering and schema validation are offline checks against a pinned Kubernetes version, so the sandbox needs no kubeconfig. That also means it cannot catch problems only the live cluster sees, such as a missing namespace or an admission policy, and the pull request says so.