confighub

Operate the Cost Management App app through its generated CLI and browser surface. Use for "Turn fleet cost findings into governed recommendations, approvals, and receipts.", Variant review, proof gaps, preview, approval scope, and receipt checks. Read-only first; live mutation requires the app commit command to prove real ConfigHub bindings.

Operate the Add-on Manager app through its generated CLI and browser surface. Use for "Install, upgrade, review, and prove platform add-ons through governed ConfigHub delivery paths.", Variant review, proof gaps, preview, approval scope, and receipt checks. Read-only first; live mutation requires the app commit command to prove real ConfigHub bindings.

Inventory and report Kubernetes autoscaling stored in ConfigHub across a fleet with the cub-autoscale CLI — HorizontalPodAutoscalers and KEDA ScaledObjects: each one's scale target, min/max replicas, and whether it is pinned (min == max). Use for "what autoscalers do we have?", "list our HPAs / ScaledObjects", "which workloads are autoscaled?", "per-cluster autoscaler counts", "is autoscaler X pinned?". Not for autoscaling findings/anti-patterns (use autoscale-findings), edits or HPA→KEDA conversion (use autoscale-edit), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

Set Kubernetes autoscaling as config-as-data with the cub-autoscale CLI — edit a HorizontalPodAutoscaler's min/max replicas and cpu/memory targets, convert an HPA to a KEDA ScaledObject, apply reusable autoscaling profiles to one Unit or across a whole selector, and promote changes downstream. Use for "raise the HPA max to 20", "set cpu target to 60%", "convert this HPA to KEDA", "make every prod HPA scale out earlier", "apply the hpa-range profile", "roll the autoscaling change downstream". Dry-run by default; requires --commit --change-desc. Not for read-only checks (use autoscale-audit / autoscale-findings) or enforcement Triggers (use autoscale-guardrails).

