[danielle-mustillo]

Why

A new kagent install has no example agent and no skills to start from, and the UI has no way to add a skill to an agent. Today skills can only be set with kubectl.

What changed

Built-ins in the chart. A new builtins values group gives a new install a starting point:

• builtins.harness: a Go ADK Harness named kagent on the chart's worker pool.
• builtins.k8sAgent: an Agent named k8s-agent on that Harness. It uses the kagent-tools Kubernetes tools and the k8s-troubleshooting skill. Tools that change the cluster wait for approval.
• builtins.skills: the skills the UI offers. builtins.skills.image with builtins.skills.list offers skills from another image instead.
• builtins.enabled: false turns all three off. Each also has its own enabled.

The Harness and the Agent need substrateWorkerPool.create, which kagent install sets.

Skills come from kagent-tools. kagent does not build a skills image of its own.

• The kagent-tools dependency goes from 0.3.0 to 0.3.1, the first release that ships skills, so the skills match the tool server the chart deploys.
• The UI offers three of them: k8s-troubleshooting, helm-release-management and istio-traffic-debugging. The image's other skills need Argo Rollouts, Cilium, Kubescape or Prometheus, so the list leaves them out.
• helm/kagent/files/builtin-skills.json holds the list and the kagent-tools image pinned by digest. make builtin-skills-catalog regenerates it from the image.
• The chart passes the list to the UI as KAGENT_UI_BUILTIN_SKILLS. global.imageRegistry mirrors the image.

Skills in the agent template form.

• A user can pick a built-in skill, or add their own from an OCI image (pinned by digest), Git (URL and full commit) or S3 (with object version), with an optional path.
• Saving writes spec.skills. The form rejects what the CRD or the runtime would reject, and each message names the skill.
• A built-in skill saved from an older kagent-tools image shows "Older version" and an Update button.
• plugins and promptTemplate, which the form does not show, are kept on save.

Limits

• A Git or S3 skill source keeps an Agent from becoming Ready until fix(substrate): let the golden actor fetch git and S3 skill sources #3435 merges. The form offers them anyway.
• A skill only names tools. An Agent a user builds must also bind the tools its skills use.
• helm upgrade --reuse-values from an older release keeps the old chart's defaults, which have no builtins values. The chart then renders no built-ins instead of failing. --reset-then-reuse-values picks up the new defaults and turns them on.
• CI e2e sets builtins.harness.enabled: false, because the lifecycle suite applies its own Harness named kagent. CI also turns kagent-tools off, so CI does not run k8s-agent.

Testing

• helm unittest helm/kagent: 378 tests pass.
• yarn typecheck, vitest (810 tests), the UI entrypoint Go tests and the mock Playwright agent-templates journey pass.
• On a Kind cluster running this chart:
  • The UI serves the three skills, and the agent template form lists them.
  • k8s-agent is Ready with its skill from ghcr.io/kagent-dev/kagent/tools@sha256:607cb0ac…. Asked about a crash-looping pod, it called load_skill for k8s-troubleshooting and got the kagent-tools text back.
  • builtins.enabled=false removed the Harness, the Agent and the UI skill list. Turning it back on restored them, and k8s-agent became Ready again.
  • An upgrade from main with --reuse-values succeeded with no built-ins. A following --reset-then-reuse-values upgrade brought them back, and k8s-agent became Ready.

[danielle-mustillo]

• Agent template form: before, there is no way to add a skill. After, a Skills field adds a built-in kagent skill (k8s-troubleshooting) from the chart's catalog, or your own OCI, Git or S3 skill.
• Agent template details: before, a template's skills are hidden behind a notice saying to use kubectl. After, each skill is listed with its full source.
• Fresh Helm install: before, there is no Harness and no Agent. After, the chart ships Harness kagent and a Ready k8s-agent with the k8s-troubleshooting skill from the kagent-tools image.

pr3554-reel.mp4

Screenshots

Before: new template form has no Skills field

