observe-flux

Diagnose Flux-managed Kubernetes resources by tracing ownership to Kustomizations or HelmReleases.

14|Updated Jan 17, 2026
One-click install
npx skills add https://github.com/confighub/cub-scout --skill observe-flux
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: observe-flux
Source: https://github.com/confighub/cub-scout/tree/main/skills/observe-flux
Command: npx skills add https://github.com/confighub/cub-scout --skill observe-flux

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It helps you determine whether a Kubernetes resource is managed by Flux and precisely explain where its values came from, why it’s unhealthy or drifting, and which Flux controller and source artifact are responsible.

Core Features & Use Cases

  • Flux ownership detection: Identifies Flux-managed resources using controller-specific label families for Kustomizations and HelmReleases.
  • Managed-field attribution: Explains which controller wrote observed fields by matching Flux’s exact metadata.managedFields.manager strings (kustomize-controller, helm-controller, source-controller).
  • Trace back to Flux source artifacts: Walks the chain from a workload to its owning Kustomization/HelmRelease, then to the underlying source (GitRepository, OCIRepository, HelmRepository, Bucket, HelmChart) via spec.sourceRef and source revision evidence.

Quick Start

Ask the skill to explain why a deployment is unhealthy and whether Flux is the real owner, including which Kustomization/HelmRelease and which source artifact produced it.

Frequently Asked Questions about observe-flux

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find which Flux Kustomization or HelmRelease owns a Kubernetes resource?▼

Flux ownership is detected by inspecting Kubernetes resources for controller-specific label families and matching exact `metadata.managedFields.manager` strings to kustomize-controller, helm-controller, or source-controller.

How does Flux trace a workload back to its source artifact?▼

Flux traces workloads back to source artifacts by walking the chain from the owning Kustomization or HelmRelease to the underlying GitRepository, OCIRepository, or HelmRepository via `spec.sourceRef` and source revision evidence.

Why is my Flux-managed Kubernetes resource unhealthy or drifting?▼

Flux-managed resources drift or become unhealthy due to reconcile failures or configuration mismatches, diagnosed through read-only inspection of Flux controller traces and source revision evidence.

Can I diagnose Kubernetes resources managed by Flux without modifying them?▼

Yes, Flux-managed Kubernetes resources are diagnosed using read-only inspection of objects, applying Flux-aware detection and controller trace logic to explain ownership and reconcile outcomes without applying changes.

What is the best way to identify which Flux controller wrote specific fields on a Kubernetes object?▼

The best way to attribute specific fields on a Kubernetes object is by matching `metadata.managedFields.manager` strings to kustomize-controller, helm-controller, or source-controller to pinpoint the writing controller accurately.

Does Flux ownership detection work with both HelmRelease and Kustomization controllers?▼

Yes, Flux ownership detection applies to both HelmRelease and Kustomization controllers by identifying resources through controller-specific label families and matching their respective managedFields manager strings.