Produce severity-ranked Kubernetes autoscaling findings across a ConfigHub fleet with the cub-autoscale CLI. Flags autoscalers that are pinned (min == max, can't scale), workloads with no HPA/ScaledObject, and the cross-resource case where a PodDisruptionBudget's minAvailable blocks all voluntary eviction at the autoscaler's minReplicas. Use for "what autoscaling problems do we have?", "which HPAs can't scale?", "which workloads lack an autoscaler?", "is any PDB blocking scale-down?". Not for the raw autoscaler inventory (use autoscale-audit), fixing autoscaling (use autoscale-edit), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

Install and inspect the autoscaling enforcement pack with the cub-autoscale CLI — an autoscale-policy Space with two Warn=true Triggers: a vet-cel rule that flags any HPA/ScaledObject that is pinned (min == max), and a vet-schemas rule that schema-validates every mutation (the post-convert check for convert-keda output, since keda.sh is in the schema catalog) — wired to in-scope Spaces via a shared Trigger Filter. guardrails install (dry-run by default) and status (Units with ApplyWarnings/Gates). Use for "enforce that no HPA is pinned", "make sure converted ScaledObjects pass schema validation", "which autoscalers are flagged?". Not for read-only findings (use autoscale-findings) or fixing autoscaling (use autoscale-edit).

Inventory the observability posture of Kubernetes workloads stored in ConfigHub across a fleet with the cub-observability CLI — ServiceMonitors, Services (and which expose metrics), and telemetry-sidecar presence. Use for "what ServiceMonitors / Services do we have?", "which Services expose metrics?", "which workloads have an otel sidecar?", "per-cluster observability counts". Not for ServiceMonitor coverage gaps (use observability-findings), fixes (use observability-instrument / observability-guardrails), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

Produce severity-ranked observability findings across a ConfigHub fleet with the cub-observability CLI — a metrics-exposing Service with no ServiceMonitor selecting it (the cross-Unit coverage join), and a dangling ServiceMonitor that selects nothing. Use for "what observability gaps do we have?", "which metrics Services are not scraped?", "any ServiceMonitors selecting nothing?", "observability findings for the checkout component". Not for the raw coverage report (use observability-audit), fixes (use observability-instrument), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

Use when working in the cub-scout repo or when answering capability-assistant questions ("can cub-scout do X?", "should I use cub-scout or kubectl here?", "how does cub-scout differ from cub?"). This is the umbrella router — it points you at the verb-grouped scenario skills under `skills/scout-*/` and the workflow / observer / reference skills planned for batches 2–5. For a specific verb-group task (observe / diagnose / compare / attribute / adopt existing config / govern / integrate / verify) load the corresponding `scout-*` skill directly.

Use when the user wants to observe KRO-managed resources specifically — the controller-specific observer skill for kro (the Kubernetes Resource Orchestrator). Natural phrasing: "is this a kro instance?", "which ResourceGraphDefinition produced this?", "show me kro applyset writes", "what does `kro.run/applyset` mean?", "trace this resource back to the kro instance". kro is a Kubernetes-native resource orchestrator using applysets. Do NOT load for: generic ownership (use scout-observe), Crossplane (similar composition pattern but different — use observe-crossplane), authoring kro CRDs themselves.

Use when the user wants to observe Modelplane-managed resources specifically. Natural phrasing: "is this from Modelplane?", "which ModelDeployment produced this replica?", "show me Modelplane endpoints", "what does modelplane.ai/deployment mean?", "is this Modelplane or generic Crossplane?". Do NOT load for: generic ownership (use scout-observe), Crossplane-only resources (use observe-crossplane), or authoring Modelplane APIs.

Use when the user wants to observe NATIVE Kubernetes resources — anything cub-scout's ownership detector couldn't classify as Argo / Flux / Sveltos / Modelplane / Helm / Crossplane / kro / ConfigHub / Terraform / Custom. Natural phrasing: "why is this resource unowned?", "show me orphan workloads", "this isn't managed by anything — what does that mean?", "what is OwnerReferences-only ownership?", "is this a kubectl-applied resource without a controller?", "show me native K8s resources in this cluster". Load whenever intent is unowned / native / orphan / no-controller / OwnerReferences-only / direct-apply. Do NOT load for: any specific controller (use the matching observe-* skill), generic ownership when the controller IS known (use scout-observe), or apply/edit/delete operations (cub-scout never mutates).

Use when the user wants to observe Sveltos-managed resources specifically. Natural phrasing: "is this from Sveltos?", "which ClusterProfile deployed this?", "what ConfigMap or Secret supplied this Sveltos policy?", "show me Sveltos Profile ownership", "what does projectsveltos.io/owner-kind mean?". Do NOT load for: generic ownership (use scout-observe), Sveltos authoring/mutation, or Sveltos notifications unless the task is read-only observation.

Use when Pilot is CLASSIFYING DRIFT and DECIDING WHAT TO DO ABOUT IT after a divergence between intended state and live state is detected. Natural phrasings: "Pilot, classify this drift", "is this manual edit or controller drift?", "should Pilot revert this patch?", "quarantine or accept-as-canonical?", "what does cub-scout say about who touched this field?", "render a drift verdict for the audit". Pilot consumes cub-scout's attribution evidence (`cause: manual-edit` / `controller-drift` / `unknown` + `managerHint` + `gitSource` + `bindingSource`) and decides revert / quarantine / accept-as-canonical / ASK-human. The decision shape matches the attribution layer's evidence shape — cub-scout produces deterministic classification; Pilot picks the policy action. Do NOT load for: a single-resource pre-deploy gate (use pilot-cd-gate), a real-time event response (use pilot-watch-alert-response), a fleet roll-up (use pilot-fleet-conformance), or any mutating action. Pilot mutates via `cub` / Argo / kubectl — never vi

Use when the user wants to understand WHERE a specific field value came from on a running Kubernetes resource — which controller, which git file, or which ConfigHub Link binding produced it. Natural phrasing: "why is replicas: 1 in prod?", "did someone kubectl edit this?", "is Argo still reconciling or has the GitOps loop been bypassed?", "what git commit set this image tag?", "which upstream unit feeds this field?", "where does this value come from?", "show me the provenance of this Deployment", "is this controller-drift or manual-edit?". Load whenever attribution / provenance / lineage / git-blame-for-runtime / who-changed-this intent appears, especially on `compare` and `explain` output. Do NOT load for: pure ownership classification at the resource level (use scout-observe — that gives Owner=Argo/Flux/etc., not per-field), source-truth strategy verdicts (use scout-compare), or live-cluster mutation (cub-scout cannot mutate — that is `cub` or `kubectl` with user driving).

Use when the user is MIGRATING from ad-hoc `kubectl apply` toward GitOps (Argo / Flux / ConfigHub) — and needs to find the manual edits, decide what to do with each (revert / port to git / accept as canonical), and plan the transition. Natural phrasing: "find all the manual edits in this cluster", "we have years of kubectl-apply, help us move to GitOps", "which resources have been hand-edited?", "audit drift caused by humans not controllers", "port my cluster state to git", "show me everything kubectl-* has touched". Composes attribution layer (`cause: manual-edit`) + `map orphans` (resources without a controller owner) + `scan` (risk classification) + `snapshot` / `import --git-path` preview once a repo skeleton exists. Read-only throughout — the migration itself is user-driven. Do NOT load for: real-time triage (use triage-unhealthy-workload), single-resource drift question (use investigate-drift), a fleet conformance audit (use audit-fleet-conformance), or any mutating action.

Change data inside an existing ConfigHub Unit, preferring a function over a hand-edit. Use for "update the image", "bump the replicas", "change the env var", "set the annotation", "apply defaults", "edit this unit", or a bulk edit across many units. Not for creating a brand-new Unit (use confighub-core).

Make validation enforced or advisory, via the platform-Space + Filter + TriggerFilterID pattern — Triggers that attach a blocking ApplyGate, or a non-blocking ApplyWarning (--warn), when validation fails. Use for "block bad config from being deployed", "wire up schema validation", "enforce a policy", "warn but don't block", "why is this Unit blocked?", "what warnings does this Unit have?". Not for one-off validator runs (use cub-mutate).

Find, count, inspect, or audit Kubernetes workloads and config stored in ConfigHub — fleet sweeps and single-workload lookups. Use for "where is checkout deployed?", "which Deployments run over 5 replicas?", "find workloads missing resource limits", "what image tag is our worker on?". Not for live cluster state (use kubectl).

Turn an app config file (.env, .properties, .yaml, .json, .toml, .ini, text) into a versioned AppConfig Unit and render it to a Kubernetes ConfigMap via an Upsert link + render-configmap Invocation (no worker/Target). For: use my .env with ConfigHub, ConfigMap like configMapGenerator, envFrom injection. Not for raw ConfigMap authoring (use confighub-core).

Foundational ConfigHub skill — load first for orientation and doctrine. Covers core vocabulary (Unit, Space, Target, Worker, Trigger, Filter, Link), Space layout per environment/region, config-as-data authoring (literal YAML, no Helm/Kustomize templates, one resource per Unit), delete/destroy gates, and routing a task to the right skill. Route obvious tasks directly (image bump -> cub-mutate; find Units -> cub-query).

Apply (deploy) a ConfigHub Unit or group of Units to their Target via cub unit apply, respecting ApplyGates. Use for "apply this", "deploy this to staging", "push the change to the cluster", "roll out the fix", "apply everything unapplied", "apply the ChangeSet", "dry-run what would change". Not for rollback (use rollback-revision).

Onboard existing Kubernetes config into ConfigHub as Units, from a Helm chart ("cub helm install", "upgrade the chart without losing my edits") or a Kustomize overlay ("import my base + overlays", "kustomize build into Units"). Not for authoring new YAML from scratch (use kubernetes-resources).

Orchestrate the ConfigHub side of a live production incident — triage, decide stabilize-and-mitigate vs rollback vs drift reconciliation, route to the right mutation skill. Use for "we have an outage", "prod is crashing", "mitigate or roll back?", "post-incident cleanup". Not for planned releases (use promote-release).