After: Skills field with a kagent skill

Before: template's skills hidden behind a notice

After: template details list both skills in full

---

Written by 🤖

[Charlesthebird]

This automated review is a first pass. A manual review will follow once the blockers are addressed.

---

Nothing blocks merge. One non-blocking gap: the skill form accepts an OCI image the controller rejects.

✅ What I checked

• ✅ --reuse-values from a release without builtins: every read goes through dig on .Values.AsMap
• ✅ global.imageRegistry: the catalog and k8s-agent both use the mirrored image, so "Older version" compares like with like
• ✅ Git, S3, path, 50-skill limit and duplicate-name checks against the v1alpha3 CRD and the translator
• ✅ plugins and promptTemplate on save: specFromDraft replaces only spec.skills
• ✅ KAGENT_UI_BUILTIN_SKILLS escaping through the entrypoint into JSON.parse
• ✅ CI: only the Harness named kagent clashes with the lifecycle suite, and k8s-agent drops out with kagent-tools off
• ✅ Default s3://ate-snapshots/kagent/ matches the RustFS store in setup-cluster.sh
• ✅ No internal brand terms in the diff

---

Written by 🤖

[Charlesthebird]

Level: 🟠 Medium · Not Blocking

The controller parses this with name.NewDigest (skills.go#L71), so ghcr.io/MyOrg/skills@sha256:… saves here but the Agent never becomes Ready.

Suggested change

	if (draft.sourceKind === "oci" && !OCI_DIGEST_REF.test(source.oci ?? "")) {
	problems.push(`${label} needs an OCI image pinned by digest, like ghcr.io/org/skills@sha256:<64 hex characters>.`);
	}
	if (draft.sourceKind === "oci" && !OCI_DIGEST_REF.test(source.oci ?? "")) {
	problems.push(`${label} needs an OCI image pinned by digest, like ghcr.io/org/skills@sha256:<64 hex characters>.`);
	} else if (draft.sourceKind === "oci" && /[A-Z]/.test((source.oci ?? "").split("@")[0])) {
	problems.push(`${label} needs an image name in lowercase.`);
	}

---

Written by 🤖

[Charlesthebird]

On second review, this LGTM overall. Couple notes:

• Could /improve-ui for both of these areas. Specifically, it could be clearer what skill the delete button is for, and the link could look more like a link.

[Charlesthebird]

For this, would there be another agent for the built in skills like "helm-release-management" or other skills from istio-traffic-debugging?

Maybe we could start with this and then add other agents for those other groups of skills (for example the argo-rollouts or other agents from v0.x)

[younsl]

The kagent-tools bump to 0.3.1 in this PR also fixes a downgrade for users upgrading from 0.10.x. The v0.10.6 chart depends on kagent-tools 0.3.1, while v1.0.0 pins 0.3.0, so moving from 0.10.6 to 1.0.0 rolls kagent-tools back.

Keeping this dependency on the latest tools release matters because operational fixes land there. For example, kagent-dev/tools#84 (the Streamable HTTP server leaking heap on every MCP initialize request) was fixed in 0.3.0 by kagent-dev/tools#85. Users only get fixes like that without overriding the subchart when the chart tracks the current release.

Changes between kagent-tools 0.3.0 and 0.3.1:

• CVE fixes in the bundled CLIs and Go dependencies (kagent-dev/tools#99)
• The kagent 1.x skills bundle in the tools image (kagent-dev/tools#91)

If the rest of this PR needs more review time, landing the dependency bump on its own would keep the next 1.0.x release from shipping the older tools chart.

[blacksmith-sh]

Found 2 test failures on Blacksmith runners:

Failures

Test	View Logs
github.com/kagent-dev/kagent/go/core/test/upgrade/TestUpgrade	View Logs
github.com/kagent-dev/kagent/go/core/test/upgrade/TestUpgrade/upgrade_to_current_build	View Logs

^{Need help on this PR? Tag @codesmith-bot with what you need.}