[Bug]: Kiro skills never show in the / or $ menu, though Kiro sends them in available_commands_update #31645

On Kiro threads, the composer menus never offer Kiro skills. Kiro sends the skills that it finds for the session in available_commands_update, but the Kiro provider does not publish those commands to the provider snapshot that the composer reads.

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Kiro provider: packages/provider-kiro, packages/provider-acp.

Steps to reproduce

Steps for a signed-in install. The run that I recorded used a stand-in for the Kiro sign-in; see "How this was reproduced" below.

1. Install kiro-cli 2.37.1 and sign in.

2. Add this skill as ~/.kiro/skills/probe-skill/SKILL.md:

   ---
   name: probe-skill
   description: A probe skill that checks skill discovery over ACP.
   ---
   
   Say PROBE.

3. In Settings → Providers, enable Kiro and refresh it.

4. Start a Kiro thread and send a message, so that a Kiro session starts. Wait a few seconds after the session starts.

5. In the composer, type /probe. Then type $probe.

Expected behavior

The / menu lists /skill:probe-skill, and the $ menu lists probe-skill. docs/user/composer.md says: "Type / for commands or $ to add a skill from the selected environment and provider", and "The slash menu also includes skills unless you turn off … Show skills in slash menu". That setting is on by default. ACP registry agents get their menu entries from the same ACP update (packages/provider-acp-registry/src/server/adapter.ts:265).

Actual behavior

With default settings:

• /probe shows "No matching command."
• / lists only /model, /side, /btw and /compact.
• $probe shows "No skills found. Try / to browse provider commands."

The menus stay the same after the Kiro session starts. In that session, Kiro sent two available_commands_update notifications. The first had only the two custom agents. The second, a moment later, also had the skill:

Cause. The same code is on tag v0.1.7 (322f654) and on main @ 09eb653. Line numbers are for main:

• packages/provider-kiro/src/server/status.ts:92: the Kiro snapshot sets slashCommands: [COMPACT_SLASH_COMMAND] and no skills. After the status check, ~/.t3/caches/kiro.json has "skills": [].
• packages/provider-kiro/src/server/driver.ts has no snapshotForCwd, so there is no workspace skill scan for Kiro.
• packages/provider-acp/src/server/adapter.ts:6273 (6198 on v0.1.7) gives each available_commands_update to flavor.onAvailableCommandsUpdate. In production code, only the ACP registry adapter sets that hook (packages/provider-acp-registry/src/server/adapter.ts:265). makeKiroAcpAdapterFlavor (packages/provider-kiro/src/server/adapter.ts:526) does not set it. So no command from that update reaches the provider snapshot.

Kiro's side. kiro-cli 2.37.1 runs @kiro/agent 0.66.70. In its dist/server/acp-server.js, the slash command manager collects commands from steering, custom agents, power skills, skills, workflows, goal and prompts, and sends them in available_commands_update. The skill source maps each skill of the session catalog to { name, description, input: { hint }, _meta: { kiro: { type: "skill", resource, originalName } } }. The names have no $ prefix. I found no sign-in check on this path. T3's recorded Kiro fixtures (apps/server/src/orchestration-v2/testkit/fixtures/kiro_*) also contain these updates. The recorder removes each command whose source has an origin other than bundled (apps/server/scripts/record-kiro-acp-replay-fixture.ts:295-303), so the fixtures show only steering and custom-agent entries.

How this was reproduced. T3 v0.1.7 (t3 serve, web client in headless Chromium), with no Kiro account:

• A kiro-cli stand-in on PATH answered --version (2.37.1), whoami and chat --list-models. T3 showed Kiro as ready.
• For acp, the stand-in ignored the flags that T3 sent (--agent-engine=v3 --auth-method=cli). It started the real @kiro/agent 0.66.70 engine from the kiro-cli 2.37.1 Linux package (sha256 b4049000d5a7…) with Node and a placeholder KIRO_API_KEY.
• The engine started the session and sent both updates. Then the prompt failed with "Access denied", because the key is not real. Skill discovery does not need that key.

The reporter first saw the symptom on a signed-in kiro-cli 2.37.1 install: none of the skills in ~/.kiro/skills showed in the / menu.

Not checked:

• A signed-in turn in the recorded run.
• How Kiro expects a selected skill in session/prompt. On feat(provider-kiro): add Kiro as an ACP provider #14693, a comment found that Kiro answers plain /compact text as chat.
• Skills in a project's .kiro/skills.

Impact

Major degradation or frequent failure

On every Kiro thread, no Kiro skill can be selected from the / or $ menu. Chat still works.

Version or commit

Seen on t3 v0.1.7. The code on main @ 09eb653 has the same gap.

Environment

Linux x86_64. kiro-cli 2.37.1 (@kiro/agent 0.66.70), started by T3 as kiro-cli acp --agent-engine=v3 --auth-method=cli.

Logs or stack traces

# ~/.t3/caches/kiro.json, the Kiro provider entry (other keys removed)
{"status":"ready","version":"2.37.1","slashCommands":[{"name":"compact","description":"Summarize the conversation and reduce context usage"}],"skills":[]}

# Kiro -> T3, second available_commands_update of the thread's session (abridged: the agent entries are shortened)
{"jsonrpc":"2.0","method":"session/update","params":{"sessionId":"sess_…","update":{"sessionUpdate":"available_commands_update","availableCommands":[
  {"name":"general-task-execution","description":"General-purpose sub-agent …","_meta":{"kiro":{"type":"custom-agent", …}}},
  {"name":"context-gatherer","description":"Investigates the codebase …","_meta":{"kiro":{"type":"custom-agent", …}}},
  {"name":"probe-skill","description":"A probe skill that checks skill discovery over ACP.","input":{"hint":"optional context"},"_meta":{"kiro":{"type":"skill","resource":{"resourceType":"skill","source":{"origin":"user"}},"originalName":"probe-skill"}}}]}}}

# Kiro -> T3, the prompt after that (placeholder key)
{"code":-32000,"message":"Access denied. Please check your authentication. …"}

Workaround

None in the menus. Kiro lists the skill in its context data (session_info_update), so a request for the skill by name in a message can work. I did not test that with a signed-in turn.

Related

• [Bug]: Muse provider doesn't surface Personal/Project skills in composer skill picker #19155: Muse skills missing from the composer (issue). Muse has no skill discovery at all.
• PRs for other providers: fix(acp): list Copilot skills in the skill menu #26438 (Copilot) and fix(acp): expose Droid and Kimi skills in picker #27963 (Droid and Kimi) map ACP registry commands to skills; fix(provider-muse): show skills in the composer pickers #20774 (Muse) adds Muse skill discovery. None of them changes packages/provider-kiro.
• [Bug]: ACP Registry provider skills are missing from the / menu in a new thread until the first message is sent #26460: ACP registry skills show only after the first message. The Kiro status check does not start a session (probeKiroAgents, packages/provider-kiro/src/server/status.ts:338-354), so skills for a new thread need another source or come with the first session.
• Possible direction: set onAvailableCommandsUpdate in the Kiro flavor, and publish the commands with _meta.kiro.type === "skill" as provider skills. A provider skill needs a path (packages/contracts/src/server.ts:113), and Kiro's command has none, so the fix must make one. The ACP registry path already makes one for $ commands (packages/provider-acp-registry/src/server/probe.ts:233). I did not build or test this.

Filed with Claude Opus 5.5 in Claude Code. Checked by Claude Fable 5.1, GPT-6 Astra and Muse Wonder Full.