confighub-skills

kubernetes-resources

Use when the user wants to create or modify a specific Kubernetes resource type in ConfigHub — phrases like "create a StatefulSet", "add an Ingress", "set up NetworkPolicy", "I need a CronJob", "add RBAC for my app", "set up autoscaling", "create a DaemonSet", "expose my service externally", "add a PDB", "create a Job for data migration", "I need a headless Service", "set up persistent storage". Walks the user through authoring the resource as literal YAML in a ConfigHub Unit, applying best-practice defaults via functions, and wiring it into the Space. Pulls live examples from the `skill-examples` Space when available (seeded by `skill-examples-bootstrap`); falls back to `references/yaml-patterns.md`. Do not load for: AppConfig-based ConfigMaps (use `app-config`), Helm chart imports (use `import-from-helm`), raw config-as-data doctrine questions without a specific resource type (use `config-as-data`).

import-from-argocd

Use when the user has ArgoCD running in a cluster and wants to bring their existing `Application` resources under ConfigHub management — phrases like "I already use ArgoCD, how do I add ConfigHub?", "import my Argo apps into ConfigHub", "we have 50 ArgoCD Applications, can cub discover them?", "gitops import", "cub gitops discover", "put ConfigHub in front of ArgoCD", "keep Argo but add ConfigHub validation/approval". Runs `cub gitops discover` + `cub gitops import` against a cluster Target, produces dry/wet Unit pairs linked via MergeUnits, sets wet-Unit ProviderType to `ArgoCDOCI` so that applying a wet Unit re-deploys through ConfigHub's OCI registry via Argo, and disables auto-sync on the original Applications. Do not load for Flux (use `import-from-flux`), for direct Helm chart install without Argo (use `import-from-helm`), for plain live-resource adoption without a GitOps tool (use `import-from-cluster`), or for installing the Worker itself (use `worker-bootstrap` first — this skill assumes the Worker is already running with the three bridges).

import-unit-granularity

Use when the user is deciding how to slice Kubernetes YAML into ConfigHub Units — phrases like "one Unit or many?", "how should I split these resources?", "should Deployment and Service be one Unit?", "where do CRDs go?", "Unit per resource or per bundle?", "should my namespace and its RBAC be together?", "per-app or per-namespace?". Applies a short set of rules (CRDs separate; rendered-from-generator stays bundled; otherwise split by ownership / references / lifecycle / blast radius) and routes the user to the right import skill with a concrete Unit-slug plan. Do not load for authoring new YAML (use `config-as-data`), for executing an import the user has already scoped (use the matching `import-from-*` skill), or when the split is already forced by the tool in use (`cub helm install` and `cub gitops import` split CRDs automatically — just run them).

import-from-kustomize

