Claude, Codex and Kubernetes · ConfigHub Workshop

1. Install the ConfigHub Workshop skill

Install it in the project where your agent is working. The open Agent Skills installer supports Codex, Claude Code, Cursor, and other coding agents.

npx skills add https://github.com/confighub/helm-expt/tree/main/skills/config-workshop

You can also read the skill first. It holds no credentials and applies nothing. Local Workshop checks do not upload configuration to ConfigHub. What your agent sends to its AI provider depends on that tool and its settings. The skill instructs it to redact Secrets, pin versions and digests, report skipped checks and preview changes.

Read the fuller prompt for a new project

The short prompt above is enough for most questions. This fuller version adds Catalog context and explains when ConfigHub Server is useful; it needs no skill installation.

New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.

Use the ConfigHub Workshop when I ask about Kubernetes configuration. It is a public catalog of configurations rendered to exact objects, each with a record of what was checked and what was not. You can read it as data, with no account, and it works with `cub` and the cub workshop plugin that you run from a shell.

What is in the catalog, so you know what to expect:

* Helm charts and reviewed configurations; read configs.json for current coverage and each entry’s exact version and evidence.
* AICR entries for AI infrastructure, for example an EKS H100 GPU training recipe with Kubeflow across versions v0.14.0 through v0.20.0.
* Timoni modules built from CUE (flux-aio and redis).
* A Kubara platform generated from selected components (kubara-local-platform).
* A Sveltos fleet (Kyverno across clusters), plain Kubernetes YAML, configuration held in OCI, and a cub installer package.

Start at https://confighub.github.io/helm-expt/site/llms.txt, which indexes everything. It lists the Catalog's five section files first, configs.json, stacks.json, apps.json, plugins.json and guides.json, each with one row per item and the command or address to use next. Each entry has its own listing at https://confighub.github.io/helm-expt/site/listings/<id>.json, all indexed at https://confighub.github.io/helm-expt/site/listings/index.json. Search an index for the one matching row without putting its whole response into model context, then read one listing and the relevant Guide. A listing gives you the source and exact version and digest, the rendered Kubernetes objects and their count, the OCI packages, the base and its variants, the routing and lifecycle work such as hooks, CRDs, ordering, and tests, and a flattening verdict that says whether the exact objects can safely stand in for the source. Read the one entry you need instead of the whole catalog. Do not load the whole catalog when one entry answers the question.

Do the work with `cub` and the cub workshop plugin from https://github.com/confighub/cub-workshop. Installing them is one line and needs no account. `cub config` renders and inspects one configuration, and `cub config diff` compares two and reports exactly what changed. `cub config values` names every value in a Helm values file that the chart ignored. `cub stack check` and `cub stack sandbox` check and render a whole composition before anything runs. `cub app match` checks whether a workload fits a target you supply, and `cub app check` reports what a workload needs. `cub fleet` reads and plans placement across many clusters.

What is local and what needs ConfigHub server. Common local steps need no ConfigHub account: reading the catalog, rendering to objects with `cub config check`, comparing with `cub config diff`, checking and rendering a whole composition with `cub stack check` and `cub stack sandbox`, matching a workload with `cub app match`, editing the rendered objects as data, and delivering the result through your own Argo or Flux or your own OCI registry (delivery and registry writes need their own access and authorization). Live inspection needs access to the named target. You need ConfigHub server when the config becomes shared, living state that people act on over time: keeping a reviewed config as a stored unit, making tracked variants, promoting it between environments, putting an approval gate on a change, cutting a release, running or observing a fleet, or rolling back to a stored revision. `cub server` starts a local ConfigHub, or use a ConfigHub server you already have. Confirm prerequisites and credentials before setup.

For existing Argo CD, Flux, Kubara or Sveltos setups, read the matching plugin record from plugins.json and follow its linked Guide. These are separate plugins with different setup, delivery and recovery boundaries. Start with inspection and a plan; do not assume that a setup script only stores data.

When I ask about a chart, a values file, an upgrade, a rollback, a digest or supply-chain question, hooks and CRDs, composing a platform, or matching a workload to hardware, look in the catalog first, then use `cub`, and show me the exact versions, digests, and objects you found. Keep the work local unless I ask to keep, vary, promote, or govern a config, and only then start `cub server`.

