confighub-skills

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).

Author a specific Kubernetes resource type as literal YAML in a ConfigHub Unit with best-practice defaults. Use for "create a StatefulSet", "add an Ingress", "set up NetworkPolicy", "I need a CronJob", "add RBAC for my app", "set up autoscaling", "add a PDB". Not for AppConfig-based ConfigMaps (use app-config).

Promote a release to the next environment or across the fleet, and manage variant spaces — cub variant create / promote to reconcile a variant with its upstream, or a ChangeSet-wrapped bulk upgrade for partial / cross-space scopes. Phrases: promote to staging, roll forward to prod, which Units are behind upstream, push the base to every downstream. Not for rollback (use rollback-revision).

Roll back a change by moving a Unit head (or a set of Unit heads) to a prior revision via cub unit update --restore, then hand off to cub-apply. Use for "roll back this change", "revert the last release", "undo the ChangeSet", "restore to the last applied revision". Not for a forward one-field fix where a new cub-mutate is clearer.

Create or refresh a skill-examples Space with seed Units covering common Kubernetes resource types — a playground to exercise the other skills against. Use for "set up the skill-examples space", "bootstrap the examples", "give me a Unit to tinker with", "reset the examples". Not for creating real application Spaces (use confighub-core).

Bind Units to a delivery Target — ProviderType OCI (publish Unit data to ConfigHub's OCI registry for ArgoCD/Flux to pull) or ConfigHub (apply ConfigHub/YAML config). Both are server workers, no external worker to run. Phrases: set up a target, publish to OCI, attach units to a target. Creates the Target + server worker and attaches Units via cub unit set-target; stops before apply.

Post-apply verification and close-out. Confirm ConfigHub published/applied the Unit (Completed vs Failed), then confirm ArgoCD/Flux pulled the OCI artifact and the cluster converged (read-only argocd/flux/kubectl). Use right after cub-apply, or for: did it actually deploy, is it live, did argo pick it up, close this release out. Not for authoring (use cub-mutate).

Set up a ConfigHub worker. Default: a server worker (cub worker create --is-server-worker) — no process to run, and all that OCI / ConfigHub Targets need. Run an external worker (cub worker run / install) only to host custom worker functions. Phrases: set up a worker, do I need to run a worker, add custom functions. Not for creating Targets (use target-bind).