Skill duplicate roots can change available_skills across restarts

[ualtinok]

Description

When the same skill name exists in more than one discovered skill root, OpenCode can pick a different root across process starts.

The final <available_skills> block is sorted by skill name, but duplicate resolution happens earlier while loading matching SKILL.md files. Duplicate names currently use last-writer-wins, and the loader processes matches concurrently, so the winning location can depend on file I/O completion order.

This makes the system prompt bytes change after a restart even when no skill files changed. For users with prompt caching, that causes an unnecessary one-time cache miss on the first turn after restart.

Plugins

N/A

OpenCode version

Current dev

Steps to reproduce

1. Create the same skill name in two discovered roots, for example:
   • .claude/skills/example/SKILL.md
   • .opencode/skills/example/SKILL.md
2. Start OpenCode and inspect the verbose <available_skills> system prompt entry for example.
3. Restart OpenCode and inspect the same entry again.

The selected <location> should be stable according to discovery precedence. Instead, duplicate winners can vary because skill files are loaded concurrently and duplicate names overwrite each other as each load completes.

Screenshot and/or share link

N/A

Operating System

macOS

Terminal

Any

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Skill enumeration is non-deterministic when the same skill is reachable through multiple discovery roots #29950: Describes the exact same root cause — non-deterministic skill location resolution when the same skill name is reachable through multiple discovery roots (e.g. .claude/skills/ and .agents/skills/), causing per-session system prompt byte changes and breaking prompt cache hit rates. It also proposes the same fix (deduplicate by basename at discovery time with a canonical root preference).

If your issue adds new context or a different angle not covered there, please note that in a comment on #29950 or here.