sleep: plugin skills never resolve, because Claude Code records them as `plugin:skill`
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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
- Resolve
plugin:skillin 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 keeptoolbox:doc-truth; the proposal is staged and adopted asdoc-truth(adopt --skill doc-truth). If two plugins'doc-truthshow up in one night,skill_proposal_rowsalready refuses the duplicate. The resolver still never guesses between roots. - Same resolution, staged under an encoded name such as
toolbox--doc-truth, soadopt --skillnames stay unique across plugins.skill_proposal_rowsand_adopt_live_target_okwould need a new rule, since today they tie the staged name to the directory name. - 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-reviewwould resolve to~/.claude/skills/code-reviewand 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.
- 主要言語
- Python
- スター
- 18.2k
- フォーク
- 1.7k
- 平均マージ
- 4日 1時間
- マージ済み PR（30日）
- 10
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/SkillOpt のほかの issue
-
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
メンテナーはふだん 2 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 66/100
メンテナーはふだん 2 日以内に返信
-
Clarification on Rollout Timeouts, Inference Concurrency, and Their Impact on SkillOpt Evaluationオープン
難易度 4/5 3〜5日 初心者へのやさしさ 12/100
メンテナーはふだん 2 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 32/100
メンテナーはふだん 2 日以内に返信
-
skillopt-sleep: max_tokens_per_night is defaulted and documented but never enforced対応中かも @Thanatos9404 が 2 日前に担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
メンテナーはふだん 2 日以内に返信
microsoft/SkillOpt の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
ok-oldking/ok-wuthering-waves#1785 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
healthchecks/healthchecks#1349 ·
-
deployment release-lag
難易度 1/5 1時間未満 初心者へのやさしさ 68/100
nolte/kamerplanter#2374 ·
メンテナーはふだん 1 日以内に返信
-
bug v1 v2
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
modelcontextprotocol/python-sdk#3725 ·
メンテナーはふだん 1 日以内に返信
-
batchterms() drops queries without a similar() clause, misaligning results with inputs対応中かも @MohammadHijjawi97 が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
メンテナーはふだん 1 日以内に返信