Support for &#34;Skills&#34; #2141

https://www.anthropic.com/news/skills

Originally created by @tobias-walle on GitHub (Oct 17, 2025).

Originally assigned to: @thdxr on GitHub.

Yesterday Claude Code released a new feature called "Skills", that basically allows the user to define prompts, that are lazily loaded by the Agent when needed.

It would be nice to see a similar feature in OpenCode.

Originally created by @tobias-walle on GitHub (Oct 17, 2025). Originally assigned to: @thdxr on GitHub. Yesterday Claude Code released a new feature called "Skills", that basically allows the user to define prompts, that are lazily loaded by the Agent when needed. [https://www.anthropic.com/news/skills](https://www.anthropic.com/news/skills) It would be nice to see a similar feature in OpenCode.

yindo closed this issue

yindo commented

@github-actions[bot] commented on GitHub (Oct 17, 2025):

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

#3195: Dynamic system prompts for custom agents - discusses dynamically generating system prompts that can be lazily loaded, which is conceptually similar to the Skills feature for loading prompts when needed
#12: Custom system prompt - requests custom system prompt functionality

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Oct 17, 2025): This issue might be a duplicate of existing issues. Please check: - #3195: [Dynamic system prompts for custom agents](https://github.com/sst/opencode/issues/3195) - discusses dynamically generating system prompts that can be lazily loaded, which is conceptually similar to the Skills feature for loading prompts when needed - #12: [Custom system prompt](https://github.com/sst/opencode/issues/12) - requests custom system prompt functionality Feel free to ignore if none of these address your specific case.

yindo commented

@tobias-walle commented on GitHub (Oct 17, 2025):

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

Dynamic system prompts for custom agents #3195: Dynamic system prompts for custom agents - discusses dynamically generating system prompts that can be lazily loaded, which is conceptually similar to the Skills feature for loading prompts when needed

status messages and logging need work #12: Custom system prompt - requests custom system prompt functionality

Feel free to ignore if none of these address your specific case.

Not a duplicate, as this issue is refereeing to handling dynamic content in the system prompt (by running scripts), but these are always included. With skills the agent decides then it wants to include a specific "Skill".
Also not a duplicate

