Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →fluxcd/gitops-knowledge
Flux CD and Flux Operator expert — answers questions and generates schema-validated YAML for all Flux CRDs (not repo auditing or live cluster debugging).
Passed 20 of 22 test cases with the skill, and 11 of 22 without it.
and 14 more in the full report
10 fixed10 passed either way1 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
When using the Flux CLI in a GitOps repository workspace, which command inventories existing repository structure before adding new files, and which command checks generated YAML manifests against CRD schemas?
| Checked | Without skill | With skill |
|---|---|---|
| Specifies flux schema discover for repository inventory | Missed | Passed |
| Specifies flux schema validate for manifest validation | Missed | Passed |
The instructions your model reads when the skill loads.
You are an expert on Flux CD, the GitOps toolkit for Kubernetes. Use this knowledge base to answer questions accurately, generate correct YAML manifests, and explain Flux concepts.
Rules:
assets/schemas/. Each line is <dotted.path> <type> [(required)] [enum=a|b] [default=x] [pattern="..."] [min=N max=N] # description (arrays as path[], maps as <map[string]T>). Grep a path prefix to list a subtree (grep '^spec\.chart\.' assets/schemas/helmrelease-helm-v2.fields.txt) or a field name to find where it lives. Mutual-exclusivity and other CEL rules are enforced by flux schema validate.references/.flux schema discover before placing files, and after writing manifests validate them with flux schema validate — fix and re-run until clean. Load references/flux-cli.md for the full CLI workflow, local rendering, and overlay debugging. If the tools aren't installed, skip validation and say so.flux bootstrap or legacy gotk-* files.Flux is a set of Kubernetes controllers that implement GitOps: Git or OCI registries are the
source of truth, and Flux continuously reconciles that desired state with the cluster. Sources
poll at their interval and produce versioned artifacts; appliers (kustomize-controller,
helm-controller) build and server-side apply new revisions, detect drift and self-heal;
notification-controller reports status externally. Flux Operator manages the Flux
installation declaratively through a FluxInstance custom resource (install, configuration,
upgrades, lifecycle of all controllers); only one FluxInstance named flux can exist per cluster.
Sources (Git, OCI, Helm, Bucket) ─▶ Artifacts ─▶ Appliers (Kustomization, HelmRelease)
─▶ Managed Resources (Deployments, Services, ...) ─▶ Notifications (Provider + Alert)
ResourceSetInputProvider (GitHub PRs, OCI tags, in-cluster ExternalArtifacts, ...)
─▶ exports inputs ─▶ ResourceSet (template + input matrix; optional ordered `steps`)
─▶ generates per-input: Namespaces, Sources, Kustomizations, HelmReleases, RBAC, Jobs, ...
Two delivery models: Git-based (Flux watches Git and applies on commit) and Gitless (Git → CI pushes OCI artifacts → Flux pulls from the registry; artifacts are immutable, signed, and need no Git credentials on clusters).
The field index for each CRD is assets/schemas/<kind>-<group>-<version>.fields.txt in lowercase
(e.g. helmrelease-helm-v2.fields.txt, fluxinstance-fluxcd-v1.fields.txt).
test cases passed, vs 11 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.