Copilot skills picker reports no skills despite skills available to the agent #30

Report

In a Copilot-provider thread, the $ composer picker opens but reports "No skills found", although skills are available to the agent in that environment. Investigate provider discovery and UI exposure separately from trigger/menu rendering.

Correction to the initial report: the user initially thought neither / nor $ opened a menu. While composing the report, they captured the $ popover. The confirmed screenshot symptom is an empty skills menu, not complete absence of a menu.

Observed behavior

The supplied screenshot shows:

No skills found. Try / to browse provider commands.

The user expects at least human-facing-writing to be available. In the environment hosting this conversation:

• The agent can load and use human-facing-writing.
• .agents/skills/human-facing-writing exists as a link to the shared skill source.

That establishes agent-side skill availability, not that t3code's provider snapshot currently includes the same skill or uses the same discovery configuration.

The user also reports / did not show the expected options. No screenshot or independent UI reproduction establishes the exact / behavior yet. Track that separately: / provider commands and $ skills are different surfaces, and not every native CLI command necessarily has an SDK/adapter equivalent.

Reproduction

1. Open a Copilot-provider thread in an environment where human-facing-writing is available to the native agent.
2. In the composer, type $ where the skill trigger is recognized.
3. Observe whether skills populate. In the report, the popover appeared with the empty-state message above.
4. Search for human-facing-writing, then separately test / and record whether a provider-command menu appears and which commands it offers.
5. Compare the effective environment/cwd/Copilot home, native skill discovery, provider snapshot, and composer results without changing the environment's installed skills.

Expected behavior

• Skills discoverable by the effective Copilot runtime should be surfaced through the intended t3code skills picker, including human-facing-writing when enabled/available.
• Loading, discovery failure, unsupported capability, filtering/disabled state, and a genuinely empty skill set should not all collapse into an unexplained "No skills found".
• / should show supported provider commands or explain the limitation. Document the intended distinction between / commands and $ skills rather than inventing unsupported native command forwarding.
• Selecting a listed skill should use the adapter's supported invocation mechanism.

Existing fork work worth checking

The requested preview branch was inspected at 1ba8423c8611d65dc9739a970fe84c78c9892710:

• copilot-skill-discovery/status.json describes handling session.skills_loaded, an rpc.skills.list() fallback, mapping to ServerProviderSkill, and updating the provider snapshot so $ autocomplete populates. Its recorded state is blocked, with reconciliation blocked by a parent.
• copilot-skill-controls-ui/status.json remains requested. Enable/disable controls are related but are not required to fix discovery.
• These records are leads, not proof of the running build's implementation or the root cause. Confirm what actually shipped.
• Related backlog: [A-009] Inventory native provider capabilities versus T3 exposure #16 (native provider capabilities versus t3code exposure).

Current upstream contains the same empty-state text in ComposerCommandMenu.tsx. This confirms the UI distinction, not that the same provider implementation or behavior is deployed in this fork. No unrelated upstream screenshot is being presented as evidence of this running build.

Acceptance criteria

• A controlled Copilot thread with a known installed skill lists it in $ autocomplete.
• Discovery remains correct for shared/symlinked skill directories and the effective remote environment, cwd, and Copilot home.
• Initial session startup and reconnect/resume refresh the skill snapshot without requiring a first unrelated user turn as an undocumented workaround.
• Discovery errors/unsupported states are visible and actionable; an empty search result is distinguishable from missing capability or failed discovery.
• / behavior is reproduced and either corrected or explicitly documented for Copilot.
• Add adapter/snapshot and composer coverage; avoid regressing other providers.

Evidence limits

The actual empty-state screenshot was supplied by the reporter. UI actions were not independently reproduced during filing. Exact desktop/frontend build remains unverified; the separately inspected MLVM backend is 0.0.42-preview.20261003.2.
The screenshot remains in the originating conversation and is not attached to this issue.