Feature summary
In the composer's / slash-command menu, always show plugin-provided skills as plugin-name:skill-name, instead of only when two installed plugins collide on a skill name.
What problem are you trying to solve?
App version: v1.1.6
The / autocomplete menu lists plugin skills by bare name, and only adds the plugin qualifier when two installed plugins happen to provide the same skill name.
Observed with ~20 plugins from several marketplaces installed:
repository-policy is provided by two installed plugins, so it appears as repository-policy:repository-policy.
- Uniquely-named skills like
engineering-standards or dependency-scanning appear bare, with no indication of which plugin or marketplace provides them.
The result is an inconsistent, provenance-free menu:
- You can't tell a marketplace-provided skill from a personal or repository one while picking from
/.
- When a skill misbehaves, the menu gives you no way to know which plugin to disable, update, or uninstall.
- Two marketplaces shipping similar generic skill names are indistinguishable in the menu until they literally collide.
- Names are unstable: installing an unrelated plugin can silently rename an entry in the menu from
foo to some-plugin:foo, so muscle memory and typed prefixes break.
Proposed solution
Always display plugin-name:skill-name for plugin-provided skills in the / menu, keeping bare names for personal and repository skills. Fuzzy matching should keep working against both the bare skill name and the qualified form, so typing dependency still finds security:dependency-scanning.
If full qualification is considered too noisy, an acceptable alternative is a secondary label or badge on each menu row showing the providing plugin (and ideally the marketplace), so provenance is visible without changing the primary label.
Workflow impact
Affects anyone running with more than a couple of plugins installed, especially across multiple marketplaces. Making provenance visible in the menu makes skill selection predictable, makes plugin management actionable from the point of use, and removes the surprise of entries renaming themselves when unrelated plugins are installed.
Installation context
N/A
Additional context
The same inconsistency shows up in the skill list surfaced to the agent, where some entries are namespaced (testing-automation:playwright-explore-website, repository-policy:repository-policy) and others are bare (engineering-standards, dependency-scanning) — so this is likely a single shared display-name rule rather than a menu-only concern.
Feature summary
In the composer's
/slash-command menu, always show plugin-provided skills asplugin-name:skill-name, instead of only when two installed plugins collide on a skill name.What problem are you trying to solve?
App version: v1.1.6
The
/autocomplete menu lists plugin skills by bare name, and only adds the plugin qualifier when two installed plugins happen to provide the same skill name.Observed with ~20 plugins from several marketplaces installed:
repository-policyis provided by two installed plugins, so it appears asrepository-policy:repository-policy.engineering-standardsordependency-scanningappear bare, with no indication of which plugin or marketplace provides them.The result is an inconsistent, provenance-free menu:
/.footosome-plugin:foo, so muscle memory and typed prefixes break.Proposed solution
Always display
plugin-name:skill-namefor plugin-provided skills in the/menu, keeping bare names for personal and repository skills. Fuzzy matching should keep working against both the bare skill name and the qualified form, so typingdependencystill findssecurity:dependency-scanning.If full qualification is considered too noisy, an acceptable alternative is a secondary label or badge on each menu row showing the providing plugin (and ideally the marketplace), so provenance is visible without changing the primary label.
Workflow impact
Affects anyone running with more than a couple of plugins installed, especially across multiple marketplaces. Making provenance visible in the menu makes skill selection predictable, makes plugin management actionable from the point of use, and removes the surprise of entries renaming themselves when unrelated plugins are installed.
Installation context
N/A
Additional context
The same inconsistency shows up in the skill list surfaced to the agent, where some entries are namespaced (
testing-automation:playwright-explore-website,repository-policy:repository-policy) and others are bare (engineering-standards,dependency-scanning) — so this is likely a single shared display-name rule rather than a menu-only concern.