Bug: slash autocomplete omits all installed skills despite '18 loaded' header (v0.83.0, Windows)

[rensburger]

Summary

In Jcode v0.83.0 (1301e382b) on Windows x86_64, the startup header reports Skills: 18 loaded, and skill_manage action=list confirms those 18 skills, but typing / presents a suggestion list containing only the 111 built-in commands. None of the installed skill commands are included.

This is not simply an eight-row viewport hiding skills further down the list. The screenshot's pagination count and final eight entries exactly match the complete built-in-only command registry in the installed revision.

Environment

• Jcode: jcode v0.83.0 (1301e382b) (confirmed with jcode --version)
• OS / architecture: Windows / x86_64
• Observed: 2026-09-06
• Working directory: ~/dev
• Skill location: %USERPROFILE%\.agents\skills\<skill-name>\SKILL.md
• 18 installed skills, confirmed by skill_manage action=list
• No claim yet that this is Windows-specific. The implicated client initialization and autocomplete code is shared.

Observed reproduction

1. Have valid skills installed under ~/.agents/skills/.
2. Open the TUI. In the affected session, the startup header displays Skills: 18 loaded.
3. Type a bare / and browse the command suggestions to the end.
4. Observe that only built-in commands appear. The final page has ↑103 on its first row and eight visible rows, ending in /provider-test-coverage.
5. Ask the agent to run skill_manage action=list. It reports Loaded skills: 18, including /ponytail, /humaniser, and the Google ADK and Matt Pocock skills, with their existing SKILL.md paths.

These steps describe the reported session. A fresh-session automated TUI reproduction has not yet been run, and the exact startup/event timing needed to trigger the omission is not established.

Screenshot evidence, transcribed

The original screenshot was supplied in the debugging conversation. Its relevant content is transcribed here rather than claiming an image attachment:

Skills: 18 loaded
~/dev

1> /
/thinking-display       Show/hide the model's thinking text (off/full/current)  ↑103
/tool-call-details      Show/toggle dimmed technical details on tool rows with an intent
/fast-macos-release     Publish a prepared macOS arm64 build immediately; CI adds other platforms
/onboarding-preview     Preview the first-run onboarding screen
/refresh-model-list     Refresh provider model catalogs
/compact-notifications  Show/toggle single-line swarm/file-activity notifications
/show-agentgrep-output  Show/toggle full agentgrep search output inline in chat
/provider-test-coverage Show live-test evidence for the current provider/model

There is no +N more indicator below the final row. The selected final command is /provider-test-coverage.

Why this proves an omission rather than scrolling

The source of the exact installed revision, not just a different local checkout, was fetched and checked:

• Extracting RegisteredCommand::public(...) and RegisteredCommand::remote(...) entries gives 111 built-ins.
• Sorting these by command length, then name, reproduces the screenshot's final eight commands exactly.
• The screenshot shows 103 preceding entries + 8 visible entries = 111 total.
• With the 18 installed, distinct skill names included, the expected total is 129. Several installed skill commands are longer than /provider-test-coverage, so they would also change the final page.

The installed skill names are:

google-agents-cli-adk-code
google-agents-cli-deploy
google-agents-cli-eval
google-agents-cli-observability
google-agents-cli-publish
google-agents-cli-scaffold
google-agents-cli-workflow
humaniser
matt-pocock-grill-me
matt-pocock-handoff
matt-pocock-teach
matt-pocock-writing-great-skills
ponytail
ponytail-audit
ponytail-debt
ponytail-gain
ponytail-help
ponytail-review

Expected behavior

Installed, available skills should be candidates in the same slash autocomplete list as built-in commands, both for a bare / and matching prefixes such as /pony or /human.

The header, skill listing, and autocomplete should agree on which skills are available for the active session. Users should not have to first submit a prompt, invoke a missing skill, restart, or manually refresh /skills to discover already-installed skills.

Source investigation

1. Skill commands are explicitly intended to appear in autocomplete

state_ui_input_helpers.rs at 1301e382b:

command_candidates():

1. Returns the cached candidates if present.
2. Collects non-hidden registered commands.
3. Calls current_skills_snapshot() and adds /<skill.name> entries labeled Activate skill.
4. In remote/client mode, also adds names from remote_skills.
5. Caches the assembled vector.

rank_suggestions() ranks a bare / as a prefix match for every candidate, then sorts ties by command length and name. It does not intentionally exclude skills.