Use when the user wants to bring a Kustomize overlay or base into ConfigHub as Units — phrases like "I have a kustomization.yaml, how do I use it with ConfigHub?", "import my Kustomize overlays", "migrate from Kustomize to ConfigHub", "render this overlay into ConfigHub", "kustomize build into Units", or "I have a base + overlays directory structure". Runs `kustomize build` locally, splits the result into one or more ConfigHub Units via `cub unit create`, and hands off ongoing customization to `cub-mutate`. Do not load for Flux `Kustomization` CRDs (use `import-from-flux` — that's the renderer-bridge pipeline), for Helm charts (use `import-from-helm`), for adopting live cluster resources (use `import-from-cluster`), or for authoring raw YAML from scratch (use `config-as-data`).

verify-apply

Use right after cub-apply returns, or any time the user asks "did it actually deploy?", "is it live?", "is it still applying?", "did argo pick it up?", "are ConfigHub and the cluster in sync?", "prove this converged", "close this release out", "show me what changed". Single skill covering the whole post-apply arc: read Unit status + latest event to classify the apply (Progressing / Completed / Failed / Aborted), drill into `cub unit-event get` for per-resource sync/ready status and the Message field when something broke, cross-check the controller (Argo/Flux) and cluster (kubectl) for runtime failures (ImagePullBackOff, CrashLoopBackOff, schema errors), optionally produce a three-way ConfigHub ↔ controller ↔ cluster agreement table, and on success surface the Revision history with its --change-desc + GUI review links. Do not load for pure ConfigHub-internal query (use cub-query), for reconciling known drift (use drift-reconcile), or when the apply has not actually run yet (use cub-apply).

import-from-helm

Use when the user wants to bring a Helm chart under ConfigHub management — phrases like "install cert-manager from Helm", "I have a Helm chart, how do I use it with ConfigHub?", "render this chart into ConfigHub", "cub helm install", "upgrade to the new chart version", "how do I customize a chart without losing changes on upgrade?", or "deploy nginx/prometheus/traefik via Helm through ConfigHub". Runs `cub helm install` / `cub helm upgrade` / `cub helm template`, follows the clone-based customization pattern so upgrades preserve user edits, splits CRDs into their own Unit, and hands off applying to `cub-apply`. Do not load for ArgoCD Application or Flux HelmRelease discovery (use `import-from-argocd` / `import-from-flux` — those insert ConfigHub into an existing GitOps pipeline), for adopting already-deployed live resources (use `import-from-cluster`), or for authoring raw Kubernetes YAML with no chart (use `config-as-data`).

import-from-flux

Use when the user has Flux running in a cluster and wants to bring their `HelmRelease` and `Kustomization` resources under ConfigHub management — phrases like "I already use Flux, how do I add ConfigHub?", "import my Flux HelmReleases / Kustomizations into ConfigHub", "gitops import with Flux", "we have 30 HelmReleases", "put ConfigHub in front of Flux", "keep Flux but add ConfigHub validation/approval". Runs `cub gitops discover` + `cub gitops import` against a cluster Target, produces dry/wet Unit pairs linked via MergeUnits, sets wet-Unit ProviderType to `FluxOCI` so that applying a wet Unit re-deploys through ConfigHub's OCI registry via Flux, and suspends the imported HelmReleases / Kustomizations. Do not load for ArgoCD (use `import-from-argocd`), for direct Helm chart install without Flux (use `import-from-helm`), for plain live-resource adoption without a GitOps tool (use `import-from-cluster`), or for installing the Worker itself (use `worker-bootstrap` first — this skill assumes the Worker is already running with the three bridges).

target-bind

Use when the user wants to bind a Unit (or many Units) to a destination — a specific Kubernetes cluster+namespace, an ArgoCD Application, a Flux Kustomization, an OCI registry, a Tofu workspace. Phrases like "set up a target", "point this unit at my cluster", "bind these units to prod", "hook up Argo/Flux", "change the namespace this deploys to", "promote these to a different target". Creates or updates a Target with the right provider/toolchain and parameter JSON, attaches Units via cub unit set-target (or --where for bulk), and stops without applying — apply is cub-apply's job. Do not load for installing a worker (use worker-bootstrap first — Targets reference Workers), for running apply (use cub-apply), or for authoring the Unit's YAML (use config-as-data).

app-config

Use when the user wants to manage application configuration files (properties, env, toml, ini, yaml, json, text) and deploy them as Kubernetes ConfigMaps — phrases like "I have a .env / .properties / application.yaml file, how do I use it with ConfigHub?", "generate a ConfigMap like kustomize configMapGenerator", "like kubectl create configmap but versioned", "inject env vars via envFrom", "ConfigMap with content hash for rolling restart", "mutable vs immutable ConfigMap", "validate my application config with a schema", "propagate config changes to the workload without kubectl edit". Authors an AppConfig Unit in the right toolchain, sets up the ConfigMapRenderer Target, links the rendered ConfigMap to the workload via Needs/Provides, and picks immutable (hashed name, history) or mutable (stable name + hash annotation) mode. Do not load for authoring a Kubernetes `ConfigMap` resource directly in a `Kubernetes/YAML` Unit (use `config-as-data` + `cub-mutate`), for Secrets (separate SecretStore story — see `references/yaml-patterns.md`), or for migrating Helm values files (use `import-from-helm` — charts already render their own ConfigMaps).

promote-release

Use when the user wants to promote a release from one env-Space to the next, or push a base revision to every downstream across the fleet — phrases like "promote to staging", "roll forward to prod", "push this release to the next environment", "upgrade the downstream Units to match upstream", "is staging ready to roll forward?", "what do I need to check before promoting to prod?", "preflight before pushing the release to prod", "which Units are behind their upstream?". One skill for the whole promotion arc: runs the preflight checks (source converged, destination in scope, diffs sane, policy + approval ready, upstream linkage matches intent) to produce a go / no-go and a concrete scope; on go, wraps the promotion in a ChangeSet, bulk-runs `cub unit update --patch --upgrade --where ...`, closes the ChangeSet, and hands off to `cub-apply` for the rollout. Do not load for rollback of a prior promotion (use `rollback-revision` + `references/changesets.md`), cluster-ConfigHub drift (use `drift-reconcile`), post-promotion verification (use `verify-apply`), or single-Unit in-place mutations (use `cub-mutate`).

skill-examples-bootstrap

Use when the user wants a working ConfigHub playground to exercise the other skills against — phrases like "set up the skill-examples space", "bootstrap the examples", "give me a Unit to tinker with", "walk me through with a real example", "I'm new to ConfigHub, show me something I can poke at", or "reset the examples". Creates (or refreshes) a `skill-examples` Space with seed Units covering common Kubernetes resource types — Deployment, StatefulSet, DaemonSet, Job, CronJob, Ingress, NetworkPolicy, RBAC, HPA, PDB — and applies the canonical defaults-function chain so the end state demonstrates config-as-data with provenance intact. Other skills (like `kubernetes-resources`) pull from these live examples in preference to hardcoded YAML. Idempotent: re-running is safe. Do not load for creating real application Spaces (use config-as-data + space setup directly) or for bootstrapping triggers/policy (use triggers-and-applygates).

drift-reconcile

Use when ConfigHub's Unit Data and the cluster's live state for that Unit have diverged — phrases like "reconcile drift", "the cluster changed out of band", "someone kubectl edit'd this", "ConfigHub and the cluster disagree", "accept the live changes", "overwrite the cluster with ConfigHub", "refresh from live", "who owns this drift?", "we have drift on app-a in prod". Runs `cub unit refresh` to pull current live state, `cub unit diff` against Data, walks the decide-who-wins decision (ConfigHub wins → re-apply; cluster wins → absorb; merge → selective reconcile), and executes the chosen path. Do not load for revision history rewind (use `rollback-revision`), for post-apply verification / three-way agreement checks (use `verify-apply`), for the first-time apply of a newly-bound Unit (use `cub-apply`), or for importing wholesale live resources into a brand-new Unit (use `import-from-cluster`).

triggers-and-applygates

Use when the user wants validation to be enforced (not just advisory) on ConfigHub Units, is setting up a new Space and wants policy to apply automatically, asks about ApplyGates, says "block bad config from being deployed", "wire up schema validation", "enforce a policy", "require approval", or needs to diagnose why a Unit is blocked from applying. This skill installs the platform-Space + Filter + TriggerFilterID pattern — centralized Triggers that run on every Mutation and attach ApplyGates when validation fails. Do not load for: running validators one-off without installing them (use cub-mutate with vet-* functions instead), or for authoring the YAML itself.

import-from-cluster

Use when the user has live Kubernetes resources already running in a cluster — applied by `kubectl apply`, installed via a different workflow, or inherited from a previous operator — and wants to bring them under ConfigHub management without a GitOps tool or a Helm chart in hand. Phrases like "adopt these existing resources into ConfigHub", "I have stuff in the cluster, how do I get it into cub?", "reverse engineer my namespace into Units", "import from the cluster", "cub unit import", "we kubectl-apply'd everything and want to migrate", or "bring the running state into ConfigHub". Creates Units pre-bound to a cluster Target, runs `cub unit import` with `--where-resource` filters to pull live manifests, then hands off to `config-as-data` doctrine for ongoing management. Do not load for Helm-installed charts (use `import-from-helm`), ArgoCD Applications (use `import-from-argocd`), Flux HelmReleases / Kustomizations (use `import-from-flux`), or new YAML being authored from scratch (use `config-as-data`).

confighub-core

Orientation skill — load when the user is new to ConfigHub, asks "what is a Unit / Space / Target / Worker / Trigger / Filter / Link", needs to understand how entities relate, wants a quick tour before diving into specific operations, or asks "how do I do X in ConfigHub" without enough context to route yet. Also covers Delete Gates and Destroy Gates — phrases like "protect this Space from accidental deletion", "stop anyone from destroying the prod Unit", "add a delete gate", "why can't I delete this?", "how do I lock down critical infra?". Explains the core vocabulary, the Read vs Write tool boundary, the change-description + -o mutations conventions, gate semantics, and routes to the right dedicated skill for each kind of task. Do not load when the user's intent is already concrete enough to route (e.g., "add a trigger that blocks :latest" → triggers-and-applygates; "bump the image" → cub-mutate; "find Deployments using v1.2.3" → cub-query).

cub-query

Use when the user wants to find, count, inspect, read, or audit Kubernetes workloads and application configuration stored in ConfigHub — both fleet-wide sweeps and single-workload lookups. Natural phrasing is workload- or application-centric: "where is checkout v0.4.2 deployed?", "which Deployments run more than 5 replicas?", "find workloads missing resource requests or limits", "what image tag is our nonprod worker running?", "how many replicas does our frontend have in us-east?", "is our api up to date with the latest release?", "show me the YAML / env vars / annotations of our frontend". ConfigHub-native phrasing is equally in scope: "which Units ...", "what's in Space X", "Units with Label env=prod". Workload-in-environment phrasing like "frontend in us-east" maps to a Unit slug plus a Space slug or Space Label — see space-topology for the conventions. Load any time intent is find / list / show / which / where / how many / audit / inspect / read / what tag / is X up to date over ConfigHub-managed workloads — one workload or the whole fleet. Do not load for: mutating data (cub-mutate), authoring (config-as-data), designing the Space/Label taxonomy itself (space-topology), or live cluster state not in ConfigHub (kubectl).

space-topology

Use when the user is organizing Units, Targets, and Workers across environments or regions — phrases like "how should I structure my Spaces?", "where do dev/staging/prod go?", "multi-region layout", "one Space per environment?", "app-a-prod vs prod-app-a naming", "should these be labels or separate Spaces?", "how do I keep prod config separate from dev?", or "we're standing up a second cluster, what's the ConfigHub pattern?". Prescribes one Space per deployment boundary (environment × region × cluster), the `platform` Space for org-wide Triggers/Filters, and label/slug conventions that make cross-Space queries and cloning painless. Do not load for authoring a single Unit's YAML (use `config-as-data`), for binding a Unit to a Target (use `target-bind`), or for setting up validation Triggers (use `triggers-and-applygates`).

cub-mutate

Use whenever the user wants to change data inside a ConfigHub Unit — update an image, adjust replicas, set environment variables, add labels/annotations, change a resource field, apply defaults, or make a bulk edit across many units. This skill enforces the "prefer a function over a hand-edit" rule, composes a proper change description that captures the user's prompt and clarifications, and chooses between `cub function set` (single function, targeted or bulk) and `cub unit update` (whole-unit replacement or restore). Load proactively any time the user says "update the image", "bump the replicas", "change the env var", "set the annotation", "apply defaults", "edit this unit", or any natural request that will end in a write to ConfigHub. Do not load for: creating a brand-new Unit (use config-as-data), reading/inspecting config (use cub-query), or setting up validation (use triggers-and-applygates).

config-as-data

Use whenever the user is authoring or modifying Kubernetes configuration stored in ConfigHub, or is about to reach for Helm, Kustomize, Jsonnet, cdk8s, or a values file. This skill enforces the "configuration as data" doctrine — Units contain fully-materialized, literal YAML, mutated in place via cub functions or direct edits, never re-rendered from templates. Load this proactively any time the user says things like "add a chart", "values file", "overlay", "template this", "parameterize", "set up Helm for this", "make this reusable across envs", or starts generating K8s YAML that will be stored in ConfigHub. Do not load for: pure import-from-helm / import-from-kustomize flows (those have their own skills that handle one-shot render + store), or authoring config outside ConfigHub.

cub-apply

Use when the user wants to apply (deploy) a ConfigHub Unit or group of Units to their Target — phrases like "apply this", "deploy this to staging", "push the change to the cluster", "roll out the fix", "apply everything that's unapplied", "apply the ChangeSet", "dry-run what would change". Runs `cub unit apply` with the right scoping (single / list / --where / --filter / --revision ChangeSet:<slug>), respects ApplyGates (never bypasses), waits for completion, and hands off to verify-apply. Do not load for rollback (use rollback-revision — `cub unit apply --revision <N>` does NOT move head and is not a rollback), for authoring changes (use cub-mutate), for binding a destination (use target-bind), or for any post-apply verification / troubleshooting / close-out (use verify-apply).

incident-management

Use when the user is in the middle of a production incident and needs an orchestrated plan — phrases like "we have an outage", "prod is crashing", "page me through this", "what do I do first?", "mitigate or roll back?", "production is down since the last release", "something's broken in staging — help me triage", "we're on an incident call, walk me through the ConfigHub side", "post-incident cleanup". Triage the situation, decide between stabilize-and-mitigate vs head-moving rollback vs drift reconciliation, route to the right mutation skill with the scope and `--change-desc` composed, and drive the post-incident verification + close-out. Do not load for planned releases (use `promote-release`), for routine change management, or for single-Unit edits the user is confidently making on their own (use `cub-mutate`).

worker-bootstrap

Use when the user needs to install a ConfigHub bridge worker in a Kubernetes cluster so that Units can apply, refresh, or import against real infrastructure — phrases like "set up a worker", "install the ConfigHub worker", "connect ConfigHub to my cluster", "make ConfigHub able to deploy", "add an Argo renderer worker", "add a Flux renderer worker", "I need a worker for OCI publishing", or "the worker isn't running / is crashing". Creates the worker entity, generates the Kubernetes manifest with the right provider types, installs it (or exports it for review / storage as a ConfigHub Unit), verifies it's running, and stops before you try to deploy anything through a worker that isn't healthy. Do not load for creating Targets (use target-bind — Targets reference Workers but are a separate concern) or for day-2 application apply (use cub-apply once the worker is up).

rollback-revision

Use when the user wants to roll back a change by moving a Unit's head (or a set of Units' heads) to a prior revision — phrases like "roll back this change", "revert the last release", "undo the ChangeSet", "restore to the last applied revision", "back out yesterday's image bump", "put the head back where it was before this ChangeSet", "roll back the promotion". Always rolls back by moving head via `cub unit update --restore <target>` against one Unit or a Filter-scoped set (optionally tagged), then hands off to the `cub-apply` skill to push the restored state. Do not load for drift between ConfigHub and cluster (use `drift-reconcile`) or for rolling back a single-field change where a forward mutation via `cub-mutate` is clearer.