Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

sleep: plugin skills never resolve, because Claude Code records them as `plugin:skill`

Abierto
#316 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
tooling

Línea de trabajo

Start in harvest._skill_names_from_content and resolve_skill, then follow skill_search_roots to see how plugin roots are keyed. Staging and adoption also need reading: staging._safe_skill_name, skill_proposal_rows, and _adopt_live_target_ok. The naming choice is still open, so ask the maintainers which option to take before writing code. Done means a plugin:skill name resolves only in its own plugin root, and test_sleep_skill_harvest.py and the resolver tests pass.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

Claude Code records a plugin skill's Skill call with the plugin-qualified name, for example {"skill": "toolbox:doc-truth"}. harvest._skill_names_from_content keeps the name as written (test_sleep_skill_harvest.py pins Example-Skill:v2), so the fan-out looks for a skill called toolbox:doc-truth.

resolve_skill then looks for a directory with that literal name in every root. The plugin roots that skill_search_roots discovers (<cache>/<marketplace>/<plugin>/<version>/skills, from #185 and 109bafb) contain doc-truth/, so a plugin skill from a real transcript always comes back missing. The resolver tests use bare names in plugin roots (chrome-devtools under chrome-devtools-mcp/<version>/skills), which is not what Claude Code writes.

Repro

On main at 343db22, with a claude_home holding plugins/cache/jay-skills/toolbox/0.6.4/skills/doc-truth/SKILL.md:

roots = skill_search_roots(cfg)                  # includes .../toolbox/0.6.4/skills
resolve_skill("toolbox:doc-truth", roots).status  # 'missing'
resolve_skill("doc-truth", roots).status          # 'found'
_skill_names_from_content([{"type": "tool_use", "name": "Skill",
                            "input": {"skill": "toolbox:doc-truth"}}])  # ['toolbox:doc-truth']

End to end on 79124b3 (skill_resolver.py is unchanged since), a dry-run --source claude with multi_skill_fanout on a real session reported the group as skipped, "no SKILL.md for this skill in the configured skill roots". --skill-root can't work around it, because no directory has a colon in its name.

On one machine's Claude Code history: 264 Skill calls, 138 of them plugin-qualified, and 129 of those have <skill>/SKILL.md in the root the resolver picks for that plugin. None of the 138 resolve today.

Why it needs more than a resolver change

If the name did resolve, staging would still refuse it. staging._safe_skill_name rejects : because the name becomes proposed_SKILL.<name>.md and Windows can't store it. skill_proposal_rows and _adopt_live_target_ok also require the live file's parent directory to equal the skill name. So the fix depends on what name a plugin skill is staged and adopted under, and I'd rather you pick that.

Options

  1. Resolve plugin:skill in that plugin's root only, and stage under the directory name. Return the plugin roots keyed by plugin, send a qualified name only to its plugin's root, and send a bare name to every root as today. Reports keep toolbox:doc-truth; the proposal is staged and adopted as doc-truth (adopt --skill doc-truth). If two plugins' doc-truth show up in one night, skill_proposal_rows already refuses the duplicate. The resolver still never guesses between roots.
  2. Same resolution, staged under an encoded name such as toolbox--doc-truth, so adopt --skill names stay unique across plugins. skill_proposal_rows and _adopt_live_target_ok would need a new rule, since today they tie the staged name to the directory name.
  3. Strip the prefix at harvest and resolve the bare name everywhere. This is the smallest change, but a bare name can then match an unrelated skill. If a plugin's copy isn't in the cache, engineering:code-review would resolve to ~/.claude/skills/code-review and the proposal would be staged against that file. I wouldn't do this one.

I lean to option 1. Happy to send a PR with tests once you've picked the naming: a qualified name resolves only in its plugin's root, a same-named skill elsewhere is ignored, staging and adopt --skill work under the bare name, and duplicate bare names across plugins are still refused.

Lenguaje dominante
Python
Estrellas
18.2k
Forks
1.7k
Merge medio
4 d 1 h
PR fusionados (30 d)
10

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/SkillOpt

Todos los issues de microsoft/SkillOpt

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.