Add Kiro to databricks aitools install - #6436
Conversation
Kiro reads agent skills from ~/.kiro/skills (user-level) and <workspace>/.kiro/skills (workspace-level), each skill a directory holding a SKILL.md. Its loader requires frontmatter name and description, rejects a name longer than 64 characters or a description longer than 1024, and requires the name to match its directory. That is already what this repo emits, so Kiro needs only a registry entry. Verified on macOS with Kiro 1.0.182: all 29 stable skills written to ~/.kiro/skills are accepted by Kiro's loader. The only rejections in that directory were two deliberately malformed probes and two unrelated pre-existing skills whose frontmatter name does not match their directory. Kiro is IDE-first, so the `kiro` binary is frequently absent from PATH. Detection then falls back to ConfigDir and reports files-only, which is the correct state for a skills-only agent (Plugin nil). Also adds the telemetry enum and agentType case so Kiro installs are not logged as TYPE_UNSPECIFIED, keeping TestAgentTypeCoversRegistry green. Note the matching AitoolsAgentType value is still needed in enum.proto on the Universe side; only the CLI half is in this change. Follows the same shape as Goose (databricks#6214), Gemini CLI (databricks#6204) and Pi (databricks#6199).
Approval status: pending
|
|
An authorized user can trigger integration tests manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
Summary
Adds Kiro to the agent registry so
databricks aitools installtreats it like any other skills-only agent. Follows the same shape as Goose (#6214), Gemini CLI (#6204) and Pi (#6199).Why
Kiro reads agent skills from
~/.kiro/skills(user-level) and<workspace>/.kiro/skills(workspace-level), each skill a directory containingSKILL.md— exactly the layout this repo already emits. Today Kiro users have to fall back todatabricks aitools install --path ~/.kiro/skills, which works but records no state, soaitools updateandaitools uninstallnever see those skills andaitools listreports every one of them asnot installed.Verification
Tested on macOS with Kiro 1.0.182.
Kiro's loader (
NodeProgressiveContextSource) rejects a skill when frontmatter is missing, whennameordescriptionis empty, whennameis outside 1–64 characters, whendescriptionexceeds 1024, or whennamedoes not equal the directory name. Everything this repo emits satisfies that.With 29 stable skills installed into
~/.kiro/skills, Kiro accepted all 29. The only rejections in that directory were two deliberately malformed probe skills added to confirm the loader was really scanning, plus two unrelated pre-existing skills whose frontmatternamedisagrees with their directory:Worth knowing for anyone testing this: Kiro resolves skills lazily when a chat session starts, not when the IDE launches. Installing and then looking at an already-open Kiro shows nothing until a new session begins.
Notes on the registry entry
SkillsSubdiris left empty because Kiro's directory is literallyskills, so the default applies.SupportsProjectScope: true— Kiro's own picker text documents both scopes.Binary: "kiro"is set, but Kiro is IDE-first so the binary is frequently absent fromPATH. Detection then falls back toConfigDirand reports files-only, which is the correct state for a skills-only agent (Plugin nil).Telemetry
Also adds
AitoolsAgentTypeKiroand the matchingagentTypecase, so Kiro installs are not logged asTYPE_UNSPECIFIEDandTestAgentTypeCoversRegistrystays green.One thing a maintainer will need to do: that guard's failure message notes the enum lives in
enum.proto(Universe) as well asaitools_install.go(CLI). Only the CLI half is in this PR, since the Universe proto isn't in this repo. Happy to follow whatever process you prefer for the proto side.Tests
Test coverage added alongside the existing Goose cases: registry paths and project detection in
libs/aitools/agents/registry_test.go, the skills-only assertion inagents_test.go, and the project-scope declaration inlibs/aitools/installer/installer_test.go.