Run the upstream Flux controller patch release procedure for helm-controller, image-automation-controller, image-reflector-controller, kustomize-controller, notification-controller, source-controller, and source-watcher.
NewMaintained
Automatic
◆DevOps & SRE pack
Last verified 9/3/2026
What it changes
6 of 24 test cases passed with the skill.
Pass-rate lift
—
Tokens
+200%
Agent turns
0%
Response time
-33%
Model gemini-3.6-flashMeasured 9/3/2026v2 · latest is v36 of 24 cases passed with skill · 6 comparable
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 6 comparable cases; this report requires 8.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.6-flash on 10/4/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
See it in action
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 5
Prompt
I've opened the release PR for helm-controller and the CI is currently running. Should we pause here and wait for it to finish before starting on notification-controller?
What was checked, without and with the skill
Checked
Without skill
With skill
switches immediately to starting the next controller without waiting for the continuous integration run to finish
Missed
Passed
case-21 · gemini-3.6-flash · 9/3/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md340 linessingle file
Flux Controller Patch Releases
Use this skill for upstream Flux controller patch releases only. Do not use it
for flux2, pkg, or other non-controller repos.
Supported controllers:
helm-controller
image-automation-controller
image-reflector-controller
kustomize-controller
notification-controller
source-controller
source-watcher
Important rules
Go deep until you block, then switch. Drive one controller all the way
through every step you can do locally — branch, changelog commit, version
bump commit, push, open PR — before switching to the next. Only move on
when you hit something you cannot progress (CI running, PR awaiting review,
tag workflow running). The moment something unblocks (PR merged, CI green,
workflow finished), come back to it immediately — do not finish the current
controller's local work first if an earlier one is ready to advance.
Never block the conversation on long-running operations. CI checks,
release workflow runs, tag-triggered workflows, and similar waits must be
watched in the background so the user can keep steering and so you can pick
up any other controller the moment it unblocks. When a background watch
completes, report the result and proceed.
Always quote PR/issue links as full URLs (e.g.
https://github.com/fluxcd/helm-controller/pull/1465), never the
<owner>/<repo>#<number> shorthand — full URLs are clickable from the
user's terminal, the shorthand is not.
Start background watches on every PR immediately after opening it. Kick
off gh pr checks <num> -R fluxcd/<repo> --watch in the background as
soon as the PR is created so CI status lands in the conversation the
moment it finishes. Do the same for tag-triggered release workflows
(gh run watch <id> -R fluxcd/<repo> in the background). Do not wait
until "everything is pushed" to start watching — start watching the first
PR while you prepare the second. Note that gh pr checks --watch can finish
early, reporting success on a set of checks that does not yet include a run
Audit and validate Flux CD GitOps repositories by scanning local repo files (not live clusters) — runs Kubernetes schema validation, detects deprecated Flux APIs, reviews RBAC/multi-tenancy/secrets management, and produces a prioritized GitOps report. Use when users ask to audit, analyze, validate, review, or security-check a GitOps repo.