You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SKILL reference not update after edit the SKILL #19050
The SKILL reference will not update after edit the SKILL. Until restart the opencode client (TUI or Desktop).
Plugins
No response
OpenCode version
1.3.2
Steps to reproduce
create a skill in project space.
open the opencode (TUI or Desktop)
It will load skill from project space. I can use '/skill-name' to reference the skill.
when I edit the skill and save (add oneline label 'test1'). It will not load the skill from disk. And we can see the reference by '/skill-name' is still old version. (without 'test1')
It will not solve by open new session. Just restart the opencode.
The problem is that sometimes models will ask that the reference is different with script. And maybe revert my edit. Because model think the reference is new version.
I took a stab at this with draft PR #19136, but after manual testing I found the fix doesn't actually solve the problem for the default configuration.
What the PR does: Adds a Skill.invalidate() method that clears the cached skills, and wires it to FileWatcher.Event.Updated so that editing a SKILL.md triggers a cache reload. The Command cache also rebuilds when skills are invalidated.
Why it doesn't work in practice:FileWatcher only watches Instance.directory when OPENCODE_EXPERIMENTAL_FILEWATCHER=true (see src/file/watcher.ts:123). Without that flag, only .git/HEAD is watched, so FileWatcher.Event.Updated never fires for SKILL.md changes. Most users won't have the experimental flag enabled.
There's also a secondary gap: even with the flag on, the watcher only covers CWD. Skills loaded from parent directories (monorepo .claude/skills/) or global directories (~/.claude/skills/) wouldn't trigger invalidation.
The cache invalidation logic itself works — Skill.invalidate() correctly clears the cache and the next Skill.all()/Skill.get() call re-reads from disk. All automated tests pass. The gap is in how invalidation gets triggered.
Possible approaches a maintainer might consider:
Dedicated watcher for skill directories — After the initial skill load, set up fs.watch or parcel watcher subscriptions on just the known skill directories (state.dirs). Independent of the experimental flag.
Poll-based mtime checks — On each ensure() call, stat the loaded SKILL.md files and invalidate if any mtime has changed. Simple but adds disk I/O per call.
Broaden the experimental watcher scope — Extend FileWatcher to also cover skill directories when enabled, and eventually promote it out of experimental.
Happy to update the PR if a maintainer has a preferred direction.
Is the skill cache even useful? I doubt the increased memory usage and complexity is worth it.
What extra information does opencode have about skill usage patterns that can make it do a better job than whatever LRU approximation the OS is already doing for us?
Activity
fix(skill): invalidate skill cache when SKILL.md files change on disk
jwm4 commentedon Mar 25, 2026
I took a stab at this with draft PR #19136, but after manual testing I found the fix doesn't actually solve the problem for the default configuration.
What the PR does: Adds a
Skill.invalidate()method that clears the cached skills, and wires it toFileWatcher.Event.Updatedso that editing a SKILL.md triggers a cache reload. The Command cache also rebuilds when skills are invalidated.Why it doesn't work in practice:
FileWatcheronly watchesInstance.directorywhenOPENCODE_EXPERIMENTAL_FILEWATCHER=true(seesrc/file/watcher.ts:123). Without that flag, only.git/HEADis watched, soFileWatcher.Event.Updatednever fires for SKILL.md changes. Most users won't have the experimental flag enabled.There's also a secondary gap: even with the flag on, the watcher only covers CWD. Skills loaded from parent directories (monorepo
.claude/skills/) or global directories (~/.claude/skills/) wouldn't trigger invalidation.The cache invalidation logic itself works —
Skill.invalidate()correctly clears the cache and the nextSkill.all()/Skill.get()call re-reads from disk. All automated tests pass. The gap is in how invalidation gets triggered.Possible approaches a maintainer might consider:
fs.watchor parcel watcher subscriptions on just the known skill directories (state.dirs). Independent of the experimental flag.ensure()call,statthe loaded SKILL.md files and invalidate if any mtime has changed. Simple but adds disk I/O per call.FileWatcherto also cover skill directories when enabled, and eventually promote it out of experimental.Happy to update the PR if a maintainer has a preferred direction.
abread commentedon Apr 10, 2026
Is the skill cache even useful? I doubt the increased memory usage and complexity is worth it.
What extra information does opencode have about skill usage patterns that can make it do a better job than whatever LRU approximation the OS is already doing for us?
github-actions commentedon Jul 3, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.