@tobias-walle commented on GitHub (Oct 17, 2025): > This issue might be a duplicate of existing issues. Please check: > > * [Dynamic system prompts for custom agents #3195](https://github.com/sst/opencode/issues/3195): [Dynamic system prompts for custom agents](https://github.com/sst/opencode/issues/3195) - discusses dynamically generating system prompts that can be lazily loaded, which is conceptually similar to the Skills feature for loading prompts when needed > * [status messages and logging need work #12](https://github.com/sst/opencode/issues/12): [Custom system prompt](https://github.com/sst/opencode/issues/12) - requests custom system prompt functionality > > Feel free to ignore if none of these address your specific case. 1) Not a duplicate, as this issue is refereeing to handling dynamic content in the system prompt (by running scripts), but these are always included. With skills the agent decides then it wants to include a specific "Skill". 2) Also not a duplicate

yindo commented

@rekram1-node commented on GitHub (Oct 17, 2025):

Sorry about that @tobias-walle the bot is a little overeager, I think ill make it reword it's comments so that people know they dont need to respond to it.

Every issue opened is seen by someone on the team but the bot helps find duplicates (sometimes haha)

@rekram1-node commented on GitHub (Oct 17, 2025): Sorry about that @tobias-walle the bot is a little overeager, I think ill make it reword it's comments so that people know they dont need to respond to it. Every issue opened is seen by someone on the team but the bot helps find duplicates (sometimes haha)

yindo commented

@tobias-walle commented on GitHub (Oct 17, 2025):

No worries 😄 As I wasn't entirely sure about the first one, I checked and just wanted to share my findings.

Overall, I really like the bot, as it gives me some confidence that my issue is actually unique and that I didn't miss a duplicate.

@tobias-walle commented on GitHub (Oct 17, 2025): No worries 😄 As I wasn't entirely sure about the first one, I checked and just wanted to share my findings. Overall, I really like the bot, as it gives me some confidence that my issue is actually unique and that I didn't miss a duplicate.

yindo commented

@kziemski commented on GitHub (Oct 17, 2025):

Adding more to this as this guy has some interesting ideas on extensions to skills:
https://github.com/obra/superpowers
https://github.com/obra/superpowers-skills
https://blog.fsck.com/2025/10/09/superpowers/

@kziemski commented on GitHub (Oct 17, 2025): Adding more to this as this guy has some interesting ideas on extensions to skills: [https://github.com/obra/superpowers](https://github.com/obra/superpowers) [https://github.com/obra/superpowers-skills](https://github.com/obra/superpowers-skills) [https://blog.fsck.com/2025/10/09/superpowers/](https://blog.fsck.com/2025/10/09/superpowers/)

yindo commented

@rekram1-node commented on GitHub (Oct 17, 2025):

I think everything skills offers is already possible right, or at least most of it, just define a custom tool and return markdown from it

I mean that's like 99% of it I think

@rekram1-node commented on GitHub (Oct 17, 2025): I think everything skills offers is already possible right, or at least most of it, just define a [custom tool](https://opencode.ai/docs/custom-tools/) and return markdown from it I mean that's like 99% of it I think

yindo commented

@kziemski commented on GitHub (Oct 17, 2025):

I think everything skills offers is already possible right, or at least most of it, just define a custom tool and return markdown from it

I mean that's like 99% of it I think

ya that's not surprising i'm just wondering if it could be the starting point for more in opencode.
the skill sharing in the superpowers repo could be interesting.

@kziemski commented on GitHub (Oct 17, 2025): > I think everything skills offers is already possible right, or at least most of it, just define a [custom tool](https://opencode.ai/docs/custom-tools/) and return markdown from it > > I mean that's like 99% of it I think ya that's not surprising i'm just wondering if it could be the starting point for more in opencode. the skill sharing in the superpowers repo could be interesting.

yindo commented

@malhashemi commented on GitHub (Oct 17, 2025):

Hey everyone! 👋

I just published an npm plugin that implements Anthropic's Skills Specification for OpenCode!

📦 npm package: https://www.npmjs.com/package/opencode-skills
📄 GitHub repo: https://github.com/malhashemi/opencode-skills

Installation (super simple!)

Add one line to your opencode.json or ~/.config/opencode/opencode.json:

{
  "plugin": ["opencode-skills"]
}

That's it! OpenCode will automatically install the plugin from npm on next startup. No npm install needed.

What it does

This plugin provides one-to-one parity with Anthropic's Agent Skills Specification (v1.0), with the added bonus of supporting nested skills (e.g., skills/tools/analyzer/SKILL.md → skills_tools_analyzer) - a feature that Anthropic doesn't support yet.

How it works

The plugin scans your .opencode/skills/ directory (and ~/.opencode/skills/ for global skills), discovers all SKILL.md files, validates them against the spec, and exposes SKILL.md using its meta data as a callable tool (e.g., skills_my_skill). I'm assuming Claude Code implements this similarly, though I could be wrong here and something fancier is running under the hood

Quick Start

Add plugin to opencode.json (see above)
Restart OpenCode
Create a skill:

mkdir -p .opencode/skills/my-skill

Add a SKILL.md file:

---
name: my-skill
description: A custom skill that helps with specific tasks
---

# My Skill

Your skill instructions here...

Restart OpenCode again - your skill is now available as skills_my_skill!

Integration with OpenCode

Since skills are just regular OpenCode tools, they benefit from OpenCode's existing tool management:

✅ Can be disabled globally via opencode.json
✅ Can be enabled/disabled per-agent in agent frontmatter
✅ Inherit all of OpenCode's permission system

Testing

I've tested this with Anthropic's official skills on Claude Sonnet 4.5 with max thinking, and they work beautifully. You may notice that the tool call return some instructions to the LLM about path management, I found that without it the agent gets lost searching for files mentioned in the SKILLS.md.

Note on Tool Restrictions

One difference from Anthropic's implementation: I couldn't find a way to implement skill-level tool restrictions (the allowed-tools field that's available in Claude Code). However, I don't think this is necessary in OpenCode since you'll typically pair skills with specific agents, and agents already have their own fine-grained tool permissions. This actually gives you more control - you can configure which tools are available at the agent level rather than embedding it in the skill itself.

Hope this helps the community! Let me know if anyone has feedback or suggestions. 🎉

For full documentation, check out the GitHub repo.

Feel free to PR if you have some valuable improvements

@thdxr and @rekram1-node , I believe you mentioned you are going to work on revamping the custom tools in the upcoming TUI. Should I expect a breaking change?

@malhashemi commented on GitHub (Oct 17, 2025): Hey everyone! 👋 I just published an npm plugin that implements Anthropic's Skills Specification for OpenCode! **📦 npm package:** https://www.npmjs.com/package/opencode-skills **📄 GitHub repo:** https://github.com/malhashemi/opencode-skills ## Installation (super simple!) Add one line to your `opencode.json` or `~/.config/opencode/opencode.json`: ```json { "plugin": ["opencode-skills"] } ``` That's it! OpenCode will automatically install the plugin from npm on next startup. No `npm install` needed. ## What it does This plugin provides **one-to-one parity with Anthropic's Agent Skills Specification (v1.0)**, with the added bonus of supporting **nested skills** (e.g., `skills/tools/analyzer/SKILL.md` → `skills_tools_analyzer`) - a feature that Anthropic doesn't support yet. ## How it works The plugin scans your `.opencode/skills/` directory (and `~/.opencode/skills/` for global skills), discovers all `SKILL.md` files, validates them against the spec, and exposes `SKILL.md` using its meta data as a callable tool (e.g., `skills_my_skill`). I'm assuming Claude Code implements this similarly, though I could be wrong here and something fancier is running under the hood ## Quick Start 1. Add plugin to `opencode.json` (see above) 2. Restart OpenCode 3. Create a skill: ```bash mkdir -p .opencode/skills/my-skill ``` 4. Add a `SKILL.md` file: ```markdown --- name: my-skill description: A custom skill that helps with specific tasks --- # My Skill Your skill instructions here... ``` 5. Restart OpenCode again - your skill is now available as `skills_my_skill`! ## Integration with OpenCode Since skills are just regular OpenCode tools, they benefit from OpenCode's existing tool management: - ✅ Can be disabled globally via `opencode.json` - ✅ Can be enabled/disabled per-agent in agent frontmatter - ✅ Inherit all of OpenCode's permission system ## Testing I've tested this with [Anthropic's official skills](https://github.com/anthropics/skills) on **Claude Sonnet 4.5 with max thinking**, and they work beautifully. You may notice that the tool call return some instructions to the LLM about path management, I found that without it the agent gets lost searching for files mentioned in the SKILLS.md. ## Note on Tool Restrictions One difference from Anthropic's implementation: I couldn't find a way to implement skill-level tool restrictions (the `allowed-tools` field that's available in Claude Code). However, I don't think this is necessary in OpenCode since you'll typically pair skills with specific agents, and agents already have their own fine-grained tool permissions. This actually gives you more control - you can configure which tools are available at the agent level rather than embedding it in the skill itself. --- Hope this helps the community! Let me know if anyone has feedback or suggestions. 🎉 For full documentation, check out the [GitHub repo](https://github.com/malhashemi/opencode-skills). Feel free to PR if you have some valuable improvements --- @thdxr and @rekram1-node , I believe you mentioned you are going to work on revamping the custom tools in the upcoming TUI. Should I expect a breaking change?

yindo commented

@ihabwahbi commented on GitHub (Oct 17, 2025):

@malhashemi I'll test your solution seems a very straightforward and easy way to integrate Skills into opencode

@ihabwahbi commented on GitHub (Oct 17, 2025): @malhashemi I'll test your solution seems a very straightforward and easy way to integrate Skills into opencode

yindo commented

@rekram1-node commented on GitHub (Oct 18, 2025):

@malhashemi I dont think there should be any breaking changes soon, but if you run into any issues just lmk.

We do version things with specific version bumps if breaking tho

@rekram1-node commented on GitHub (Oct 18, 2025): @malhashemi I dont think there should be any breaking changes soon, but if you run into any issues just lmk. We do version things with specific version bumps if breaking tho

yindo commented

@tobias-walle commented on GitHub (Oct 18, 2025):

Great idea with the plugin! I think this is already quite a good solution.

I think an official solution would still be valuable to have a common standard, but this doesn't has much priority (considering the big refactoring you are currently working on)

@tobias-walle commented on GitHub (Oct 18, 2025): Great idea with the plugin! I think this is already quite a good solution. I think an official solution would still be valuable to have a common standard, but this doesn't has much priority (considering the big refactoring you are currently working on)

yindo commented

@kziemski commented on GitHub (Oct 20, 2025):

@tobias-walle @malhashemi @rekram1-node
I'm wondering if you guys had taken a look at what this guy had done on the CC side https://blog.fsck.com/2025/10/09/superpowers/

i'm wondering if opencode taking the approach of public skills repo or taking the approach of openweb-ui's public search for prompts,functions ie for community sharing would be something that could really bring some adoption for an official version of skills support

@kziemski commented on GitHub (Oct 20, 2025): @tobias-walle @malhashemi @rekram1-node I'm wondering if you guys had taken a look at what this guy had done on the CC side https://blog.fsck.com/2025/10/09/superpowers/ i'm wondering if opencode taking the approach of public skills repo or taking the approach of openweb-ui's public search for prompts,functions ie for community sharing would be something that could really bring some adoption for an official version of skills support

yindo commented

@rekram1-node commented on GitHub (Oct 20, 2025):

i think we are going to watch them play out a little more before doing anything major, we have some higher priority items currently to tackle but thanks for the callout

@rekram1-node commented on GitHub (Oct 20, 2025): i think we are going to watch them play out a little more before doing anything major, we have some higher priority items currently to tackle but thanks for the callout

yindo commented

@ferdinandyb commented on GitHub (Oct 24, 2025):

@malhashemi Can you version-pin the plugin somehow?

@ferdinandyb commented on GitHub (Oct 24, 2025): @malhashemi Can you version-pin the plugin somehow?

yindo commented

@malhashemi commented on GitHub (Oct 24, 2025):

@malhashemi Can you version-pin the plugin somehow?

@ferdinandyb yes you can, inside your opencode.json :

{ "plugin": ["opencode-skills@0.0.3"] }

@malhashemi commented on GitHub (Oct 24, 2025): > @malhashemi Can you version-pin the plugin somehow? @ferdinandyb yes you can, inside your `opencode.json` : ```json { "plugin": ["opencode-skills@0.0.3"] } ```

yindo commented

@malhashemi commented on GitHub (Oct 26, 2025):

Just released v0.1.0 that uses the new noReply parameter from #3433 to deliver SKILL.md as a user message rather than a tool response (This should now survives purging), also followed Anthropic less verbose path resolution style, let me know if this causes any issue in paths resolution. Make sure to update OpenCode to the latest version.

@malhashemi commented on GitHub (Oct 26, 2025): Just released [v0.1.0](https://github.com/malhashemi/opencode-skills) that uses the new `noReply` parameter from #3433 to deliver SKILL.md as a user message rather than a tool response (This should now survives purging), also followed Anthropic less verbose path resolution style, let me know if this causes any issue in paths resolution. Make sure to update OpenCode to the latest version.

yindo commented

https://github.com/numman-ali/openskills

@numman-ali commented on GitHub (Oct 30, 2025):

Skills are extremely easy to implement

You can use my lightweight approach which aligns exactly with Anthropics, only difference is instead of a tool, it's a cli bash call - openskills read

Other than that, its injecting into the system prompt the list of skills available

OpenSkills supports .claude globally and also in .agent folders for advanced users

Give me 50 likes, and approval from OpenCode team, and ill open a native PR

@numman-ali commented on GitHub (Oct 30, 2025): Skills are extremely easy to implement You can use my lightweight approach which aligns exactly with Anthropics, only difference is instead of a tool, it's a cli bash call - openskills read Other than that, its injecting into the system prompt the list of skills available OpenSkills supports .claude globally and also in .agent folders for advanced users https://github.com/numman-ali/openskills Give me 50 likes, and approval from OpenCode team, and ill open a native PR

yindo commented

@ihabwahbi commented on GitHub (Oct 31, 2025):

To the opencode maintainers (@rekram1-node): As you consider an official implementation, I'd strongly argue against an approach that just injects all available skills into the system prompt. That would undermine opencode’s core feature of fine-grained, per-agent access control. A native implementation should treat each skill as its own distinct, manageable tool (just like MCPs and custom tools), so we can enable/disable specific skills per agent.

With that in mind, as a heavy user of Skills on cursor, opencode, and claude code, here’s what I’ve found working with both the openskills and opencode-skills plugins. My findings strongly favor one model for the opencode ecosystem.

Discovery
- claude code discovers all skills in the skills folder automatically and injects them into the system prompt.
- openskills requires running the CLI (openskills sync) every time I add a skill to get it discovered, and relies on AGENTS.md to make skills discoverable.
- opencode-skills automatically discovers my skills on startup, just like opencode does for MCPs and custom tools.
Access Control (The Most Important Point for opencode)
- claude code: all skills are automatically exposed to your primary agent as well as all subagents (which I don’t like).
- openskills: By relying on AGENTS.md, it presents an all-or-nothing list to the agent, completely bypassing opencode's native, per-tool permission system.
- opencode-skills: (This is the key) It follows opencode’s model perfectly. Each skill becomes a native tool (e.g., skills_my_skill) that I can control at the agent level. This has become the main reason opencode has overtaken claude code as my primary daily driver.
Invocation
- claude code has a single tool that, when invoked, serves the required skill as a user message. I like this because it has maximum persistence compared to tool responses or file reads that may get purged. (@rekram1-node can you clarify whether file reads get purged? I don’t have a deep understanding of how purging works in opencode.)
- openskills relies on the agent running a CLI command (openskills read <name>) and parsing stdout.
- opencode-skills follows the claude code invocation pattern: it's a native tool that injects the SKILL.md content as a noReply (user) message, which is the ideal way to handle persistence.
Availability
- openskills is very helpful if you use other tools in addition to opencode, since it works with anything that reads AGENTS.md.
- opencode-skills is clearly opencode-specific, which is perfect for what it does.

Thanks to both @malhashemi and @numman-ali for giving us access to skills in opencode at such unprecedented speed, literally in less than 48 hours after Anthropic released the feature, we have parity in opencode. Great community!

@ihabwahbi commented on GitHub (Oct 31, 2025): To the `opencode` maintainers (@rekram1-node): As you consider an official implementation, I'd strongly argue against an approach that just injects all available skills into the system prompt. That would undermine `opencode`’s core feature of fine-grained, per-agent access control. A native implementation should treat each skill as its own distinct, manageable tool (just like MCPs and custom tools), so we can enable/disable specific skills per agent. With that in mind, as a heavy user of Skills on `cursor`, `opencode`, and `claude code`, here’s what I’ve found working with both the `openskills` and `opencode-skills` plugins. My findings strongly favor one model *for the `opencode` ecosystem*. - **Discovery** - `claude code` discovers all skills in the `skills` folder automatically and injects them into the system prompt. - `openskills` requires running the CLI (`openskills sync`) every time I add a skill to get it discovered, and relies on `AGENTS.md` to make skills discoverable. - `opencode-skills` automatically discovers my skills on startup, just like `opencode` does for MCPs and custom tools. - **Access Control (The Most Important Point for `opencode`)** - `claude code`: all skills are automatically exposed to your primary agent as well as all subagents (which I don’t like). - `openskills`: By relying on `AGENTS.md`, it presents an all-or-nothing list to the agent, completely bypassing `opencode`'s native, per-tool permission system. - `opencode-skills`: **(This is the key)** It follows `opencode`’s model perfectly. Each skill becomes a *native tool* (e.g., `skills_my_skill`) that I can control at the agent level. This has become the main reason `opencode` has overtaken `claude code` as my primary daily driver. - **Invocation** - `claude code` has a single tool that, when invoked, serves the required skill as a user message. I like this because it has maximum persistence compared to tool responses or file reads that may get purged. (@rekram1-node can you clarify whether file reads get purged? I don’t have a deep understanding of how purging works in `opencode`.) - `openskills` relies on the agent running a CLI command (`openskills read <name>`) and parsing `stdout`. - `opencode-skills` follows the `claude code` *invocation pattern*: it's a native tool that injects the `SKILL.md` content as a `noReply` (user) message, which is the ideal way to handle persistence. - **Availability** - `openskills` is very helpful if you use other tools in addition to `opencode`, since it works with anything that reads `AGENTS.md`. - `opencode-skills` is clearly `opencode`-specific, which is perfect for what it does. --- Thanks to both @malhashemi and @numman-ali for giving us access to skills in `opencode` at such unprecedented speed, literally in less than 48 hours after Anthropic released the feature, we have parity in `opencode`. Great community!

yindo commented

@taqtiqa-mark commented on GitHub (Oct 31, 2025):

I'd strongly argue against an approach that just injects all available skills into the system prompt.

claude code: all skills are automatically exposed to your primary agent as well as all subagents (which I don’t like).

@taqtiqa-mark commented on GitHub (Oct 31, 2025): > I'd strongly argue against an approach that just injects all available skills into the system prompt. > * `claude code`: all skills are automatically exposed to your primary agent as well as all subagents (which I don’t like).

yindo commented

@klaudworks commented on GitHub (Nov 4, 2025):

@numman-ali your approach is not equivalent to what Anthropic does. This should be functionally equivalent: klaudworks/universal-skills. At least when using it with Claude Code the API requests and reponses are equivalent to native skills.

As @ihabwahbi mentioned: Anthropic injects available tools into each API request instead of into the AGENTS.md. The advantage is that the knowledge about your skills does not decay throughout the conversation.

@klaudworks commented on GitHub (Nov 4, 2025): @numman-ali your approach is not equivalent to what Anthropic does. This should be functionally equivalent: [klaudworks/universal-skills](https://github.com/klaudworks/universal-skills). At least when using it with Claude Code the API requests and reponses are equivalent to native skills. As @ihabwahbi mentioned: Anthropic injects available tools into each API request instead of into the AGENTS.md. The advantage is that the knowledge about your skills does not decay throughout the conversation.

yindo commented

https://github.com/numman-ali/openskills/blob/main/README.md

@numman-ali commented on GitHub (Nov 4, 2025):

@klaudworks please read my full write up

I literally network sniffed the calls and extracted the exact structure

There is system instructions added, and one load skills tool

Thats it

Agents.md is appended as system instructions for every other coding agent out there

Using MCP servers, removes the whole point of progressive disclosure

See their engineering blog

https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

End of the day, we can trust the OpenCode team to determine the best option - and I'm sure it'll be configurable and take the best of all implementations

@numman-ali commented on GitHub (Nov 4, 2025): @klaudworks please read my full write up https://github.com/numman-ali/openskills/blob/main/README.md I literally network sniffed the calls and extracted the exact structure There is system instructions added, and one load skills tool Thats it Agents.md is appended as system instructions for every other coding agent out there Using MCP servers, removes the whole point of progressive disclosure See their engineering blog https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills End of the day, we can trust the OpenCode team to determine the best option - and I'm sure it'll be configurable and take the best of all implementations

yindo commented

@klaudworks commented on GitHub (Nov 4, 2025):

@numman-ali I agree that you send the exact same "skill tool description" message provided by Claude Code:

Tool Description: Skill

<!--
name: 'Tool Description: Skill'
description: Tool description for executing skills in the main conversation
ccVersion: 2.0.20
variables:
  - AVAILBLE_SKILLS_1
  - AVAILBLE_SKILLS_2
-->
Execute a skill within the main conversation

<skills_instructions>
When users ask you to perform tasks, check if any of the available skills below can help complete the task more effectively. Skills provide specialized capabilities and domain knowledge.

How to use skills:
- Invoke skills using this tool with the skill name only (no arguments)
- When you invoke a skill, you will see <command-message>The "{name}" skill is loading</command-message>
- The skill's prompt will expand and provide detailed instructions on how to complete the task
- Examples:
  - \`command: "pdf"\` - invoke the pdf skill
  - \`command: "xlsx"\` - invoke the xlsx skill
  - \`command: "ms-office-suite:pdf"\` - invoke using fully qualified name

Important:
- Only use skills listed in <available_skills> below
- Do not invoke a skill that is already running
- Do not use this tool for built-in CLI commands (like /help, /clear, etc.)
</skills_instructions>

<available_skills>
${AVAILBLE_SKILLS_1}${AVAILBLE_SKILLS_2}
</available_skills>

What is not correct is that Claude Code sends the "Skill" tool description via the system prompt. The Claude.md is also not sent via a system prompt. At least not in Claude Code. It is sent via the following user input instead:

{
  "model": "claude-sonnet-4-5-20250929",
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "<system-reminder> ... $CLAUDE.md

The prior message will be part of your conversation history so your approach obviously works. It just has some shortcomings. LLMs have a recency bias so the knowledge of the CLAUDE.md / AGENTS.md fades throughout the conversation. That leads to worse retention of what each tool does and degrading accuracy when invoking tools. It also bypasses the training procedures to make LLMs reliably invoke tool calls.

The approach in openskills boils down to writing into the AGENT.md: "if you want more knowledge about apples, check .agent/skills/apple". That works but in my experience it doesn't work well especially in longer conversations. I'd be happy to hear your experience. You can just start a longer conversation and then try to invoke a skill. I'd strongly assume that it works less reliably. It might still work with direct prompts like "use skill apples" but I'd assume it fails with more implicit skill invocations.

What Claude actually does is to send their skill feature as an available tool in the request to the Anthropic API:

  "tools": [
    {
      "name": "Skill",
      "description": "${CONTENT_FROM_TOOL_DESCRIPTION}",
      "input_schema": {
        "type": "object",
        "properties": {
          "command": {
            "type": "string",
            "description": "The skill name (no arguments). E.g., \"pdf\" or \"xlsx\""
          }
        },
        "required": [
          "command"
        ],
        "additionalProperties": false,
        "$schema": "http://json-schema.org/draft-07/schema#"
      }
    },

The MCP approach in klaudworks/universal-skills leads to the exact same tool call (with negligible syntactic differences) because each MCP tool is translated into an LLM tool call. It also uses progressive disclosure because the actual SKILL.md is only loaded on demand.

I don't like MCP in general because it provides no native progressive disclosure mechanism and thus bloats the context. However, if you just define a single MCP tool that loads skills on demand then MCP is actually exactly what you want:

Easy to plug into any agent
Providing tool call / function call options to the LLM

EDIT: If you would like to understand how skills work in-depth you can read this: https://x.com/klaudworks/status/1982029102925414477

@klaudworks commented on GitHub (Nov 4, 2025): @numman-ali I agree that you send the exact same "skill tool description" message provided by Claude Code: <details> <summary>Tool Description: Skill</summary> ```markdown  Execute a skill within the main conversation <skills_instructions> When users ask you to perform tasks, check if any of the available skills below can help complete the task more effectively. Skills provide specialized capabilities and domain knowledge. How to use skills: - Invoke skills using this tool with the skill name only (no arguments) - When you invoke a skill, you will see <command-message>The "{name}" skill is loading</command-message> - The skill's prompt will expand and provide detailed instructions on how to complete the task - Examples: - \`command: "pdf"\` - invoke the pdf skill - \`command: "xlsx"\` - invoke the xlsx skill - \`command: "ms-office-suite:pdf"\` - invoke using fully qualified name Important: - Only use skills listed in <available_skills> below - Do not invoke a skill that is already running - Do not use this tool for built-in CLI commands (like /help, /clear, etc.) </skills_instructions> <available_skills> ${AVAILBLE_SKILLS_1}${AVAILBLE_SKILLS_2} </available_skills> ``` </details> What is not correct is that Claude Code sends the "Skill" tool description via the system prompt. The Claude.md is also not sent via a system prompt. At least not in Claude Code. It is sent via the following user input instead: ``` { "model": "claude-sonnet-4-5-20250929", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "<system-reminder> ... $CLAUDE.md ``` The prior message will be part of your conversation history so your approach obviously works. It just has some shortcomings. LLMs have a recency bias so the knowledge of the CLAUDE.md / AGENTS.md fades throughout the conversation. That leads to worse retention of what each tool does and degrading accuracy when invoking tools. It also bypasses the training procedures to make LLMs reliably invoke tool calls. The approach in openskills boils down to writing into the AGENT.md: "if you want more knowledge about apples, check .agent/skills/apple". That works but in my experience it doesn't work well especially in longer conversations. I'd be happy to hear your experience. You can just start a longer conversation and then try to invoke a skill. I'd strongly assume that it works less reliably. It might still work with direct prompts like "use skill apples" but I'd assume it fails with more implicit skill invocations. What Claude actually does is to send their skill feature as an available tool in the request to the Anthropic API: ``` "tools": [ { "name": "Skill", "description": "${CONTENT_FROM_TOOL_DESCRIPTION}", "input_schema": { "type": "object", "properties": { "command": { "type": "string", "description": "The skill name (no arguments). E.g., \"pdf\" or \"xlsx\"" } }, "required": [ "command" ], "additionalProperties": false, "$schema": "http://json-schema.org/draft-07/schema#" } }, ``` The MCP approach in [klaudworks/universal-skills](https://github.com/klaudworks/universal-skills) leads to the exact same tool call (with negligible syntactic differences) because each MCP tool is translated into an LLM tool call. It also uses progressive disclosure because the actual SKILL.md is only loaded on demand. I don't like MCP in general because it provides no native progressive disclosure mechanism and thus bloats the context. However, if you just define a single MCP tool that loads skills on demand then MCP is actually exactly what you want: - Easy to plug into any agent - Providing tool call / function call options to the LLM EDIT: If you would like to understand how skills work in-depth you can read this: https://x.com/klaudworks/status/1982029102925414477

yindo commented

@klaudworks commented on GitHub (Nov 4, 2025):

For a native implementation, I'd probably not go with MCP but directly inject a new tool call into the API request. Maybe one would also like to add a little interface decoration for skill invocations.

MCP is just an easy mechanism to plug this skills feature into any agent while preserving all important properties.

@klaudworks commented on GitHub (Nov 4, 2025): For a native implementation, I'd probably not go with MCP but directly inject a new tool call into the API request. Maybe one would also like to add a little interface decoration for skill invocations. MCP is just an easy mechanism to plug this skills feature into any agent while preserving all important properties.

yindo commented

@rekram1-node commented on GitHub (Nov 4, 2025):

apologies for jumping in, maybe i didn't read enough but just a note:

plugins allow custom tool definitions so that should be possible

@rekram1-node commented on GitHub (Nov 4, 2025): apologies for jumping in, maybe i didn't read enough but just a note: plugins allow custom tool definitions so that should be possible

yindo commented

@klaudworks commented on GitHub (Nov 4, 2025):

Then, this may be the way to go for a native implementation. As far as I can judge this looks like a solid approach: https://github.com/malhashemi/opencode-skills. It differs slightly from Claude Codes implementation by creating a tool per skill. That bloats the context a little more than a single tool but that shouldn't matter unless someone plans to use hundreds of tools.

Skills being individual tools allows permission control. Not sure if it's realistic that you would want to access to individual skills though. By design they don't directly interact with external systems anyways. In my current opinion there is not much value in that.

@klaudworks commented on GitHub (Nov 4, 2025): Then, this may be the way to go for a native implementation. As far as I can judge this looks like a solid approach: https://github.com/malhashemi/opencode-skills. It differs slightly from Claude Codes implementation by creating a tool per skill. That bloats the context a little more than a single tool but that shouldn't matter unless someone plans to use hundreds of tools. Skills being individual tools allows permission control. Not sure if it's realistic that you would want to access to individual skills though. By design they don't directly interact with external systems anyways. In my current opinion there is not much value in that.

yindo commented

@malhashemi commented on GitHub (Nov 4, 2025):

It differs slightly from Claude Codes implementation by creating a tool per skill. That bloats the context a little more than a single tool but that shouldn't matter unless someone plans to use hundreds of tools.

I'd like to argue that if we are using a single tool we still have to pass the name and description of every skill that is available, so single tool vs multiple tool doesn't really blow the context as much as we'd like to believe, if anything with one tool per skill, when you limit certain skills to agents/subagents you would be saving context, why pass skills to a subagent that doesn't need them?

Also another important note to keep in mind is how to invoke a skill, I noticed in longer conversations tool response purging is another issue that you would face, SKILL.md loaded by an MCP or tool response ends up getting forgotten if the skill process starts to drag, Claude Code loads SKILL.md as a user message, thanks to @rekram1-node for approving the noReply addition to the API/SDK which allowed the plugin to load the SKILL.md in a similar fashion.

However, this solution is still not perfect, currently OpenCode default read tool does not allow reading files outside the working directory, so when a skill is residing in ~/.opencode/skills and that skill has reference files to read we are getting read errors, the current solution is to use bash to read the file which I believe not ideal.

@rekram1-node anything can be done in that regard? or do you recommend that I serve a custom read tool (I really don't want to do that, specially that Claude Code default read tool can read files in any absolute path without any issues).

@malhashemi commented on GitHub (Nov 4, 2025): > It differs slightly from Claude Codes implementation by creating a tool per skill. That bloats the context a little more than a single tool but that shouldn't matter unless someone plans to use hundreds of tools. I'd like to argue that if we are using a single tool we still have to pass the name and description of every skill that is available, so single tool vs multiple tool doesn't really blow the context as much as we'd like to believe, if anything with one tool per skill, when you limit certain skills to agents/subagents you would be saving context, why pass skills to a subagent that doesn't need them? Also another important note to keep in mind is how to invoke a skill, I noticed in longer conversations tool response purging is another issue that you would face, `SKILL.md` loaded by an MCP or tool response ends up getting forgotten if the skill process starts to drag, Claude Code loads `SKILL.md` as a user message, thanks to @rekram1-node for approving the `noReply` addition to the API/SDK which allowed the plugin to load the `SKILL.md` in a similar fashion. However, this solution is still not perfect, currently OpenCode default read tool does not allow reading files outside the working directory, so when a skill is residing in `~/.opencode/skills` and that skill has reference files to read we are getting read errors, the current solution is to use bash to read the file which I believe not ideal. @rekram1-node anything can be done in that regard? or do you recommend that I serve a custom read tool (I really don't want to do that, specially that Claude Code default read tool can read files in any absolute path without any issues).

yindo commented

@taqtiqa-mark commented on GitHub (Nov 4, 2025):

@klaudworks:

That bloats the context a little more than a single tool but that shouldn't matter unless someone plans to use hundreds of tools.

I believe the issue is a workflow using many sessions and subagents, since agents & subagents can configure the tools then tools could be invoked a large number of times.

Skills being individual tools allows permission control. Not sure if it's realistic that you would want to access to individual skills though.

Yes, I believe, and find, these two features are essential.

@taqtiqa-mark commented on GitHub (Nov 4, 2025): @klaudworks: > That bloats the context a little more than a single tool but that shouldn't matter unless someone plans to use hundreds of tools. I believe the issue is a workflow using many sessions and subagents, since agents & subagents can configure the tools then tools could be invoked a large number of times. > Skills being individual tools allows permission control. Not sure if it's realistic that you would want to access to individual skills though. Yes, I believe, and find, these two features are essential.

yindo commented

@taqtiqa-mark commented on GitHub (Nov 4, 2025):

@malhashemi:

I'd like to argue that if we are using a single tool we still have to pass the name and description of every skill that is available

Given that agents and subagents can configure the set of tools available, such universal lists seems redundant.
If there is a use case can this behavior be configurable?

However, this solution is still not perfect, currently OpenCode default read tool does not allow reading files outside the working directory,

I isolate my projects in a container, and git, so a rouge prompt/skill/tool change doesn't affect me.... that said, this does matter for newer/casual users.
Since OpenCode does not guard against making changes without source control (discussed in another issue), there is some responsibility to ensure no edits to files outside of the current working directory unless explicitly requested, e.g. using bash (off by default) instead of Read tool

@taqtiqa-mark commented on GitHub (Nov 4, 2025): @malhashemi: > I'd like to argue that if we are using a single tool we still have to pass the name and description of every skill that is available Given that agents and subagents can configure the set of tools available, such universal lists seems redundant. If there is a use case can this behavior be configurable? > However, this solution is still not perfect, currently OpenCode default read tool does not allow reading files outside the working directory, I isolate my projects in a container, and git, so a rouge prompt/skill/tool change doesn't affect me.... that said, this does matter for newer/casual users. Since OpenCode does not guard against making changes without source control (discussed in another issue), there is some responsibility to ensure no edits to files outside of the current working directory unless explicitly requested, e.g. using bash (off by default) instead of Read tool

yindo commented

@airtonix commented on GitHub (Nov 5, 2025):

However, this solution is still not perfect, currently OpenCode default read tool does not allow reading files outside the working directory, so when a skill is residing in ~/.opencode/skills and that skill has reference files to read we are getting read errors, the current solution is to use bash to read the file which I believe not ideal.

@malhashemi Is this what you're referring to in this ticket? https://github.com/malhashemi/opencode-skills/issues/2

I was secretly hoping you wouldn't do something to close off access to the skills original directory.

my current strategy to minimise use of bash to access those files is to frontload all of references into a basicmemory project of the same name as the skill.

Not sure how bullet proof it really is though 😅

I suspect what you might have already thought of is providing a tool that allows reading of skill resources:

> pwd
/mnt/Store/Projects/test

> mythicaltree ~/.config/opencode/skills
speckit/
  SKILL.md
  planning/
    SKILL.md
    resources/
      ...

  resources/
    templates/
      spec.md
      plan.md
      ...
    scripts/
      get-worktree-id.sh

produces

skill_speckit()
skill_speckit_planning()
skill_resources(skillname: string, path: string)

and you might even address this in the skill description:

use `skill_resources(skillname:string,path:string)` when accessing `resource://<path>` references from a skills SKILL.md

@airtonix commented on GitHub (Nov 5, 2025): > However, this solution is still not perfect, currently OpenCode default read tool does not allow reading files outside the working directory, so when a skill is residing in `~/.opencode/skills` and that skill has reference files to read we are getting read errors, the current solution is to use bash to read the file which I believe not ideal. @malhashemi Is this what you're referring to in this ticket? https://github.com/malhashemi/opencode-skills/issues/2 I was secretly hoping you wouldn't do something to close off access to the skills original directory. my current strategy to minimise use of bash to access those files is to frontload all of `references` into a basicmemory project of the same name as the skill. Not sure how bullet proof it really is though 😅 I suspect what you might have already thought of is providing a tool that allows reading of skill resources: ```sh > pwd /mnt/Store/Projects/test > mythicaltree ~/.config/opencode/skills speckit/ SKILL.md planning/ SKILL.md resources/ ... resources/ templates/ spec.md plan.md ... scripts/ get-worktree-id.sh ``` produces ```ts skill_speckit() skill_speckit_planning() skill_resources(skillname: string, path: string) ``` and you might even address this in the skill description: ```md use `skill_resources(skillname:string,path:string)` when accessing `resource://<path>` references from a skills SKILL.md ```

yindo commented

@ribelo commented on GitHub (Dec 2, 2025):

Skills is no longer a feature of Claude Code. Today, experimental support was added to Codex
https://github.com/openai/codex/commit/a8d5ad37b8115068ff777b66ab9299cdab85cdd7

@ribelo commented on GitHub (Dec 2, 2025): Skills is no longer a feature of Claude Code. Today, experimental support was added to Codex https://github.com/openai/codex/commit/a8d5ad37b8115068ff777b66ab9299cdab85cdd7

yindo commented

@djmaze commented on GitHub (Dec 2, 2025):

Skills is no longer a feature of Claude Code.

It is not? At least it is still in the documentation: https://code.claude.com/docs/en/skills

@djmaze commented on GitHub (Dec 2, 2025): > Skills is no longer a feature of Claude Code. It is not? At least it is still in the documentation: https://code.claude.com/docs/en/skills

yindo commented

@rakibdev commented on GitHub (Dec 2, 2025):

skills are obsolete after new mcp tool search tool

@rakibdev commented on GitHub (Dec 2, 2025): skills are obsolete after new mcp tool search tool

yindo commented

@ruant commented on GitHub (Dec 2, 2025):

Skills is no longer a feature of Claude Code.

It is not? At least it is still in the documentation: https://code.claude.com/docs/en/skills

I think @ribelo meant it as that skills is not just a feature in Claude Code anymore, since now codex also have added support for it.

So perhaps opencode should reconsider their stance on the matter since other CLI's are also implementing support for skills. They wanted to see where things were going before commiting dev time, if I have understood previous comments on this issue correctly.

@ruant commented on GitHub (Dec 2, 2025): > > Skills is no longer a feature of Claude Code. > > It is not? At least it is still in the documentation: https://code.claude.com/docs/en/skills I think @ribelo meant it as that skills is not just a feature in Claude Code anymore, since now codex also have added support for it. So perhaps opencode should reconsider their stance on the matter since other CLI's are also implementing support for skills. They wanted to see where things were going before commiting dev time, if I have understood previous comments on this issue correctly.

yindo commented

@taqtiqa-mark commented on GitHub (Dec 2, 2025):

opencode should reconsider their stance on the matter

I believe @malhashemi 's opencode-skills plugin is a reasonable workaround until OC delivers some more critical bug fixes and features. Like:

chaotic primary-subagent interaction (A2A implementation)
undefined primary-primary interaction (A2A implementation)
Customizable System Prompts (i.e. the user has full control over all prompt content, no background injection, etc.)
File scope management (c.f. Aider's /add)
broken keybinding,
broken XML parsing around tooling,
flaky error handling around providers, etc.

Right now opencode-skills Just-Works(TM) enough to be a workaround, albeit with the skills_* prefix in tool settings, but I actually like the additional control that gives me over when Skills are available - YMMV.

@taqtiqa-mark commented on GitHub (Dec 2, 2025): > opencode should reconsider their stance on the matter I believe @malhashemi 's opencode-skills plugin is a reasonable workaround until OC delivers some more critical bug fixes and features. Like: - chaotic primary-subagent interaction (A2A implementation) - undefined primary-primary interaction (A2A implementation) - Customizable System Prompts (i.e. the user has full control over all prompt content, no background injection, etc.) - File scope management (c.f. Aider's `/add`) - broken keybinding, - broken XML parsing around tooling, - flaky error handling around providers, etc. Right now opencode-skills Just-Works(TM) enough to be a workaround, albeit with the `skills_*` prefix in tool settings, but I actually like the additional control that gives me over when Skills are available - YMMV.

yindo commented

@malhashemi commented on GitHub (Dec 3, 2025):

opencode should reconsider their stance on the matter

I believe @malhashemi 's opencode-skills plugin is a reasonable workaround until OC delivers some more critical bug fixes and features. Like:

chaotic primary-subagent interaction (A2A implementation)

undefined primary-primary interaction (A2A implementation)

Customizable System Prompts (i.e. the user has full control over all prompt content, no background injection, etc.)

File scope management (c.f. Aider's /add)

broken keybinding,

broken XML parsing around tooling,

flaky error handling around providers, etc.

Right now opencode-skills Just-Works(TM) enough to be a workaround, albeit with the skills_* prefix in tool settings, but I actually like the additional control that gives me over when Skills are available - YMMV.

Thanks for recommending my tool, but even as the maintainer of the tool I would love to see native support or at least some changes for how permission system works in OpenCode so I can make it as close to native as possible, I hate the skills_* pattern, the ideal way is so make a single skills tool and manage permission similar to how bash currently work in OpenCode, with the current implementation I have to do that permission control on the plugin level if I want to have such a pattern, which is something I don't want to manage as I want to leveraging the permission system that OpenCode already exposes. Maybe the native permission control for custom tools could get a revamp to allow for such a behaviour, this would make plugins even more powerful.

@malhashemi commented on GitHub (Dec 3, 2025): > > opencode should reconsider their stance on the matter > > I believe @malhashemi 's opencode-skills plugin is a reasonable workaround until OC delivers some more critical bug fixes and features. Like: > - chaotic primary-subagent interaction (A2A implementation) > - undefined primary-primary interaction (A2A implementation) > - Customizable System Prompts (i.e. the user has full control over all prompt content, no background injection, etc.) > - File scope management (c.f. Aider's `/add`) > - broken keybinding, > - broken XML parsing around tooling, > - flaky error handling around providers, etc. > > Right now opencode-skills Just-Works(TM) enough to be a workaround, albeit with the `skills_*` prefix in tool settings, but I actually like the additional control that gives me over when Skills are available - YMMV. Thanks for recommending my tool, but even as the maintainer of the tool I would love to see native support or at least some changes for how permission system works in OpenCode so I can make it as close to native as possible, I hate the `skills_*` pattern, the ideal way is so make a single `skills` tool and manage permission similar to how `bash` currently work in OpenCode, with the current implementation I have to do that permission control on the plugin level if I want to have such a pattern, which is something I don't want to manage as I want to leveraging the permission system that OpenCode already exposes. Maybe the native permission control for custom tools could get a revamp to allow for such a behaviour, this would make plugins even more powerful.

yindo commented

@malhashemi commented on GitHub (Dec 3, 2025):

chaotic primary-subagent interaction (A2A implementation)

undefined primary-primary interaction (A2A implementation).

@taqtiqa-mark

Also to note

A2A is already there in Opencode, task tool recently received an update with resume ability (pass the session Id to task tool) you can get the primary and subagent to talk back and forth. However I do not see that documented anywhere in the docs yet.

For primary A2A I already made a plugin for that Opencode-sessions (ask your agent to use the tool with mode = message and call whatever primary agent you want as target through agent argument)

@malhashemi commented on GitHub (Dec 3, 2025): > - chaotic primary-subagent interaction (A2A implementation) > - undefined primary-primary interaction (A2A implementation). @taqtiqa-mark Also to note A2A is already there in Opencode, task tool recently received an update with resume ability (pass the session Id to task tool) you can get the primary and subagent to talk back and forth. However I do not see that documented anywhere in the docs yet. For primary A2A I already made a plugin for that [Opencode-sessions](https://github.com/malhashemi/opencode-sessions) (ask your agent to use the tool with mode = `message` and call whatever primary agent you want as target through agent argument)

yindo commented

@taqtiqa-mark commented on GitHub (Dec 3, 2025):

Thanks for recommending my tool, but even as the maintainer of the tool I would love to see native support or at least some changes for how permission system works in OpenCode so I can make it as close to native as possible

Agreed. As I said, given the backlog, opencode-skills is a workaround that is a functional MVP until the final implementation lands..... keybindings, etc., etc. are not functional. I was just putting forward an alternative view of priorities that does not have Skills implementation as # 1.

Agreed that the implementation of Skills will (hopefully) be informed by these experiences.

@taqtiqa-mark commented on GitHub (Dec 3, 2025): > Thanks for recommending my tool, but even as the maintainer of the tool I would love to see native support or at least some changes for how permission system works in OpenCode so I can make it as close to native as possible Agreed. As I said, given the backlog, opencode-skills is a **workaround** that is a functional MVP until the final implementation lands..... keybindings, etc., etc. are not functional. I was just putting forward an alternative view of priorities that does not have Skills implementation as # 1. Agreed that the implementation of Skills will (hopefully) be informed by these experiences.

yindo commented

@thdxr commented on GitHub (Dec 4, 2025):

we're probably forced to support it at this point - talking to anthropic

@thdxr commented on GitHub (Dec 4, 2025): we're probably forced to support it at this point - talking to anthropic

yindo commented

@malhashemi commented on GitHub (Dec 4, 2025):

we're probably forced to support it at this point - talking to anthropic

Great news @thdxr !!!

Would love/be honoured to share my findings from the time I spent adopting it to be as close to OpenCode style as possible and all the community requests I received for the plugin 🙏. I am sure you will come up with a way better design than I did.

@malhashemi commented on GitHub (Dec 4, 2025): > we're probably forced to support it at this point - talking to anthropic Great news @thdxr !!! Would love/be honoured to share my findings from the time I spent adopting it to be as close to OpenCode style as possible and all the community requests I received for the plugin 🙏. I am sure you will come up with a way better design than I did.

yindo commented

@taqtiqa-mark commented on GitHub (Dec 9, 2025):

@malhashemi,

A2A is already there in Opencode

I should have linked, but here A2A refers to the protocol, see #3023

@taqtiqa-mark commented on GitHub (Dec 9, 2025): @malhashemi, > A2A is already there in Opencode I should have linked, but here A2A refers to the protocol, see #3023

yindo commented

@gsemet commented on GitHub (Dec 14, 2025):

Hello.

My custom solution on Vscode copilot:

I have a tool that index all skills in a nested structure. This is important because it can becomes really huge especially when sharing with several teams
skills has 2 states: activated/unactivated, loaded/unloaded.
Unactivated skills are not « kwown » at all by the coding agent
once activated (by a CLI tool), the frontmatter description and keywords are forcefully added to the context through a equivalent of AGENTS.md (« always injected » instruction files that explain briefly what a skill is and has a recopy of all the activated skills frontmatter). The context always has this content and I do not see any drift so far
the Coding agent can easily load the skill based on user intend. That requires the knowledge base (a git repo) to be in the workspace, but maybe this can be done by MCP server, I tested it but it does not work (I did it wrong probably)
the CLI can forcefully « load » a skill to the context (ie recopy the SKILL.md to the instruction files), for a dedicated session for instance. I actually never use this.

At the end, I can do in my vscode « use the skill creator skill to generate a skill in xxx about project in path yyyy », and I see the progressive disclosure directly happening in the chat.

Doing this by MCP makes it really hard do see if the agent has understood the intent.

I want you have your feedback, I would be glad to have a standard solution to write skills (especially shared, hierarchical repositories of skills in a company)

@gsemet commented on GitHub (Dec 14, 2025): Hello. My custom solution on Vscode copilot: - I have a tool that index all skills in a nested structure. This is important because it can becomes really huge especially when sharing with several teams - skills has 2 states: activated/unactivated, loaded/unloaded. - Unactivated skills are not « kwown » at all by the coding agent - once activated (by a CLI tool), the frontmatter description and keywords are forcefully added to the context through a equivalent of AGENTS.md (« always injected » instruction files that explain briefly what a skill is and has a recopy of all the activated skills frontmatter). The context always has this content and I do not see any drift so far - the Coding agent can easily load the skill based on user intend. That requires the knowledge base (a git repo) to be in the workspace, but maybe this can be done by MCP server, I tested it but it does not work (I did it wrong probably) - the CLI can forcefully « load » a skill to the context (ie recopy the SKILL.md to the instruction files), for a dedicated session for instance. I actually never use this. At the end, I can do in my vscode « use the skill creator skill to generate a skill in xxx about project in path yyyy », and I see the progressive disclosure directly happening in the chat. Doing this by MCP makes it really hard do see if the agent has understood the intent. I want you have your feedback, I would be glad to have a standard solution to write skills (especially shared, hierarchical repositories of skills in a company)

yindo commented

@klaudworks commented on GitHub (Dec 15, 2025):

I'd be happy to implement a skill implementation native to opencode:

I already analyzed the requests to Anthropic: https://x.com/klaudworks/status/1982029102925414477
and implemented my own MCP based version that mirrors it: https://github.com/klaudworks/universal-skills

@klaudworks commented on GitHub (Dec 15, 2025): I'd be happy to implement a skill implementation native to opencode: I already analyzed the requests to Anthropic: https://x.com/klaudworks/status/1982029102925414477 and implemented my own MCP based version that mirrors it: https://github.com/klaudworks/universal-skills

yindo commented

https://scottspence.com/posts/how-to-make-claude-code-skills-activate-reliably:

@taqtiqa-mark commented on GitHub (Dec 15, 2025):

I'd be happy to implement a skill implementation native to opencode:

Would you implement support for .hooks the way CC does? The use case is set out here:

... skills are supposed to activate autonomously based on their descriptions. ... In practice? Nah. ... Forced hook never completely failed a category (most consistent).

There will always be some degree of mismatch between what an use instructs and the skill description. Nonetheless, opencode-skills has rejected building in this CC compatibility feature. See https://github.com/malhashemi/opencode-skills/issues/38

This is one of the things where I think CC is sane.

@taqtiqa-mark commented on GitHub (Dec 15, 2025): > I'd be happy to implement a skill implementation native to opencode: Would you implement support for `.hooks` the way CC does? The use case is set out here: https://scottspence.com/posts/how-to-make-claude-code-skills-activate-reliably: > ... skills are supposed to activate autonomously based on their descriptions. ... In practice? Nah. ... Forced hook never completely failed a category (most consistent). - [Tabulated Results](https://scottspence.com/posts/how-to-make-claude-code-skills-activate-reliably#complete-results-across-all-hooks) - [Tabulated Costs](https://scottspence.com/posts/how-to-make-claude-code-skills-activate-reliably#cost-and-performance-comparison) There will always be some degree of mismatch between what an use instructs and the skill description. Nonetheless, opencode-skills has rejected building in this CC compatibility feature. See https://github.com/malhashemi/opencode-skills/issues/38 This is one of the things where I think CC is sane.

yindo commented

https://github.com/joshuadavidthomas/opencode-agent-skills/blob/1b4b97226bd39acdae9c6b4ac1c3a8bb31992130/src/plugin.ts#L44-L56

@joshuadavidthomas commented on GitHub (Dec 15, 2025):

I read that blog post and ended up adding something to the skills plugin I've been kicking around for the past couple of weeks, opencode-agent-skills. Basically I generate a local embedding of all the skills via all-MiniLM-L6-v2 and on every user message I do a quick search for any potential relevant skills and inject a small synthetic reminder message:

<skill-evaluation-required>
SKILL EVALUATION PROCESS

The following skills may be relevant to your request:

${skillLines}

Step 1 - EVALUATE: Determine if these skills would genuinely help
Step 2 - DECIDE: Choose which skills (if any) are actually needed
Step 3 - ACTIVATE: Call use_skill("name") for each chosen skill

If no skills are needed for this request, proceed without activation.
</skill-evaluation-required>

It's only been a few days, but LLMs do seem to be a bit more eager to call skills, at least if they are relevant to the conversation. I don't have any hard evals around it, just a gut feeling. And since I dedupe any skills that are loaded in the course of a session, there's not a huge token hit to the context window.

I should note, the approach I took differs slightly from the one by @malhashemi in opencode-skills -- instead of tools for each skill, my plugin just has 4 tools around listing and reading skills and I do inject messages into the session through the chat.message hook and the session.compacted event.

@joshuadavidthomas commented on GitHub (Dec 15, 2025): I read that blog post and ended up adding something to the skills plugin I've been kicking around for the past couple of weeks, [opencode-agent-skills](https://github.com/joshuadavidthomas/opencode-agent-skills). Basically I generate a local embedding of all the skills via all-MiniLM-L6-v2 and on every user message I do a quick search for any potential relevant skills and inject a small synthetic reminder message: > ``` > <skill-evaluation-required> > SKILL EVALUATION PROCESS > > The following skills may be relevant to your request: > > ${skillLines} > > Step 1 - EVALUATE: Determine if these skills would genuinely help > Step 2 - DECIDE: Choose which skills (if any) are actually needed > Step 3 - ACTIVATE: Call use_skill("name") for each chosen skill > > If no skills are needed for this request, proceed without activation. > </skill-evaluation-required> > ``` https://github.com/joshuadavidthomas/opencode-agent-skills/blob/1b4b97226bd39acdae9c6b4ac1c3a8bb31992130/src/plugin.ts#L44-L56 It's only been a few days, but LLMs do seem to be a bit more eager to call skills, at least if they are relevant to the conversation. I don't have any hard evals around it, just a gut feeling. And since I dedupe any skills that are loaded in the course of a session, there's not a huge token hit to the context window. I should note, the approach I took differs slightly from the one by @malhashemi in opencode-skills -- instead of tools for each skill, my plugin just has 4 tools around listing and reading skills and I do inject messages into the session through the `chat.message` hook and the `session.compacted` event.

yindo commented

@taqtiqa-mark commented on GitHub (Dec 15, 2025):

I should note, the approach I took differs slightly from the one by @malhashemi in opencode-skills -- instead of tools for each skill, my plugin just has 4 tools around listing and reading skills and I do inject messages into the session through the chat.message hook and the session.compacted event.

Thanks for the heads-up about your plugin, and the feedback. I think one of the things opencode-skills gets right is the 1:1 mapping between skills and tools - to the extent that this gives atomic control over what skills are active for each agent, via the tools list.

Another, is respecting nested skills folders.

@taqtiqa-mark commented on GitHub (Dec 15, 2025): > I should note, the approach I took differs slightly from the one by [@malhashemi](https://github.com/malhashemi) in opencode-skills -- instead of tools for each skill, my plugin just has 4 tools around listing and reading skills and I do inject messages into the session through the `chat.message` hook and the `session.compacted` event. Thanks for the heads-up about your plugin, and the feedback. I think one of the things opencode-skills gets right is the 1:1 mapping between skills and tools - to the extent that this gives atomic control over what skills are active for each agent, via the tools list. Another, is respecting nested skills folders.

yindo commented

@rekram1-node commented on GitHub (Dec 15, 2025):

Dax said he should be adding this first party v soon

@rekram1-node commented on GitHub (Dec 15, 2025): Dax said he should be adding this first party v soon

yindo commented

@surma commented on GitHub (Dec 19, 2025):

Quick question: I just stumbled over agentskills.io, which seems to be a standardization(-ish) effort around skills, and it lists OpenCode as a tool that supports it. Is this issue out of date, is the website wrong or is there other nuance to this?

@surma commented on GitHub (Dec 19, 2025): Quick question: I just stumbled over agentskills.io, which seems to be a standardization(-ish) effort around skills, and it lists OpenCode as a tool that supports it. Is this issue out of date, is the website wrong or is there other nuance to this? <img width="788" height="562" alt="Image" src="https://github.com/user-attachments/assets/5ed73da0-c2cf-4c62-b8f4-9f56e38db978" />

yindo commented

@ucirello commented on GitHub (Dec 19, 2025):

@surma -- currently is achieved by a plugin. Refer to https://opencode.ai/docs/ecosystem/#plugins

@ucirello commented on GitHub (Dec 19, 2025): @surma -- currently is achieved by a plugin. Refer to https://opencode.ai/docs/ecosystem/#plugins

yindo commented

https://x.com/i/status/2001717794946031740

@trystan2k commented on GitHub (Dec 19, 2025):

Quick question: I just stumbled over agentskills.io, which seems to be a standardization(-ish) effort around skills, and it lists OpenCode as a tool that supports it. Is this issue out of date, is the website wrong or is there other nuance to this?

Dax mentioned in X they are working on it and plan to ship next week

@trystan2k commented on GitHub (Dec 19, 2025): > Quick question: I just stumbled over agentskills.io, which seems to be a standardization(-ish) effort around skills, and it lists OpenCode as a tool that supports it. Is this issue out of date, is the website wrong or is there other nuance to this? > > <img width="788" height="562" alt="Image" src="https://github.com/user-attachments/assets/5ed73da0-c2cf-4c62-b8f4-9f56e38db978" /> Dax mentioned in X they are working on it and plan to ship next week https://x.com/i/status/2001717794946031740

yindo commented

@jensenojs commented on GitHub (Dec 22, 2025):

I'd be happy to implement a skill implementation native to opencode:我很乐意在 opencode 中实现原生的技能功能：

Would you implement support for .hooks the way CC does? The use case is set out here:您会像 CC 那样实现 .hooks 的支持吗？具体用例说明如下：

https://scottspence.com/posts/how-to-make-claude-code-skills-activate-reliably:

... skills are supposed to activate autonomously based on their descriptions. ... In practice? Nah. ... Forced hook never completely failed a category (most consistent).……技能应能根据其描述自主激活。……实际效果如何？不尽如人意。……强制钩子从未在任何类别中完全失效（表现最为稳定）。

Tabulated Results 制表结果

Tabulated Costs 费用统计表格

There will always be some degree of mismatch between what an use instructs and the skill description. Nonetheless, opencode-skills has rejected building in this CC compatibility feature. See malhashemi/opencode-skills#38用户指令与技能描述之间总会存在某种程度的不匹配。尽管如此，开源技能项目已拒绝内置此项 CC 兼容性功能。详情参见 malhashemi/opencode-skills#38

This is one of the things where I think CC is sane.这正是我认为 CC 设计理念较为合理的方面之一。

Is there any further discussion on this topic?

@jensenojs commented on GitHub (Dec 22, 2025): > > I'd be happy to implement a skill implementation native to opencode:我很乐意在 opencode 中实现原生的技能功能： > > Would you implement support for `.hooks` the way CC does? The use case is set out here:您会像 CC 那样实现 `.hooks` 的支持吗？具体用例说明如下： > > https://scottspence.com/posts/how-to-make-claude-code-skills-activate-reliably: > > > ... skills are supposed to activate autonomously based on their descriptions. ... In practice? Nah. ... Forced hook never completely failed a category (most consistent).……技能应能根据其描述自主激活。……实际效果如何？不尽如人意。……强制钩子从未在任何类别中完全失效（表现最为稳定）。 > > * [Tabulated Results 制表结果](https://scottspence.com/posts/how-to-make-claude-code-skills-activate-reliably#complete-results-across-all-hooks) > * [Tabulated Costs 费用统计表格](https://scottspence.com/posts/how-to-make-claude-code-skills-activate-reliably#cost-and-performance-comparison) > > There will always be some degree of mismatch between what an use instructs and the skill description. Nonetheless, opencode-skills has rejected building in this CC compatibility feature. See [malhashemi/opencode-skills#38](https://github.com/malhashemi/opencode-skills/issues/38)用户指令与技能描述之间总会存在某种程度的不匹配。尽管如此，开源技能项目已拒绝内置此项 CC 兼容性功能。详情参见 [malhashemi/opencode-skills#38](https://github.com/malhashemi/opencode-skills/issues/38) > > This is one of the things where I think CC is sane.这正是我认为 CC 设计理念较为合理的方面之一。 Is there any further discussion on this topic?

yindo commented