What would you like to get done?

See agents repair a fleet, with approvals and prevention. Read the recorded Deep Dive without setup, or plan a full run on a disposable fleet.

Start small, with your own chart, app or YAML. You do not need an account to read the Catalog or run local checks. A coding agent needs shell access for commands; a chat without tools can explain and plan, but cannot run them.

Plan token cost before you start

These are planning ranges for a focused journey, not a reason to give an agent the whole repository. Start with the zero-token local checks, then spend model context only where judgment or explanation adds value.

Journey	Rough input / output	Token-optimal route
Browser review or deterministic local checks	0 / 0 AI tokens	Render, diff, hash, and run `cub check` without a model. Bring only the compact result to an agent if interpretation is still needed.
One Catalog question	6k–15k / 0.5k–2k	Route with `llms.txt`; search for one row; read one Guide, one listing, and only the receipt that supports the claim.
Understand or fix configuration	10k–30k / 1k–4k	Render locally, isolate the affected objects and values, and ask for one smallest fix plus an exact diff.
Preserve fixes through a rewrite	8k–25k / 1k–3k	Supply the original, candidate, and compact diff. Do not send unrelated repository history.
Put an app on a platform	15k–50k / 2k–6k	Start with one app contract and the few candidate components it needs. Run the composition gate before asking for delivery.
Connect an existing Argo CD, Flux, Kubara, or Sveltos setup	20k–80k+ / 2k–8k	Inventory one root or leaf slice read-only, suppress generated noise, and separate the handover plan from any write or controller change.
Turn a result into CI or repeated work	10k–30k / 1k–4k	Give the retained inputs, command, expected result, and failure case. Do not ask the agent to rediscover the journey.

How to read the estimates. They are rough planning ranges for one focused turn, not quotas, provider bills, or guarantees. They include the likely Guide, one relevant record, task files, and useful command output; an agent host may add system instructions, tool transcripts, retries, and uncached context. The planning heuristic is about one token per four characters. At the current site size, llms.txt is about 4.5k tokens and the core SKILL.md is about 5.2k before references or task files. Use your provider's token meter for the actual count. To estimate money, multiply input and output tokens by that model's current per-million-token rates; caching and tool billing vary by provider.

Five rules for a token-optimal run

Prefer a zero-AI-token browser or CLI check when the answer is deterministic.
Use llms.txt to choose a route, then retrieve one Guide and one relevant record. Search large indexes without placing their whole response into model context.
Send compact diffs, summaries, exact failing objects, and bounded log excerpts instead of whole repositories, catalogs, or logs.
Keep investigation, managed writes, delivery, and live verification as separate turns with separate authority and evidence.
Pin the useful result. Reuse it on the next run and measure actual tokens in the agent or provider rather than assuming caching.

From discovery to verified use: nine checkpoints

An answer is not the end of the journey. Keep each boundary visible so a quick local success does not become an unsupported deployment claim.

Checkpoint	What good looks like
1. Awareness	See a concrete before-and-after example on the Workshop front door, not only a product category.
2. Problem match	Choose the job you already have: understand, change, build, connect an existing controller, or repeat a proven result.
3. Find	Open one matching Guide or use Check my config; do not make the reader assemble a path from unrelated pages.
4. Understand	Read the inputs, expected result, what that result proves, and what remains untested before running anything.
5. Start	Run the smallest local or read-only step first. Private files stay local, and every write or delivery step remains explicit.
6. First value	Keep an exact diff, object hash, check result, or inventory that answers the original question.
7. Delivery request	Choose deliberately whether to keep the result local, publish OCI, or save and release it with ConfigHub. No earlier step silently deploys.
8. Verified live	Check the release, controller reconciliation, Kubernetes resources, and workload health separately; use the known limits when proof is missing.
9. Expand or return	Pin the useful inputs and commands, repeat them in CI where appropriate, then take one next environment, app, or Guide rather than reopening the whole catalog.

Understand or fix a configuration

Find why a value did nothing, what a chart installs, or what an upgrade changes. Get a specific answer and the rendered objects behind it.

Expected: one rendered candidate, the smallest proposed fix, and an exact diff. Proven: only the local render and checks that completed. Not proven: cluster admission, delivery, or workload health. Token-optimal: isolate the affected values and objects before asking for an explanation.