What the agent does
The agent inventories how the app is packaged. In GoogleCloudPlatform/microservices-demo (Online Boutique) it finds plain manifests under kubernetes-manifests/ (adservice, cartservice, checkoutservice, currencyservice, emailservice, frontend, loadgenerator, paymentservice, productcatalogservice and more), a Kustomize tree at kustomize/ with base/, many components/ (network-policies, service-mesh-istio, spanner, memorystore, …) and kustomize/tests/ combinations, plus helm-chart/ (Chart.yaml name onlineboutique) with templates for the same services.
It reads existing CI so new checks fit. .github/workflows/kustomize-build-ci.yaml only runs kubectl kustomize / kustomize build on base and kustomize/tests/*. .github/workflows/helm-chart-ci.yaml runs helm lint --strict and helm template then kustomize build on the rendered YAML. Neither workflow installs kubeconform nor kube-linter today, and kubevious-manifests-ci.yaml is a different static pass. The agent does not rewrite service YAML to silence policies.
It adds a script (for example scripts/validate-manifests.sh) that (1) builds kustomize/ base and each kustomize/tests/* overlay, (2) runs helm template from helm-chart/ into a temp file, and (3) pipes every render through kubeconform against upstream Kubernetes schemas and kube-linter with checks for missing liveness/readiness probes, resource limits/requests and securityContext. Findings are written to a markdown or text artifact in the branch (or the pull request body) instead of auto-fixing Deployment specs.
It wires the script into a workflow step beside the existing kustomize/helm jobs (or extends those workflows), runs the script in the sandbox so the first push shows the current finding list, and opens a pull request that contains only the script, workflow glue and the findings report. The script enumerates service YAMLs the same way a human would: every file under kubernetes-manifests/ that the base kustomization references, each overlay directory returned by ls -d kustomize/tests/*/, and helm template . from helm-chart/ including the grpc health and spanner value sets the existing helm-chart-ci job already exercises, so findings mention which render path produced each object.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Add a test script and CI step that renders every Kustomize component and the Helm chart in this repository and validates the output with kubeconform against the Kubernetes schemas and with kube-linter for missing probes, limits and securityContext. Fix nothing in the manifests; open a pull request with the checks and their current findings.",
"resources": [
{
"url": "https://github.com/your-org/your-microservices"
}
]
}- 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 the validation script, a CI workflow step, and a checked-in findings list for the current renders. Files under kubernetes-manifests/, kustomize/**/.yaml service patches and helm-chart/templates/ are not modified, matching the prompt.
The pull request description summarises how many objects kubeconform accepted and which kube-linter checks reported issues (for example missing probes on a named Deployment). The trajectory keeps the install lines for kubeconform and kube-linter and the full command output from each render path.
Before merging, a reviewer confirms the script covers base, kustomize/tests and helm template, that schema versions match the cluster version the team runs, and that failing lint rules are ones the team wants visible. Turning findings into manifest fixes is a separate follow-up request.
Run it on every manifest or Helm template changed
On pull requests that touch kubernetes-manifests/, kustomize/ or helm-chart/, POST this session body so the agent refreshes the findings report in a dedicated branch. That keeps schema drift visible without asking a human to run kubeconform locally.
Subscribe the API key webhook to run.completed and forward the session URL to the platform channel. Use max_concurrent to avoid overlapping full-repo renders when many manifest PRs land together.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Rendering every Kustomize component plus the Helm chart is a multi-minute, tool-heavy job (kustomize, helm, kubeconform, kube-linter). Rush runs it in a sandbox with those binaries installed, so your laptop is not tied up downloading schemas or fighting plugin versions.
Because the agent is forbidden to "fix" manifests, the pull request is an honest safety net: CI fails or reports on policy gaps while service YAML stays reviewably unchanged. Several services or overlays can be validated in parallel across runs.
Frequently asked questions
Will it change my Deployments to add probes?
No. The prompt says fix nothing in the manifests. It records kube-linter findings in the pull request so humans can prioritise remediations.
Does this replace the existing kustomize-build-ci job?
It extends the story: build still proves overlays render; the new step proves rendered objects match schemas and policy checks. The agent prefers adding a step or sibling workflow over deleting kustomize-build-ci.yaml.
Which Kubernetes version are the schemas for?
The agent pins a kubeconform schema version in the script (aligned with whatever the README or deploy docs claim, or a current stable if the repo is silent) and states that pin in the pull request. Adjust the pin in review if your clusters differ.
Are Istio or Spanner overlays included?
Yes, insofar as they appear under kustomize/components/ and kustomize/tests/. The script loops those test folders the same way kustomize-build-ci.yaml already does.