[FEATURE]: Plugin Hook for Registering Additional Config Directories

Feature hasn't been suggested before.

I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Add a plugin hook that allows plugins to register additional directories for skill, agent, command, and tool discovery. This enables plugins to provide pre-packaged configurations without polluting the user's config directories.

Problem Statement

Currently, Config.directories() is resolved during config initialization, before plugins have a chance to influence the search paths. This creates limitations for plugins that want to provide:

Skills from external sources (e.g., Git repositories, skill marketplaces)
Shared agent definitions (e.g., team-wide agents)
Shared commands (e.g., organization-standard commands)
Shared tools (e.g., custom tool libraries)

Current Workarounds

Plugins must resort to workarounds like:

Symlinking into user directories - Creates clutter and risks accidental commits
Replacing built-in tools - Complex and may conflict with other plugins
Custom tool implementations - Duplicates existing functionality

My Use Case: Remote Skills Plugin

I want to provide a repository that team-members can install to have commands, skills, etc. with the least amount of friction. They should be able to install and remove it.

Currently, this requires symlinking into the user's skill directory and managing .gitignore - a fragile approach that mixes plugin-managed content with user content.

By adding extra config directories (I know the environment variable exists), it would be possible to create richer plugins for opencode.

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

Streamlined Distribution for Agent Definitions #3471: Streamlined Distribution for Agent Definitions - Discusses distributing agent definitions through plugins/repositories
[FEATURE]: Allow plugins to have their own configuration #4393: Allow plugins to have their own configuration - Requests the ability to configure plugins with custom paths
[FEATURE]: Add Skill Configuration to Config Type #6013: Add Skill Configuration to Config Type - Requests adding skill configuration support similar to agents and commands
Does opencode actually support finding skills at .claude/skills? #6266: Does opencode actually support finding skills at .claude/skills? - Questions about configurable skill directories

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

I see #6013 and that would also do the job, but I would be nice to just have the same directories and markdown files and put them into a repository and be able to share that.

I also need this kind of functionality, with the aim of packaging configurations such as command, agent, skill, and MCP.
I hope that OpenCode can support this soon, as it will help promote the expansion of the OpenCode ecosystem.

Yeah the usecase makes sense, Dax will prolly have a good idea on the approach we should tkae

@thdxr

@thdxr I would like to know your thoughts on this issue and when we might expect a solution.

I've noticed quite a few similar issues being reported recently, which indicates that many users share this need. We would really appreciate it if this could be addressed as soon as possible.

I didn't see how I could customize the skills folder to detect github / vs code skills. https://code.visualstudio.com/docs/copilot/customization/agent-skills

Seems like it should just be looking for a */skills/*SKILL.md and that would match almost any implementation.

@thdxr

@thdxr Recently, there have been more and more issues related to the opencode marketplace and similar topics. There are many different proposals, so it is recommended that the opencode team provide an official solution as soon as possible to prevent the ecosystem from becoming too fragmented.

In my opinion, all third-party compatibility layers (SKILL.md, Claude Code, Cursor, Copilot, Codex, etc.) should also be moved to plug-ins to avoid overcomplication of the base app.

This would be a useful workaround, but I think the cleaner solution is what #6013 proposes: adding skill directly to the plugin return type.

Instead of:

return {
  "config.directories": async (dirs) => {
    dirs.push("/path/to/my-plugin/skills")
  }
}

We could have:

return {
  skill: {
    "pdf": skill({ ... }),
  }
}

The directory hook approach still requires managing file paths and dealing with the "where does the plugin live after npm install" problem. Direct skill export would be more explicit and portable.

That said, the directory hook could still be valuable for other use cases (dynamic skill loading, monorepo setups, etc.), so maybe both approaches make sense.

Related: #8386 proposes a completely separate Skill Registry system, which I think is overkill when we could just enhance the existing plugin system per #6013.

Would be great to get movement on this - the current workaround of symlinking is fragile as you mentioned.

I've opened a PR that addresses this use case: #9010

Rather than a directory hook, the implementation lets plugins declare skill paths directly:

export const MyPlugin: Plugin = async () => ({
  skill: ['./skills/pdf', './skills/docs/*']
})

This avoids the "where does the plugin live after npm install" problem since paths are resolved relative to the plugin file. Plugins can now bundle skills alongside tools and hooks in a single distributable package.

Feedback welcome!

To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.

Navigation Menu

Repository navigation

[FEATURE]: Plugin Hook for Registering Additional Config Directories #6347

Feature hasn't been suggested before.

Describe the enhancement you want to request

Problem Statement

Current Workarounds

My Use Case: Remote Skills Plugin

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE]: Plugin Hook for Registering Additional Config Directories #6347

Description

Feature hasn't been suggested before.

Describe the enhancement you want to request

Problem Statement

Current Workarounds

My Use Case: Remote Skills Plugin

Activity

github-actions commented on Dec 29, 2025

jgordijn commented on Dec 29, 2025

wch-abc commented on Dec 31, 2025

rekram1-node commented on Dec 31, 2025

wch-abc commented on Jan 6, 2026

niemyjski commented on Jan 11, 2026

wch-abc commented on Jan 12, 2026

kostrse commented on Jan 12, 2026

kvnwolf commented on Jan 16, 2026

kvnwolf commented on Jan 17, 2026

thdxr commented on Mar 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions