gitops-patterns

Provides GitOps best practices for ArgoCD, Flux, Argo Rollouts, and progressive delivery strategies. Use when setting up GitOps workflows, configuring continuous delivery, managing Kubernetes deployments declaratively, or when user mentions 'gitops', 'argocd', 'flux', 'progressive delivery', 'reconciliation', 'argo rollouts', 'canary', 'sealed secrets'.

Aller à l'installation

Dépôt: Tibsfox/gsd-skill-creator
Dernière activité de la source: 14 avril 2026 à 07:57
Langue détectée de SKILL.md: anglais
Étoiles: 69
Forks: 9

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.

npx skills add https://github.com/Tibsfox/gsd-skill-creator --skill gitops-patterns

La commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.

Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

SKILL.md

Instructions source · Aperçu en lecture seule

Retour à la recherche Retour à l’installation

goal-ambiguity-gate

Use the moment a request is underspecified and you are about to act on an ASSUMED goal. Enumerate the candidate goals the request could mean, project the action or artifact each one implies, and check whether they diverge: if two or more plausible goals lead to materially different actions or artifacts, ask exactly ONE targeted clarifying question; otherwise proceed on the most-likely goal and state the assumption in one line. Clarification is an evidence-producing action, not a delay — but one question, never an interrogation. Distinct from gsd-spec-phase (GSD-phase-bound, emits a heavy SPEC.md) and intent-router (fetch strategy, not goal disambiguation). Backed by agent goal-state inference (arxiv 2606.16813v1). Triggers on acting under an assumed goal when the request admits more than one materially different reading.

2026-07-19

memory-hubness-gate

Use at write time to vector/embedding memory — Grove content-addressed insertion, chroma/pgvector upserts, memory-consolidation promoting session traces to MEMORY.md, or embedding externally-ingested content. Scores each candidate record against a fixed panel of sentinel queries and quarantines any record that would become the nearest neighbor of too many unrelated queries — a hub — whether from adversarial poisoning or accidental over-generality. This is the memory-record-side sibling of skill-injection-guardian (file-side) and the write-side complement of memory-use-warrant (read-side). Quarantine, never silently drop; a human reviews. Backed by the admission-time hubness gate (arxiv 2606.19692v1). Triggers on inserting into vector memory, consolidating memory, and embedding stranger content.

2026-07-19

memory-use-warrant

Run this appropriateness check the moment you are about to integrate a retrieved long-term memory — a Grove content-addressed hit, a chroma/pgvector neighbour, a memory-consolidation digest, or a MEMORY.md line — into a response, especially anything touching private origins, Fox Companies IP, credentials, or Center Camp / consent-governed content. It answers a question intent-router never asks: not WHAT to fetch or HOW, but WHETHER a correctly-retrieved item should reach output. Relevance is not appropriateness — a perfect similarity match can still be a boundary violation. Default is FAIL-CLOSED: if in-context authorization is uncertain, the memory may inform behaviour but must not be surfaced. Backed by RBI-Eval (arxiv 2606.06055v1). Triggers on surfacing recalled sensitive memory into a response.

2026-07-19

Tout voir dans ce dépôt

GitOps Patterns

Best practices for operating infrastructure and applications through Git as the single source of truth. Covers ArgoCD, Flux, Argo Rollouts, environment promotion, secret management, and progressive delivery.

GitOps Principles

GitOps extends Infrastructure as Code by adding a reconciliation loop that continuously ensures the live system matches the declared state in Git.

Principle

Description

Implementation

Declarative

Entire system described declaratively

Kubernetes manifests, Helm charts, Kustomize overlays

Versioned and immutable

Desired state stored in Git

Git commits as audit trail, tags for releases

Pulled automatically

Software agents pull desired state

ArgoCD, Flux controllers watch Git repos

Continuously reconciled

Agents correct drift automatically

Reconciliation loop detects and fixes divergence

GitOps vs Traditional CI/CD

GitOps

Traditional CI/CD

Deployment trigger

Git commit (pull-based)

Pipeline step (push-based)

Source of truth

Git repository

Pipeline state / manual

Drift handling

Auto-corrected

Undetected until next deploy

Rollback method

git revert

Re-run pipeline with old version

Audit trail

Git log

Pipeline logs (often ephemeral)

Credential exposure

Cluster-only (no CI secrets)

CI system has deploy credentials

Repository Structure

Separate application source code from deployment manifests. This is the most critical architectural decision in GitOps.

# Deployment repo (gitops-deploy) -- separate from application source gitops-deploy/ apps/ backend/ base/ deployment.yaml service.yaml kustomization.yaml overlays/ dev/ kustomization.yaml # image: backend:dev-abc1234 staging/ kustomization.yaml # image: backend:staging-def5678 prod/ kustomization.yaml # image: backend:v1.2.3 patches/ replicas.yaml hpa.yaml frontend/ base/ overlays/ infrastructure/ cert-manager/ ingress-nginx/ monitoring/ clusters/ dev/ kustomization.yaml # References apps/*/overlays/dev staging/ kustomization.yaml prod/ kustomization.yaml

GitOps Patterns

GitOps Principles

GitOps extends Infrastructure as Code by adding a reconciliation loop that continuously ensures the live system matches the declared state in Git.

Principle

Description

Implementation

Declarative

Entire system described declaratively

Kubernetes manifests, Helm charts, Kustomize overlays

Versioned and immutable

Desired state stored in Git

Git commits as audit trail, tags for releases

Pulled automatically

Software agents pull desired state

ArgoCD, Flux controllers watch Git repos

Continuously reconciled

Agents correct drift automatically

Reconciliation loop detects and fixes divergence

GitOps vs Traditional CI/CD

GitOps

Traditional CI/CD

Deployment trigger

Git commit (pull-based)

Pipeline step (push-based)

Source of truth

Git repository

Pipeline state / manual

Drift handling

Auto-corrected

Undetected until next deploy

Rollback method

git revert

Re-run pipeline with old version

Audit trail

Git log

Pipeline logs (often ephemeral)

Credential exposure

Cluster-only (no CI secrets)

CI system has deploy credentials

Repository Structure

Separate application source code from deployment manifests. This is the most critical architectural decision in GitOps.

apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: backend spec: replicas: 10 selector: matchLabels: app: backend template: metadata: labels: app: backend spec: containers: - name: backend image: ghcr.io/myorg/backend:v1.2.3 ports: - containerPort: 8080 resources: requests: { cpu: 100m, memory: 128Mi } limits: { cpu: 500m, memory: 512Mi } strategy: canary: canaryService: backend-canary stableService: backend-stable trafficRouting: istio: virtualServices: - name: backend-vsvc routes: [primary] steps: - setWeight: 5 - pause: { duration: 2m } - analysis: templates: - templateName: success-rate - setWeight: 25 - pause: { duration: 5m } - analysis: templates: - templateName: success-rate - setWeight: 50 - pause: { duration: 5m } - setWeight: 100 --- # AnalysisTemplate -- automated success criteria apiVersion: argoproj.io/v1alpha1 kind: AnalysisTemplate metadata: name: success-rate spec: args: - name: service-name metrics: - name: success-rate interval: 30s count: 5 successCondition: result[0] >= 0.95 failureLimit: 3 provider: prometheus: address: http://prometheus.monitoring:9090 query: | sum(rate(http_requests_total{service="{{args.service-name}}",status=~"2.."}[2m])) / sum(rate(http_requests_total{service="{{args.service-name}}"}[2m])) - name: p99-latency interval: 30s count: 5 successCondition: result[0] <= 500 failureLimit: 3 provider: prometheus: address: http://prometheus.monitoring:9090 query: | histogram_quantile(0.99, sum(rate(http_request_duration_ms_bucket{service="{{args.service-name}}"}[2m])) by (le) )

name	gitops-patterns
description	Provides GitOps best practices for ArgoCD, Flux, Argo Rollouts, and progressive delivery strategies. Use when setting up GitOps workflows, configuring continuous delivery, managing Kubernetes deployments declaratively, or when user mentions 'gitops', 'argocd', 'flux', 'progressive delivery', 'reconciliation', 'argo rollouts', 'canary', 'sealed secrets'.
type	skill
category	patterns
status	stable
origin	tibsfox
modified	false
first_seen	"2026-02-07T00:00:00.000Z"
first_path	examples/gitops-patterns/SKILL.md
superseded_by	null

name	gitops-patterns
description	Provides GitOps best practices for ArgoCD, Flux, Argo Rollouts, and progressive delivery strategies. Use when setting up GitOps workflows, configuring continuous delivery, managing Kubernetes deployments declaratively, or when user mentions 'gitops', 'argocd', 'flux', 'progressive delivery', 'reconciliation', 'argo rollouts', 'canary', 'sealed secrets'.
type	skill
category	patterns
status	stable
origin	tibsfox
modified	false
first_seen	"2026-02-07T00:00:00.000Z"
first_path	examples/gitops-patterns/SKILL.md
superseded_by	null

Structure Pattern	When to Use	Trade-offs
Monorepo (app + deploy)	Small teams, single app	Simple but couples build and deploy
Separate repos	Multiple teams, compliance needs	Clean separation, more repos to manage
Branch-per-env	Simple promotion model	Risk of branch divergence, merge conflicts
Directory-per-env	Kustomize overlays	Recommended: explicit, reviewable, no branch drift

Setting	ArgoCD	Flux
Poll interval	3m default	`spec.interval` per resource
Webhook support	Yes (GitHub, GitLab)	Yes (Receiver CRD)
Self-heal	`selfHeal: true`	`spec.force: true`
Prune removed resources	`prune: true`	`spec.prune: true`
Retry on failure	`retry.limit` with backoff	`retryInterval`

Strategy	Mechanism	Pros	Cons
PR-based promotion	CI opens PR to update image tag	Full review, audit trail	Manual merge step
Automated promotion	Flux image automation or CI script	Fast, no manual gates	Needs strong automated tests
Git tag promotion	Tag commit for promotion	Clear versioning	Complex tag management
Branch promotion	Merge dev -> staging -> prod	Familiar Git workflow	Branch drift, merge conflicts

gitops-patterns

Options d'installation

Vérifiez les fichiers source

GitOps Patterns

GitOps Principles

Repository Structure

GitOps Patterns

GitOps Principles

Repository Structure

ArgoCD Application Manifest

ArgoCD ApplicationSet for Multi-Environment

Flux Kustomization

Progressive Delivery with Argo Rollouts

Reconciliation Loop

Environment Promotion Strategies

PR-Based Promotion Pipeline

Secret Management in GitOps

Sealed Secrets

External Secrets Operator

SOPS with Flux Decryption

Anti-Patterns

GitOps Readiness Checklist

Solution	Encryption	Where Decrypted	External Deps	Complexity
Sealed Secrets	Asymmetric (cluster key)	In-cluster controller	None	Low
SOPS + age/KMS	Symmetric or KMS	CI or GitOps agent	KMS optional	Medium
External Secrets Operator	None (fetched at runtime)	In-cluster controller	Vault, AWS SM	Medium
Vault CSI Provider	None (injected at runtime)	Sidecar / CSI driver	HashiCorp Vault	High

Anti-Pattern	Problem	Fix
Storing plain-text secrets in Git	Credentials exposed in repo history forever	Use Sealed Secrets, SOPS, or External Secrets Operator
Push-based deploys alongside GitOps	CI `kubectl apply` bypasses reconciliation	Remove all `kubectl apply` from CI; only update Git
Single repo for app code and manifests	Every code commit triggers deploy; noisy history	Separate application and deployment repositories
Branch-per-environment	Branches diverge, merge conflicts, unclear state	Use directory-per-environment with Kustomize overlays
Disabling self-heal / auto-prune	Manual changes accumulate, cluster drifts from Git	Enable `selfHeal: true` and `prune: true`
No health checks in sync policy	Sync marked complete before app is actually ready	Add health checks for Deployments, StatefulSets, Jobs
Manual `kubectl` in GitOps clusters	Reverted on next reconciliation or causes drift	All changes through Git PRs; restrict kubectl to read-only
Deploying directly to prod	No validation in lower environments	Require promotion path: dev -> staging -> prod
No RBAC on GitOps tool	Any developer can sync any app to any namespace	Use ArgoCD AppProjects or Flux multi-tenancy
Image tag `latest` in manifests	Non-deterministic deploys, no rollback possible	Use immutable tags (SHA, semver, build ID)
No notification on sync failure	Failed deployments go unnoticed for hours	Configure alerts to Slack, PagerDuty, or email
Reconciliation interval too long	Drift persists, delayed deployments	Set interval to 1-5 minutes; use webhooks for instant sync

gitops-patterns

Informations de source

Options d'installation

Vérifiez les fichiers source

Plus depuis ce dépôt

Plus depuis ce dépôt

GitOps Patterns

GitOps Principles

Repository Structure

GitOps Patterns

GitOps Principles

Repository Structure

ArgoCD Application Manifest

ArgoCD ApplicationSet for Multi-Environment

Flux Kustomization

Progressive Delivery with Argo Rollouts

Reconciliation Loop

Environment Promotion Strategies

PR-Based Promotion Pipeline

Secret Management in GitOps

Sealed Secrets

External Secrets Operator

SOPS with Flux Decryption

Anti-Patterns

GitOps Readiness Checklist