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
Opencode not auto-detecting skills located in ~/.agents/skills/** #12741
/Users/[MYHOMEDIR]/.agents/skills/vercel-react-best-practices however is not being picked up. Am i missing something or is the docs out of date?
On opencode 1.1.40.
Is there something missing from my configuration, do I need to explicitly grant anything in opencode.jsonc. It feels like it's either not behaving as expected or the docs are incomplete?
Reacted by Hans L'Hoëst, Robert Felker, andreichernov, tancou, Joel Albert, Alexey Shevchenko, Nathan Brown, Josh Dix, Marius Merschformann, Vasek Codey Vlcek and 5 more
It appears the feature has already been implemented in #11842 (merged), so if auto-detection isn't working as expected in your version, this may be a bug rather than a missing feature. Please check if you're running a recent version (v1.1.40 or later based on your message) and whether the feature is working correctly. If the problem persists, this might be worth reporting as a separate bug issue.
Feel free to ignore if this doesn't match your specific case.
I hit this with project-level .agents/skills/ (not global), and traced it to the source.
In packages/opencode/src/skill/skill.ts, project-level external skill dirs are scanned via:
```ts
for await (const root of Filesystem.up({
targets: EXTERNAL_DIRS,
start: Instance.directory,
stop: Instance.worktree,
})) {
await scanExternal(root, "project")
}
```
When the working directory is the worktree root (i.e. Instance.directory === Instance.worktree), Filesystem.up() produces an empty range — the root itself is excluded. So .agents/skills/ at the repo root is never scanned.
The global path (using Global.Path.home) works fine because it doesn't go through Filesystem.up. This explains why ~/.agents/skills/ (issue #12741 title) would also fail if Filesystem.up has the same off-by-one for the home directory case — but in the global branch it's just a direct path.join, so that one should work. The project-level branch is the broken one.
The fix would be to make Filesystem.up inclusive of the start directory, or to explicitly add Instance.worktree as a candidate when scanning project-level external dirs.
OpenCode version: whatever is running locally (identified via source inspection on the dev branch).
Correction to my earlier comment — I traced through the code more carefully and Filesystem.up()does include the start directory when start === stop. The glob scan also works correctly in isolation (Glob.scan('skills/**/SKILL.md', { cwd: '.agents' }) returns the expected SKILL.md files).
So the discovery pipeline itself looks correct on paper. I'm still experiencing the symptom (project-level .agents/skills/ skills not appearing in the <available_skills> list), but I haven't been able to pin down the actual root cause yet. It may be session/context-timing related — e.g., skill state being initialized before the Instance context is fully set up, or a caching issue where the skill list is computed once and not refreshed.
Update: this might just be stale cache, not broken discovery.
After an embarrassing amount of source-diving (tracing Filesystem.up, Instance.provide, State.create, checking env flags, reading logs, writing diagnostic scripts...), we finally realized the actual issue: Skill.state is a lazy-init, permanently-cached async closure. It initializes once per opencode process and never refreshes.
So if you:
Launch opencode
Add .agents/skills/foo/SKILL.md (perhaps with the help of an agent)
Start a /new session expecting a fresh environment
...the skill list is still cached from step 1. Even /new does not re-scan. You have to fully restart opencode.
This could explain the original report and the "console fails, desktop works" comment — if you happened to restart the desktop app but not the CLI, you'd see exactly that pattern.
The real bug is arguably that Skill.state should be invalidated on filesystem changes or at least on new sessions, rather than cached for the entire process lifetime. But it's not a discovery logic bug — the scanning code is correct.
Apologies for the earlier noise. We spent hours convinced the plumbing was broken when we just needed to restart the program.
I'm actually seeing the same thing - skills in .agents ignored, even if I restart OC. mv .agents .opencode does solve the problem, so it;s not an issue with the skill file.
Yes. I am seeing this in the package level .opencode/skills/ directory on 1.3.15.
Not using any particularly complex configurations either. Not a blocker.
Activity
github-actions commentedon Feb 8, 2026
This issue might be a duplicate of existing issues. Please check:
.agents/skills/#10986: [FEATURE]: Support standard skills location at.agents/skills/- This feature request is about supporting the standard.agents/skills/directory.agents/skills/directoriesIt appears the feature has already been implemented in #11842 (merged), so if auto-detection isn't working as expected in your version, this may be a bug rather than a missing feature. Please check if you're running a recent version (v1.1.40 or later based on your message) and whether the feature is working correctly. If the problem persists, this might be worth reporting as a separate bug issue.
Feel free to ignore if this doesn't match your specific case.
shihyuho commentedon Feb 12, 2026
In the console version 1.1.59, it also failed to load, but it works fine in the desktop version.
rumeysakicali commentedon Feb 25, 2026
Are the files here detected automatically?
rndmcnlly commentedon Feb 28, 2026
I hit this with project-level
.agents/skills/(not global), and traced it to the source.In
packages/opencode/src/skill/skill.ts, project-level external skill dirs are scanned via:```ts
for await (const root of Filesystem.up({
targets: EXTERNAL_DIRS,
start: Instance.directory,
stop: Instance.worktree,
})) {
await scanExternal(root, "project")
}
```
When the working directory is the worktree root (i.e.
Instance.directory === Instance.worktree),Filesystem.up()produces an empty range — the root itself is excluded. So.agents/skills/at the repo root is never scanned.The global path (using
Global.Path.home) works fine because it doesn't go throughFilesystem.up. This explains why~/.agents/skills/(issue #12741 title) would also fail ifFilesystem.uphas the same off-by-one for the home directory case — but in the global branch it's just a directpath.join, so that one should work. The project-level branch is the broken one.The fix would be to make
Filesystem.upinclusive of thestartdirectory, or to explicitly addInstance.worktreeas a candidate when scanning project-level external dirs.OpenCode version: whatever is running locally (identified via source inspection on the
devbranch).rndmcnlly commentedon Feb 28, 2026
Correction to my earlier comment — I traced through the code more carefully and
Filesystem.up()does include the start directory whenstart === stop. The glob scan also works correctly in isolation (Glob.scan('skills/**/SKILL.md', { cwd: '.agents' })returns the expected SKILL.md files).So the discovery pipeline itself looks correct on paper. I'm still experiencing the symptom (project-level
.agents/skills/skills not appearing in the<available_skills>list), but I haven't been able to pin down the actual root cause yet. It may be session/context-timing related — e.g., skill state being initialized before the Instance context is fully set up, or a caching issue where the skill list is computed once and not refreshed.Apologies for the premature diagnosis.
rndmcnlly commentedon Mar 1, 2026
Update: this might just be stale cache, not broken discovery.
After an embarrassing amount of source-diving (tracing
Filesystem.up,Instance.provide,State.create, checking env flags, reading logs, writing diagnostic scripts...), we finally realized the actual issue:Skill.stateis a lazy-init, permanently-cached async closure. It initializes once per opencode process and never refreshes.So if you:
.agents/skills/foo/SKILL.md(perhaps with the help of an agent)/newsession expecting a fresh environment...the skill list is still cached from step 1. Even
/newdoes not re-scan. You have to fully restart opencode.This could explain the original report and the "console fails, desktop works" comment — if you happened to restart the desktop app but not the CLI, you'd see exactly that pattern.
The real bug is arguably that
Skill.stateshould be invalidated on filesystem changes or at least on new sessions, rather than cached for the entire process lifetime. But it's not a discovery logic bug — the scanning code is correct.Apologies for the earlier noise. We spent hours convinced the plumbing was broken when we just needed to restart the program.
xl0 commentedon Mar 25, 2026
I'm actually seeing the same thing - skills in .agents ignored, even if I restart OC. mv .agents .opencode does solve the problem, so it;s not an issue with the skill file.
diegohb commentedon Mar 26, 2026
I've been using skills.path[] property on opencode.json config file as workaround.. i think it's working ?
xl0 commentedon Mar 26, 2026
It is a workarounf. The documentations says it should work without a workaround: https://opencode.ai/docs/skills/#place-files
FelikZ commentedon Mar 30, 2026
I do not know what yet but yes it is broken. v1.3.0 still.
If I just run
ln -s .agents .opencodeit then magically start to work for this directory.Top level also does not work anymore (used to work)
~/.agents/skillsand it get healed the same way. So it avoids.agentsfor some reason.UPD: for me the reason it does not work
export OPENCODE_DISABLE_CLAUDE_CODE=1- this seem disables.agentsdiscovery alongside with.claude... @jayairdavidbernat commentedon Apr 5, 2026
Yes. I am seeing this in the package level
.opencode/skills/directory on 1.3.15.Not using any particularly complex configurations either. Not a blocker.
patacca commentedon Apr 8, 2026
This should really be avoided. It's a terrible behavior
lirc571 commentedon Apr 17, 2026
#12432
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.