Inspect and keep an exact record
Download record.json with the full Redis default record and its Catalog and record hashes. No setup needed. The linked draft exercise reproduces the lookup and a refusal locally with Node and a checkout.
Give Claude, Codex, or another coding agent one configuration question. The ConfigHub Workshop skill finds exact Catalog records and the lifecycle work to check. It returns a result you can review.
The agent may propose commands or changes, and you see the source, the Kubernetes objects and the diff before any of it is applied or uploaded. You also see the checks that ran and the limits that still apply.
Local Guides and inspection
Finish with files you can inspect and keep. The walkthroughs include setup, direct commands, an assistant task, expected results and a failure case. Start with the job you need; no ConfigHub account or cluster is needed.
Inspect and keep an exact record
Download record.json with the full Redis default record and its Catalog and record hashes. No setup needed. The linked draft exercise reproduces the lookup and a refusal locally with Node and a checkout.
Walk the ten questions a Helm user asks, with the pain beneath each one and a check you run on your agent's answer.
Compose a platform with an app
Save a Kubara and Argo CD selection, move it, edit the app and retain a refusal when an API does not fit.
Adapt a configuration and review the edit
Change one replica count, inspect the exact diff and spot an unexpected second edit.
Match a GPU workload to supplied facts
Keep candidate, mismatch and unknown results separately, with the input hashes behind each answer.
Find why a Helm value did nothing
Compare a typo with the correct key in controlled renders, including a value the template transforms.
Add a field and preserve the source
Review one added label, detect an object replacement and restore the exact original file.
Compare retained versions and prepare a review packet that keeps missing promotion evidence visible.
Inspect a hook without running it, preserve an API refusal and identify what delivery still requires.
Answer the questions Timoni users ask
Build a typed module's exact objects, check the typed schema and the CRD ordering, and see which module bytes are digest-bound.
Assistants run the same commands. Inspection uses the repository adapter; the cub Guides use the Workshop plugin. Actual live-chat API integration remains a separate route.
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. Private files stay on your machine and Secret values are redacted. It pins versions and digests, reports any check it skipped, and previews a change before making it.
An assistant given only this site and one sentence has already composed a five-component stack and had it certified, in about six minutes. The run is recorded verbatim, including what it could not discover. The gate, not the assistant, is where its mistakes would have been caught.
An agent helps at every stage but cannot supply the input a stage needs. Tell it to report missing work as blocked or not run, rather than promoting a nearby result into a pass. For AICR, snapshot and diff inspect existing GPU nodes without a recipe or Catalog match, and a recipe-dependent expected-resources check applies only after those components have been deployed. See the four questions and what each needs.
Start with the job in front of you. Include the exact version or digest when you know it.
| Task | Example request | What the agent should return |
|---|---|---|
| Find a known answer | What will bitnami/redis 25.5.3 install, and what must exist first? | The exact Catalog version, objects, lifecycle work, checks, and limits. |
| Check my configuration | Here is the chart and values my AI produced. Compare them with the defaults and tell me what matters. | A local render, normalized comparison, findings, and a reviewed result you can keep. |
| Review a promotion | Can I move this staging configuration to production? | Current and candidate digests, destination differences, lifecycle work, and tests still required. |
| Inspect another source | Build the retained Timoni Redis 8.10.1 source and tell me what plain YAML leaves out. | The module digest, typed options, seven exact objects, ordered lifecycle, and current limits. |
Check my config builds a local prompt and browser review. Promote my config compares current and proposed objects. Neither page uploads your files.
For an upgrade or environment move, open Promote my config, compare the two object sets, download the promotion review, and copy its AI review prompt. The prompt tells the agent to name any destination checks and tests that have not run yet.
After the source tool writes Kubernetes YAML, the agent can run the same released local checker a person uses:
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.
cub plugin install confighub/homebrew-tap@cub-scan-v0.7.3 --name scan
cub check --format json --output cub-check.json ./rendered
cub check is advisory and does not apply configuration. The agent must keep its result with the exact object digest and list target or live checks that did not run.
The skill reads the same public files as the site. Page copy and an agent's explanation are not records.
| Record | What it answers |
|---|---|
| changes.json | Which exact Helm package version and digest did you ask about, and which areas have evidence? |
| base-variant-records.json | Where did the configuration come from, which exact objects were produced, and what lifecycle, ownership, OCI, and delivery records exist? |
| review and promotion records | Which files were compared, which checks ran, and what remains before the result moves? |
| linked receipts | What command or live run produced a claim, for which object digest and target? |
Missing coverage means the claim is unchecked. A successful render proves the objects are well formed, while cluster admission, controller convergence and workload health remain open, along with upgrade and rollback.
Every maintained entry also has a machine-readable listing at its own URL, whatever format it came from. An agent that wants one entry reads that one file instead of the whole catalog. Start from the listing index for an entry's id and URL, read the listing schema for the fields every listing fills, or open one example listing to see them filled in.
Helm renders, Timoni builds, AICR and Kubara compose or generate, and literal YAML or configuration OCI already contains exact objects. The same source-and-intent, materialize, flatten, lifecycle, and deliver steps apply to each, so an agent records which operation happened instead of calling every source a Helm recipe. See what each format becomes · Read the agent processing model
The first Timoni entry retains Redis 8.10.1 at an immutable module digest. Its typed options, seven exact objects, master-first apply order, optional test Job, and destination requirements are recorded like any other base. The current record proves a local build and an anonymous OCI pull, not a Kubernetes apply or GitOps delivery. See how Timoni and every other format fits the model.
Open the Timoni Redis record · Read the ConfigHub base guide · Read the development variant · Check the proof and limits · Compare it with Helm Redis configurations
Use ConfigHub when the accepted objects need team history, approvals, and comparison with live systems. The handoff should keep the same object digest visible before and after upload.
One recorded AICR example starts with an unsafe proposal: too many H100 nodes, a mutable image, and an inline API key. ConfigHub stores the corrected object, runs the applicable checks, and requires approval before an OCI dry run. It does not claim a policy automatically enforced the GPU-node limit for that target.
Read the checked result and its limits · Continue with ConfigHub
Agents read source behavior, propose starting configurations and generate checks. They also investigate failures and explain receipts. Whatever they write is reviewed against committed data before it appears as a Catalog claim.
| Agent task | Required record |
|---|---|
| Read source behavior | Inspect versions, values or typed options, templates, generated objects, hooks, CRDs, tests, waits, prerequisites, and destination assumptions. |
| Propose useful configurations | Suggest chart-specific or source-specific starting choices. The generator and recorded checks decide what enters the Catalog. |
| Investigate failures | Separate input errors, missing target setup, lifecycle work, controller results, and workload health. |
| Maintain explanations | Turn exact records and receipts into short instructions while keeping links to the underlying evidence. |
Read the fresh-agent evaluation · Run the verification commands · Open technical guides