anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 17:42:05 -05:00 by yindo · 10 comments
yindo commented 2026-02-16 17:42:05 -05:00
Owner
Copy Link
Copy Source

Originally created by @jgordijn on GitHub (Dec 29, 2025).

Originally assigned to: @thdxr on GitHub.

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:

  1. Symlinking into user directories - Creates clutter and risks accidental commits
  2. Replacing built-in tools - Complex and may conflict with other plugins
  3. 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.

Originally created by @jgordijn on GitHub (Dec 29, 2025). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] 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: 1. **Symlinking into user directories** - Creates clutter and risks accidental commits 2. **Replacing built-in tools** - Complex and may conflict with other plugins 3. **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.
yindo added the discussion label 2026-02-16 17:42:05 -05:00
yindo commented 2026-02-16 17:42:06 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 29, 2025):

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

  • #3471: Streamlined Distribution for Agent Definitions - Discusses distributing agent definitions through plugins/repositories
  • #4393: Allow plugins to have their own configuration - Requests the ability to configure plugins with custom paths
  • #6013: Add Skill Configuration to Config Type - Requests adding skill configuration support similar to agents and commands
  • #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.

@github-actions[bot] commented on GitHub (Dec 29, 2025): This issue might be a duplicate of existing issues. Please check: - #3471: Streamlined Distribution for Agent Definitions - Discusses distributing agent definitions through plugins/repositories - #4393: Allow plugins to have their own configuration - Requests the ability to configure plugins with custom paths - #6013: Add Skill Configuration to Config Type - Requests adding skill configuration support similar to agents and commands - #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.
yindo commented 2026-02-16 17:42:06 -05:00
Author
Owner
Copy Link
Copy Source

@jgordijn commented on GitHub (Dec 29, 2025):

I see https://github.com/sst/opencode/issues/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.

@jgordijn commented on GitHub (Dec 29, 2025): I see https://github.com/sst/opencode/issues/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.
yindo commented 2026-02-16 17:42:06 -05:00
Author
Owner
Copy Link
Copy Source

@wch-abc commented on GitHub (Dec 31, 2025):

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.

@wch-abc commented on GitHub (Dec 31, 2025): 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.
yindo commented 2026-02-16 17:42:06 -05:00
Author
Owner
Copy Link
Copy Source

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

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

@rekram1-node commented on GitHub (Dec 31, 2025): Yeah the usecase makes sense, Dax will prolly have a good idea on the approach we should tkae
yindo commented 2026-02-16 17:42:06 -05:00
Author
Owner
Copy Link
Copy Source

@wch-abc commented on GitHub (Jan 6, 2026):

@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.

@wch-abc commented on GitHub (Jan 6, 2026): @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.
yindo commented 2026-02-16 17:42:06 -05:00
Author
Owner
Copy Link
Copy Source

@niemyjski commented on GitHub (Jan 11, 2026):

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.

@niemyjski commented on GitHub (Jan 11, 2026): 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.
yindo commented 2026-02-16 17:42:06 -05:00
Author
Owner
Copy Link
Copy Source

@wch-abc commented on GitHub (Jan 11, 2026):

@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.

@wch-abc commented on GitHub (Jan 11, 2026): @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.
yindo commented 2026-02-16 17:42:06 -05:00
Author
Owner
Copy Link
Copy Source

@kostrse commented on GitHub (Jan 12, 2026):

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.

@kostrse commented on GitHub (Jan 12, 2026): 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.
yindo commented 2026-02-16 17:42:06 -05:00
Author
Owner
Copy Link
Copy Source

@kvnwolf commented on GitHub (Jan 16, 2026):

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.

@kvnwolf commented on GitHub (Jan 16, 2026): 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: ```typescript return { "config.directories": async (dirs) => { dirs.push("/path/to/my-plugin/skills") } } ``` We could have: ```typescript 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.
yindo commented 2026-02-16 17:42:06 -05:00
Author
Owner
Copy Link
Copy Source

@kvnwolf commented on GitHub (Jan 16, 2026):

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!

@kvnwolf commented on GitHub (Jan 16, 2026): I've opened a PR that addresses this use case: #9010 Rather than a directory hook, the implementation lets plugins declare skill paths directly: ```typescript 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!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3959
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?