What the agent does
The run starts from the repository URL in resources: the agent clones it into its own cloud sandbox and opens the chart the issue names. In prometheus-community/helm-charts, that chart is charts/prometheus-blackbox-exporter/. Chart.yaml reports version 11.20.0 and appVersion v0.29.0, with kubeVersion >=1.21.0-0. Templates already include templates/networkpolicy.yaml, and values.yaml has a networkPolicy block with enabled: false, allowMonitoringNamespace and monitoringNamespaceName.
The existing NetworkPolicy is narrow. When enabled without allowMonitoringNamespace, the template emits an ingress rule of {} (allow all). When allowMonitoringNamespace is true, it allows only pods from the namespace labelled kubernetes.io/metadata.name matching monitoringNamespaceName. There is no list of arbitrary ingress sources, and the blackbox chart has no tests/*.yaml unit suite yet (unlike sibling charts such as prometheus-ipmi-exporter/tests/). CI values under ci/networkpolicy-values.yaml only set enabled: true.
The agent extends networkPolicy with a configurable ingress sources list (namespace selectors and optional pod selectors) that the template renders when enabled is true, keeps the monitoring-namespace shortcut working, and defaults enabled to false so installs do not change behaviour. It adds helm-unittest specs that assert no NetworkPolicy when disabled, and that enabled values render only the configured sources. Chart.yaml version bumps per the repository's chart release practice.
Proving it means the commands the issue names: helm lint on the chart, chart-testing (ct lint) against the repo's config, and helm unittest for the new specs. The agent runs those in the sandbox and fixes template whitespace or values schema issues they surface.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Linear issue labeled agent says: \"Add a NetworkPolicy Option to a Helm Chart. Add networkPolicy.enabled to the prometheus-blackbox-exporter chart, rendering a NetworkPolicy that allows only the configured ingress sources, with unit tests and a chart version bump.\" Do the work in this repository, add tests for it, run helm lint, ct lint and helm unittest, and open a pull request that links back to the issue.",
"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
What comes back is a pull request. Its diff updates charts/prometheus-blackbox-exporter/values.yaml and templates/networkpolicy.yaml, adds unittest files under that chart, bumps Chart.yaml, and may refresh ci/networkpolicy-values.yaml. The description quotes the issue and links back to it.
The checks on the pull request run helm lint, ct lint and helm unittest. A reviewer reads the default (enabled: false), confirms enabled installs no longer rely on an empty allow-all rule when sources are set, and confirms the version bump matches the changelog expectations for the repo. Other exporter charts are untouched.
The session read keeps the record behind the pull request: lint output and the unittest results. Anyone who questions an ingress from stanza can open the rendered fixture the agent asserted on.
Run it on every Linear issue labelled agent
The Project's automation turns the label into the run. In the console, add an automation with a Linear trigger on linear.issue.labeled filtered to the agent label and this prompt; each labelled chart security issue starts its own run in its own sandbox and opens its own pull request on the helm-charts repository.
If the automation is not wanted, a small server can do the same: receive Linear's issue webhook, put the issue text into input, and POST to /o/{org}/sessions with the prometheus-community helm-charts repository in resources. A run.completed webhook on the API key posts the pull request when ct lint and unittest finish.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
On a laptop this job needs Helm, chart-testing and helm-unittest plugins at versions the CI workflows expect, plus a checkout large enough to hold every chart. Each run on Rush boots its own sandbox with that already in reach, runs lint and unittest itself, and keeps every command and its output.
NetworkPolicy changes are easy to get wrong in a shared charts monorepo. Labelling the issue gives blackbox-exporter its own sandbox so a values rename does not collide with someone bumping kube-prometheus-stack on the same machine.
Frequently asked questions
networkPolicy.enabled already exists in values.yaml. What is left?
The flag and template exist, but enabled mode can allow all ingress, and there are no unit tests. The agent adds configurable ingress sources, asserts them with helm-unittest, and bumps the chart version.
Does enabling the policy break Prometheus scrapes?
Only if the configured sources omit the scrape namespace. The monitoring-namespace shortcut and the new sources list are how you allow Prometheus; the default stays disabled so upgrades are safe.
Which chart version gets bumped?
The version field in charts/prometheus-blackbox-exporter/Chart.yaml (11.20.0 at clone time). appVersion stays tied to the blackbox_exporter release unless the issue asks otherwise.
Are Kubernetes integration tests required?
No. The issue asks for unit tests with helm-unittest and lint via helm and ct. Cluster install tests are out of scope unless CI already runs them for this chart.