Potential support for openskill universal path

[casassg]

A new project dropped out which allows people to fetch skills from github and manage them on laptops. For the most part it seems like a GitHub fetch + place under a folder in either project or $HOME. https://github.com/numman-ali/openskills

This bridges a small gap for my use of SKILLs in claude code vs opencode which may be interesting to support:

• Allow me to fetch skills written in separate repos easily.
• Re-use them in my projects/manage the global ones.

I think the nice thing about this plugin is that you don't need to do openskills sync. However it would be nice to support ./.agent/skills and ~/.agent/skills/ in this project.

Posting here as food for thought (there is workarounds which is doing symlinks locally to the folder opencode uses)

[malhashemi]

Hi @casassg thanks for bringing this up!

I think it makes sense to let users define what additional directories the tool should scan. I'm considering either a config option (possibly through opencode.json) or an environment variable approach, still need to explore which would work best. I'll get
back to you on this.

As for fetching skills, the issue is how you would interact with the plugin. The idea behind it is that it gives your coding agent a set of tools. The main value proposition is the ability to control skill permissions on an individual agent/subagent level. This lets you have a massive amount of skills without polluting your context, compared to simply listing every single skill in AGENTS.md. So trying to fetch skills in a separate repo feels like it's outside the scope of this plugin. However, I'll see if we can do something about it.

[taqtiqa-mark]

@malhashemi, thanks for your work on this. Hopefully your spike develops into a part of core.

I think it makes sense to let users define what additional directories the tool should scan. I'm considering either a config option (possibly through opencode.json) or an environment variable approach

Yes, is would be great if the user could have project level control of the skills that are loaded. As requested here:

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

Currently the folder hierarchy is scanned and all skills collated. This is great for working out whay skills a project has access to if there is no whitelist provided.

But, loading all name/Skill.md will quickly get out of hand, if it is not already, see https://github.com/obra/superpowers https://github.com/obra/superpowers-skills

In this way they could also be given control of the location I'd start with the URI/URL spec (file:///... and http(s)) and accept fragments, starting from the end.

This suggests json config is the way to go.... passing each skill as env varaiable will get old fast.

[malhashemi]

@taqtiqa-mark You can achieve comprehensive control at all levels with this plugin, which I believe addresses what the comment you referred to was discussing.

Here are three levels of control:

1. Project Level (Global Defaults)

In your project's opencode.json, disable all skills by default and only enable specific ones:

{
  "$schema": "https://opencode.ai/config.json",
  "tools": {
    "skills*": false,
    "skills_skill_creator": true
  }
}

This prevents skill context pollution across your entire project.

2. Built-in Agent Level

Override defaults for specific built-in agents (like build, plan, etc.):

{
  "$schema": "https://opencode.ai/config.json",
  "tools": {
    "skills*": false
  },
  "agent": {
    "build": {
      "tools": {
        "skills_document_skills_docx": true,
        "skills_document_skills_xlsx": true
      }
    }
  }
}

Now only the build agent has access to document skills.

3. Subagent Level

For custom subagents, control tools via YAML frontmatter:

mode: subagent
description: content creator
tools:
  skills_document_skills_pptx: true

This subagent gets presentation skills even if disabled globally.

---

Now going back to path management:

I see the main use case not being to manage your loaded skills, but rather to allow flexibility in supporting skills present in other directories due to project constraints. I have yet to find the time to fiddle with opencode.json to see if it would allow me to include some extra config into it. I really do not want to get people to add another config file in their project.

Another challenge that comes to mind: if we take in URIs, there's the issue of how to handle references mentioned in SKILL.md. The current spec by Anthropic doesn't have any fancy loading mechanism, it simply relies on the coding agent's default file read tool. As far as I know, that doesn't support URIs, meaning the workaround would probably be to download all the URI folder content to some tmp/ folder in your project directory when the plugin starts. Not sure if this is an elegant enough solution.

---

However, I totally agree that things can easily get out of hand. Not only with skills, I run OpenCode for all types of workflows, not only software engineering. Some are pure business-related, some are marketing, etc., and in many cases there's a swarm of agents/subagents working on the same project from different angles, each having their own commands, skills, MCPs, and custom tools. Claude Code's plugin system is a good solution, but what do we do when there's a team where each member is leaning towards using a different coding agent? Things get out of hand real quick with each project having .claude, .opencode, .cursor, etc.

I see the problem of managing/distributing your LLM tooling as a real problem. I've seen multiple agentic workflow package management solutions popping up and I'm trying several of these, but the tools I've tried so far are really not satisfactory enough. I'm getting very close to taking this on as a serious project, we need something as easy as shadcn's registry but for coding agents.

[taqtiqa-mark]

... the workaround would probably be to download all the URI folder content to some tmp/ folder in your project directory when the plugin starts.

I'd argue for the convention to be: skills that are used by OpenCode should be downloaded/installed to \<project\>.opencode/skill/.

As you remark, multiple agents can coexist as long as they stay in their "lane": .opencode, .claude, etc.

There may be some duplication, but this allows each to evolve independently.

As you remark, OpenCode, is a bit of a misnomer for some users. It's more OpenAgent.

[khaliqgant]

I see the problem of managing/distributing your LLM tooling as a real problem. I've seen multiple agentic workflow package management solutions popping up and I'm trying several of these, but the tools I've tried so far are really not satisfactory enough. I'm getting very close to taking this on as a serious project, we need something as easy as shadcn's registry but for coding agents.

Jumping in here, I would invite you to try out prpm.dev as I believe we're trying to solve the problem you mention. Open to any feedback, thoughts, or suggestions!

Also worth mentioning that I am working on adding in first support for opencode as well and the .opencode/agent project configuration. Great work on opencode!