Plugin skill silently dropped from /skills list despite "Installed N skills" confirming load
- 主要言語
- Shell
- スター
- 11.2k
- フォーク
- 1.9k
- 平均マージ
- 14時間 16分
- マージ済み PR(30日)
- 6
説明
## Describe the bug
Installing my plugin `shinyay/tokopt-skills` (9 skills + 2 agents) reports `Installed 9 skills`, and `copilot plugin list` confirms registration, but `/skills list` consistently shows only **8 of the 9 skills**. The missing skill is exactly the same one every time: `slim-apply`. The other 8 (`antipattern-scan`, `heavy-tail`, `hygiene-coach`, `prompt-anatomy`, `prompt-optimizer`, `slim-rewind`, `slim-suggest`, `token-audit`) appear correctly.
Verified:
- ✅ On disk: `~/.copilot/installed-plugins/_direct/shinyay--tokopt-skills/skills/slim-apply/SKILL.md` exists, well-formed (3452 B, ASCII frontmatter, no BOM)
- ✅ Install log says `Installed 9 skills` → loader sees it
- ❌ `/skills list` shows 8/9 → display/filter layer drops one
- ❌ Cwd-shadowing ruled out — same result from `/tmp` (outside repo) and from inside the repo
- ❌ Description length ruled out — slim-apply is 346 chars, well within range of visible skills (233–357 chars)
- ❌ Frontmatter formatting ruled out — identical structure (just `name:` + `description:`) to the 8 visible skills
Repro repo: https://github.com/shinyay/tokopt-skills (public, v0.1.0)
## Affected version
```
GitHub Copilot CLI 1.0.55-6.
```
## Steps to reproduce the behavior
```bash
copilot plugin install shinyay/tokopt-skills
# → "Plugin "tokopt-skills" installed successfully. Installed 9 skills."
copilot plugin list | grep tokopt
# → " • tokopt-skills (v0.1.0)"
ls ~/.copilot/installed-plugins/_direct/shinyay--tokopt-skills/skills/
# → 9 entries including slim-apply/
```
Then in an interactive `copilot` session:
```
/skills list
```
Count entries in the `plugin:` section that belong to `tokopt-skills`. Result: **8 entries, slim-apply missing**.
## Expected behavior
`/skills list` should show all 9 skills from the plugin, including `slim-apply`, matching the loader's `Installed 9 skills` count.
## Additional context
**Workarounds attempted (none worked):**
1. Uninstall + reinstall — same 8/9
2. Edited SKILL.md to rename `## DO NOT` → `## Guardrails` and `Destructive.` → `Note:` (in case a safety-keyword filter was matching) — still 8/9
3. Cleared a stale duplicate directory `_direct/tokopt-skills/` left over from an earlier local-path install — caused all 9 to disappear; re-established via symlink to recover the 8/9 state (separate-but-related quirk: the loader appears to resolve plugin dir by plugin-manifest `name`, not by `--` directory name)
**Description content of `slim-apply` (in case the filter is keyword-based):**
> Apply tokopt slim's compression IN-PLACE after the user has reviewed a slim-suggest preview AND explicitly approved. Writes compressed output back to disk with full safety: requires clean git tree, refuses symlinks, detects races. Use ONLY when the prior turn ran slim-suggest for the SAME single file. Never for first-pass analysis.
It is the only skill in the plugin whose description references another skill by name (`slim-suggest`, twice). Could `/skills list` be deduplicating or filtering based on cross-references in descriptions?
**Environment:**
- OS: Linux (WSL2, kernel 6.6.114.1-microsoft-standard)
- Arch: x86_64
- Node: v22.22.0
- Shell: bash
- Terminal: VS Code Insiders integrated terminal
**Related quirk (separate finding from the same investigation):**
When a plugin is installed from a GitHub repo shorthand (e.g., `copilot plugin install shinyay/tokopt-skills`), the plugin is unpacked to `~/.copilot/installed-plugins/_direct/shinyay--tokopt-skills/`, but `/skills list` only sees the skills if a `_direct//` directory (without the `--` prefix) is also present. Removing the orphan unprefixed directory leaves only the prefixed one, and the loader then loads 0 skills from the plugin, even though `copilot plugin list` still reports it as installed. A symlink `_direct/tokopt-skills -> shinyay--tokopt-skills` restores the loader. This suggests the plugin-name → directory resolution may not be handling the gh-shorthand naming convention consistently.
コントリビューションガイド
評価
この issue はまだ評価されていません。