2. The minimal remote-client startup begins with empty skill data

These paths were also checked against the exact installed revision:

• tui_lifecycle.rs:1327-1338: new_for_remote_with_options() constructs Registry::empty() and calls new_minimal_with_session().
• tui_lifecycle.rs:350-355: the minimal constructor initializes App.skills with SkillRegistry::default().
• tool/mod.rs:302-307: Registry::empty() also contains an empty skill registry.

Thus neither of these client-local sources initially contains the installed global skills. Here, "remote" means the client/server runtime path, not necessarily an SSH connection.

3. Snapshot fallback does not load missing global skills

state_ui_runtime.rs:

current_skills_snapshot() normally reads self.registry.skills(), falling back to self.skills only when the read lock cannot be acquired. A successfully read empty registry is accepted. It then composes the project-local overlay, not a fresh global registry load.

For SSH, it returns self.skills.clone() directly. Any repair must retain remote-host isolation rather than inadvertently enumerating local-machine skills for SSH sessions.

4. Server history is an existing skill synchronization point

remote/server_events.rs:1732-1733:

app.remote_skills = skills;
app.invalidate_command_candidates_cache();

Therefore it would be inaccurate to claim there is no cache invalidation at all. The important next check is whether the affected fresh/blank client receives and applies a history payload containing its effective skills before autocomplete is first populated, and whether any other skill update path leaves the candidates cached as built-ins only.

refresh_skills_snapshot() explicitly reloads global skills and invalidates candidates, but that is a separate path from merely typing /.

Diagnosis and remaining uncertainty

Confirmed: all 18 skills are absent from this screenshot's complete autocomplete candidate list despite being discoverable by the agent and advertised as loaded in the header.

Leading explanation: incomplete initialization/synchronization of the minimal client's skill data, potentially preserved by the candidate cache. The empty minimal registry path explains how a built-in-only list can be constructed without skill files themselves being invalid.

Not yet confirmed: which startup/history/refresh event was missing or delayed in this particular session. Live debug inspection was attempted with jcode debug help, but the running instance returned Debug control is disabled. No debug setting was changed, no running session was restarted, and no fix or end-to-end verification is claimed.

Suggested investigation and regression coverage

• Reproduce using the real new_for_remote_with_options() / minimal-client path, not only a fully initialized standalone test app.
• Check a blank session before its first submitted message, then after history synchronization.
• Make the effective skill metadata available to autocomplete during client startup and invalidate cached candidates whenever that metadata changes. Avoid loading skills from disk on every rendered frame.
• Verify a bare / includes a fixture skill, and a matching prefix includes the same skill.
• Warm autocomplete while skill data is empty, deliver the real metadata/update event, and verify the fixture appears without restarting or running /skills first.
• Verify the header count and autocomplete's unique skill candidates agree for the active session.
• Preserve project-local isolation between simultaneous sessions in different working directories, and local/remote-host isolation for SSH.
• Cover installed global skills under ~/.agents/skills/, not just project-local fixtures followed by an explicit refresh.

Related issues

• Bug: skill_manage reload_all does not sync skill registry back to TUI — new skills invisible in /skills list #431: closed report about server-side skill_manage reload_all not syncing the TUI snapshot and autocomplete. This observation does not require a preceding reload operation and concerns already-installed skills in the bare-slash menu.
• Slash skill invocation uses stale registry after skill_manage reload_all #59: closed stale-registry report for direct slash invocation.
• Bug: project-local skills are loaded into the shared registry instead of a session-local overlay #457: closed project-local/global skill scoping issue. Any fix here should preserve its session-isolation invariant.

An exact currently open duplicate was not found in searches for skills slash and skills autocomplete.

[1jehuang]

Thanks for the report. Minimal local clients now load global skills before initial History, while SSH clients retain remote-only metadata and project overlays remain session-scoped.

Proposed fix: #1218, commit 0e84b66. The skill cohort passed 17 tests and the overlapping SSH cohort passed 47. Follow-up acceptance on the exact published binary: Tab completed an installed skill in the real TUI, with captured frames, before populated History. A real SSH host remains untested.

The PR remains a draft pending clean-branch CI and review. It documents the local build limitations. This issue remains open until the fix is merged and verified.

---

— Jcode agent (automated triage), on behalf of @1jehuang