flux-gitops
Skill4 starsChanged 10 months agoMITView on GitHub
Flux CD GitOps scaffolding: multi-environment repos, infrastructure components, image automation, External Secrets integration, Kustomize overlays.
In this repository2 other files it gives its agents.
- go-developmentSkill
- helm-chart-developerSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 8 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 84
Create directory structure per references/project-structure.md
- Very specific: line 134
Validation: Run kubectl kustomize infra/{env}/...
- Very specific: line 159
Create image automation in apps/{env}/:
- Distinctive: line 182
CRITICAL: Never use deprecated versions (v2beta1, v2beta2).
- Distinctive: line 243
CRITICAL: Never hardcode versions. Always use Context7 to get current versions.
- Distinctive: line 255
Before creating ANY HelmRelease or vendoring CRDs:
- Distinctive: line 288
Use versions from memory or previous sessions
- Distinctive: line 293
Verify version is current before deployment
- Very specific: line 294
Use empty version: "" as placeholder until Context7 fetched
- Very specific: line 300
Before committing GitOps manifests, validate structure with kubectl kustomize:
- Distinctive: line 321
Before completing GitOps scaffolding:
- Distinctive: line 323
Structure: All directories created per pattern
- Distinctive: line 327
API Versions: All using current stable APIs
- Very specific: line 373
orchestration-kustomizations.yaml: - All 5 Flux Kustomizations with dependsOn chain - Very specific: line 399
conventional-commit: - Commit message formatting
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Flux GitOps Scaffold
Purpose
Scaffold and manage Flux CD GitOps repositories with:
- Multi-environment structure (dev/staging/prod)
- Infrastructure components (cert-manager, ingress-nginx, external-secrets)
- Application deployments with image automation
- External Secrets integration for secret management
Complementary to: helm-chart-developer skill (for Helm chart authoring).
This skill focuses on GitOps project structure and Flux-specific patterns.
When to Use
Activate for:
- Creating new GitOps repositories from scratch
- Adding infrastructure components to existing GitOps projects
- Setting up application deployments with image automation
- Configuring Flux Kustomization dependencies
- Multi-environment deployment patterns
Project Structure Pattern
gitops/
├── clusters/{env}/ # Flux orchestration layer
│ ├── kustomization.yaml # Aggregates all Flux Kustomizations
│ ├── 00-crds.yaml # CRDs (prune: false, wait: true)
│ ├── 01-controllers.yaml # dependsOn: crds
│ ├── 02-cluster-configs.yaml # dependsOn: controllers
│ ├── 03-services.yaml # dependsOn: cluster-configs
│ ├── 99-apps.yaml # dependsOn: services, cluster-configs
│ └── flux-system/
│
├── infra/
│ ├── base/
│ │ ├── cluster/
│ │ │ ├── controllers/ # cert-manager, ingress-nginx, ESO
│ │ │ └── configs/ # ClusterIssuer, ClusterSecretStore
│ │ └── services/ # redis, postgres (with configs/secrets)
│ ├── crds/ # Vendored CRDs (applied first)
│ │ ├── kustomization.yaml # Aggregates all CRD subdirs
│ │ ├── cert-manager/
│ │ └── external-secrets/
│ └── {env}/
│ ├── cluster/
│ │ ├── controllers/ # values only (ConfigMapGenerator)
│ │ └── configs/ # plain manifests
│ └── services/ # values + configs + secrets
│
├── apps/
│ ├── base/{app}/ # Base HelmRelease
│ └── {env}/{app}/ # values + configs + secrets
│ ├── configs/ # Plain ConfigMaps
│ └── secrets/ # ExternalSecrets
│
└── charts/app/ # Generic application chartStructure Principle: Base + overlay with explicit layering. Controllers → Configs → Services → Apps.
See references/project-structure.md for detailed layout.
Core Workflows
1. Initialize GitOps Project
To create a new GitOps project:
- Gather requirements via AskUserQuestion:
- Project name
- Environments (dev, staging, prod)
- Secrets provider (AWS/GCP/Azure/Vault)
- Cloud region/project
- Create directory structure per
references/project-structure.md - Generate cluster orchestration files (numbered Kustomizations)
- Copy generic Helm chart from
assets/charts/app/ - Fetch latest component versions via Context7
2. Add Infrastructure Component
Three workflows depending on component type:
2a. Add Controller (cert-manager, ingress-nginx, ESO)
- FIRST: Get latest version via Context7 (see Version Management section)
- Vendor CRDs to
infra/crds/{component}/:kustomization.yaml- Resources referencecrds.yaml- Vendored from upstream (curl from release)
- Create
infra/base/cluster/controllers/{component}/:kustomization.yaml- Resources referencehelm.yaml- HelmRepository + HelmRelease (installCRDs: false)
- Create
infra/{env}/cluster/controllers/{component}/:kustomization.yaml- refs base + ConfigMapGeneratorvalues.yaml- Environment values (installCRDs: false)
- Update
infra/crds/kustomization.yamlaggregator - Update
infra/{env}/cluster/controllers/kustomization.yamlaggregator
2b. Add Cluster Config (ClusterIssuer, ClusterSecretStore)
- Create
infra/base/cluster/configs/{component}/:kustomization.yaml- Resources reference{component}.yaml- Plain manifest template
- Create
infra/{env}/cluster/configs/{component}/:kustomization.yaml- refs base{component}.yaml- Environment-specific manifest
- Update
infra/{env}/cluster/configs/kustomization.yamlaggregator
2c. Add Service (redis, postgres)
- FIRST: Get latest version via Context7 (see Version Management section)
- Create
infra/base/services/{component}/:kustomization.yaml- Resources referencehelm.yaml- HelmRepository + HelmRelease
- Create
infra/{env}/services/{component}/:kustomization.yaml- refs base + ConfigMapGenerator + configs + secretsvalues.yaml- With envFrom injectionconfigs/{component}.config.yaml- Plain ConfigMapsecrets/{component}.external.yaml- ExternalSecret
- Update
infra/{env}/services/kustomization.yamlaggregator
Validation: Run kubectl kustomize infra/{env}/... to validate before commit.
See references/infra-components.md for supported components.
3. Add Application
To add application with image automation:
- Gather via AskUserQuestion:
- Registry type (ECR/GCR/ACR/GHCR)
- Image repository URL
- Tag pattern (dev: run_id, prod: semver)
- Create
apps/base/{app}/:kustomization.yaml- Resources referencehelm.yaml- HelmRelease referencingcharts/app
- Create
apps/{env}/{app}/:kustomization.yaml- refs base + ConfigMapGenerator + configs + secretsvalues.yaml- With envFrom injectionpatches.yaml- Image tag with automation markerkustomizeconfig.yaml- ConfigMap name replacementconfigs/{app}.config.yaml- Plain ConfigMap (non-sensitive)secrets/{app}.external.yaml- ExternalSecret (sensitive)
- Create image automation in
apps/{env}/:image-automation.yaml- ImageRepository + ImagePolicy + ImageUpdateAutomation
- Update
apps/{env}/kustomization.yamlaggregator
See references/image-automation.md for registry-specific patterns.
API Versions
Always use these API versions:
| Resource | API Version |
| HelmRelease | helm.toolkit.fluxcd.io/v2 |
| HelmRepository | source.toolkit.fluxcd.io/v1 |
| Kustomization (Flux) | kustomize.toolkit.fluxcd.io/v1 |
| GitRepository | source.toolkit.fluxcd.io/v1 |
| ImageRepository | image.toolkit.fluxcd.io/v1 |
| ImagePolicy | image.toolkit.fluxcd.io/v1 |
| ImageUpdateAutomation | image.toolkit.fluxcd.io/v1 |
| ExternalSecret | external-secrets.io/v1 |
| ClusterSecretStore | external-secrets.io/v1 |
CRITICAL: Never use deprecated versions (v2beta1, v2beta2). If found, propose migration.
Key Patterns
See references/key-patterns.md for detailed YAML patterns:
- HelmRelease with ConfigMap Values
- ConfigMap Generator (Kustomize overlay pattern)
- Flux Kustomization with Dependencies
- Image Automation Markers
- Configs & Secrets Pattern (ConfigMap, ExternalSecret, envFrom)
Orchestration
Five Flux Kustomizations with explicit dependsOn chain:
| File | DependsOn | Path | Critical Settings |
00-crds.yaml | - | ./infra/crds | prune: false, wait: true |
01-controllers.yaml | crds | ./infra/{env}/cluster/controllers | wait: true, timeout: 10m |
02-cluster-configs.yaml | controllers | ./infra/{env}/cluster/configs | wait: true, timeout: 5m |
03-services.yaml | cluster-configs | ./infra/{env}/services | wait: true, timeout: 10m |
99-apps.yaml | services, cluster-configs | ./apps/{env} | wait: true, timeout: 10m |
Why this order:
- CRDs must exist before controllers can install CRs
- Controllers must be running before configs (ClusterIssuer needs cert-manager)
- Cluster configs (ClusterSecretStore) needed before services can fetch secrets
- Services provide infrastructure for apps (redis, postgres)
Aggregator Pattern
Each directory Flux points to MUST have kustomization.yaml:
# infra/{env}/cluster/controllers/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- cert-manager
- ingress-nginx
- external-secretsCRD Management
CRITICAL: Vendor CRDs into repository. Do NOT use nested Flux Kustomizations for CRDs.
# Download vendored CRDs (use Context7 to get {VERSION} first!)
curl -sL https://github.com/cert-manager/cert-manager/releases/download/{VERSION}/cert-manager.crds.yaml \
> infra/crds/cert-manager/crds.yamlFor HelmReleases with CRDs, disable CRD installation:
# values.yaml
installCRDs: falseVersion Management (MANDATORY)
CRITICAL: Never hardcode versions. Always use Context7 to get current versions.
Enforcement Layers
- SessionStart hook — Reminds about Context7 when k8s/Flux project detected
- PreToolUse hook — Checks versions in HelmRelease files:
- Empty version (
version: "") → Blocks and requires Context7 - Hardcoded version (
version: "1.2.3") → Asks for verification
- Empty version (
- Documentation — No hardcoded versions provided (only Context7 workflow)
Workflow (REQUIRED for every HelmRelease)
Before creating ANY HelmRelease or vendoring CRDs:
# Step 1: Resolve library ID
Tool: resolve-library-id
Parameter: libraryName="{component}"
# Step 2: Query docs for version
Tool: query-docs
Parameters:
libraryId: "/{org}/{project}"
topic: "helm chart installation version"
# Step 3: Use version from documentationExample: cert-manager
Tool: resolve-library-id
libraryName: "cert-manager"
# Returns: /jetstack/cert-manager
Tool: query-docs
libraryId: "/jetstack/cert-manager"
topic: "helm installation version"
# Extract version from documentationGuardrails
NEVER:
- Copy versions from examples or documentation files
- Use versions from memory or previous sessions
- Hardcode versions without Context7 verification
ALWAYS:
- Fetch version via Context7 for EVERY new HelmRelease
- Verify version is current before deployment
- Use empty
version: ""as placeholder until Context7 fetched
See references/version-matrix.md for Context7 library IDs per component.
Validation
Before committing GitOps manifests, validate structure with kubectl kustomize:
# Validate infra component
kubectl kustomize infra/dev/cert-manager
# Validate apps
kubectl kustomize apps/dev
# Validate entire environment (from cluster kustomization)
kubectl kustomize clusters/devThis catches:
- Missing files referenced in kustomization.yaml
- Invalid patches
- YAML syntax errors
- Invalid resource references
Definition of Done
Before completing GitOps scaffolding:
- Structure: All directories created per pattern
- Validation:
kubectl kustomizepasses for all directories - Dependencies:
dependsOnset correctly in Kustomizations - Versions: Latest versions fetched via Context7
- API Versions: All using current stable APIs
- Values: ConfigMapGenerator with
disableNameSuffixHash: true - Secrets: ExternalSecret configured (not hardcoded secrets)
- Image Automation: Markers set for automated updates
Anti-Patterns
| Avoid | Instead |
| Hardcoded secrets in values | ExternalSecret + secretRef |
prune: true for CRDs | prune: false to prevent deletion |
Missing dependsOn | Always set dependencies |
crds: CreateReplace | crds: Skip + vendored CRDs |
installCRDs: true in values | installCRDs: false (CRDs managed separately) |
| Nested Flux Kustomization for CRDs | Vendor CRDs into repo (race condition!) |
Missing wait: true | Always use wait: true + timeout |
| Missing aggregator kustomization.yaml | Every Flux path needs kustomization.yaml |
v2beta1/v2beta2 APIs | Use stable v2/v1 APIs |
| Hash suffix on ConfigMaps | disableNameSuffixHash: true |
{name}-{env} suffix | Skip suffix if env = namespace |
Examples
Trigger phrases:
- "Create a new GitOps repository for my microservices"
- "Add cert-manager to my Flux project"
- "Set up image automation for my app"
- "Configure multi-environment deployment"
- "Add ingress-nginx infrastructure"
- "Set up External Secrets with AWS"
Additional Resources
Reference Files
For detailed patterns, consult:
references/project-structure.md- Full directory layoutreferences/image-automation.md- Registry-specific automationreferences/infra-components.md- Infrastructure patternsreferences/version-matrix.md- Current versions + Context7 usage
Example Files
Working examples in examples/:
Orchestration:
orchestration-kustomizations.yaml- All 5 Flux Kustomizations with dependsOn chain
Controllers & Configs:
infra-base-helm.yaml- Base HelmRepo + HelmRelease for controllercluster-controller-overlay.yaml- Controller overlay (values only)cluster-config-overlay.yaml- Cluster config overlay (ClusterIssuer)
Services & Apps (with configs/secrets):
service-overlay-full.yaml- Service with configs/secretsapp-overlay-full.yaml- App with configs/secretsconfig-configmap.yaml- Plain ConfigMap patternvalues-with-envfrom.yaml- values.yaml with envFrom injection
CRDs & Image Automation:
crds-kustomization.yaml- Vendored CRDs aggregatorimage-automation-ecr.yaml- ECR automationimage-automation-ghcr.yaml- GHCR automationexternal-secret.yaml- ESO pattern
Assets
Generic chart template in assets/charts/app/ - copy to target project.
Related Skills
helm-chart-developer- Helm chart authoring and ESO integrationconventional-commit- Commit message formatting
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

