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

[FEATURE]: Add Skill Configuration to Config Type #3776

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

Originally created by @wch-abc on GitHub (Dec 23, 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

Request to add skill configuration support to the Config type, similar to existing agent, command, mcp, and plugin configurations. This would enable skill management through config hooks and provide better extensibility.

Originally created by @wch-abc on GitHub (Dec 23, 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 Request to add `skill` configuration support to the `Config` type, similar to existing `agent`, `command`, `mcp`, and `plugin` configurations. This would enable skill management through config hooks and provide better extensibility.
yindo added the discussion label 2026-02-16 17:41:26 -05:00
yindo commented 2026-02-16 17:41:26 -05:00
Author
Owner
Copy Link
Copy Source

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

Related discussion: This feature request follows a similar pattern to #4393 which requests configuration support for plugins. You might want to check that issue to understand the broader context of adding configuration support to different extensibility types in the Config type.

@github-actions[bot] commented on GitHub (Dec 23, 2025): Related discussion: This feature request follows a similar pattern to #4393 which requests configuration support for plugins. You might want to check that issue to understand the broader context of adding configuration support to different extensibility types in the Config type.
yindo commented 2026-02-16 17:41:26 -05:00
Author
Owner
Copy Link
Copy Source

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

+1 on this. This is the right approach.

Currently plugins can export tool, but not skill. The inconsistency is frustrating when you want to distribute a complete package (skill + supporting tools + hooks).

Related issues:

  • #6347 proposes a hook for registering config directories (workaround)
  • #8386 proposes a completely new Skill Registry system (overkill IMO)

Both of those would be unnecessary if we just add skill to the plugin return type:

export const MyPlugin: Plugin = async (ctx) => {
  return {
    skill: {
      "my-skill":  skill({ ... })
    },
  }
}

This keeps the plugin system as the single distribution mechanism for all OpenCode extensions, which is much cleaner than having separate systems for tools vs skills vs commands.

Any updates on this? Would love to see it prioritized.

@kvnwolf commented on GitHub (Jan 16, 2026): +1 on this. This is the right approach. Currently plugins can export `tool`, but not `skill`. The inconsistency is frustrating when you want to distribute a complete package (skill + supporting tools + hooks). Related issues: - #6347 proposes a hook for registering config directories (workaround) - #8386 proposes a completely new Skill Registry system (overkill IMO) Both of those would be unnecessary if we just add `skill` to the plugin return type: ```typescript export const MyPlugin: Plugin = async (ctx) => { return { skill: { "my-skill": skill({ ... }) }, } } ``` This keeps the plugin system as the single distribution mechanism for all OpenCode extensions, which is much cleaner than having separate systems for tools vs skills vs commands. Any updates on this? Would love to see it prioritized.
yindo commented 2026-02-16 17:41:26 -05:00
Author
Owner
Copy Link
Copy Source

@super-unique-ai commented on GitHub (Jan 16, 2026):

+1 on this. This is the right approach.

Currently plugins can export tool, but not skill. The inconsistency is frustrating when you want to distribute a complete package (skill + supporting tools + hooks).

Related issues:

Both of those would be unnecessary if we just add skill to the plugin return type:

export const MyPlugin: Plugin = async (ctx) => {
return {
skill: {
"my-skill": skill({ ... })
},
}
}
This keeps the plugin system as the single distribution mechanism for all OpenCode extensions, which is much cleaner than having separate systems for tools vs skills vs commands.

Any updates on this? Would love to see it prioritized.

I Support!

@super-unique-ai commented on GitHub (Jan 16, 2026): > +1 on this. This is the right approach. > > Currently plugins can export `tool`, but not `skill`. The inconsistency is frustrating when you want to distribute a complete package (skill + supporting tools + hooks). > > Related issues: > > * [[FEATURE]: Plugin Hook for Registering Additional Config Directories #6347](https://github.com/anomalyco/opencode/issues/6347) proposes a hook for registering config directories (workaround) > * [[FEATURE]: Skill Registry + Installer for Awesome-Claude-Skills (Make OpenCode the One Tool) #8386](https://github.com/anomalyco/opencode/issues/8386) proposes a completely new Skill Registry system (overkill IMO) > > Both of those would be unnecessary if we just add `skill` to the plugin return type: > > export const MyPlugin: Plugin = async (ctx) => { > return { > skill: { > "my-skill": skill({ ... }) > }, > } > } > This keeps the plugin system as the single distribution mechanism for all OpenCode extensions, which is much cleaner than having separate systems for tools vs skills vs commands. > > Any updates on this? Would love to see it prioritized. I Support!
yindo commented 2026-02-16 17:41:26 -05:00
Author
Owner
Copy Link
Copy Source

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

+1 on this. This is the right approach.

Currently plugins can export tool, but not skill. The inconsistency is frustrating when you want to distribute a complete package (skill + supporting tools + hooks).

Related issues:

Both of those would be unnecessary if we just add skill to the plugin return type:

export const MyPlugin: Plugin = async (ctx) => {
return {
skill: {
"my-skill": skill({ ... })
},
}
}
This keeps the plugin system as the single distribution mechanism for all OpenCode extensions, which is much cleaner than having separate systems for tools vs skills vs commands.

Any updates on this? Would love to see it prioritized.

@thdxr, do you have any thoughts on this proposal?

@kvnwolf commented on GitHub (Jan 16, 2026): > +1 on this. This is the right approach. > > Currently plugins can export `tool`, but not `skill`. The inconsistency is frustrating when you want to distribute a complete package (skill + supporting tools + hooks). > > Related issues: > > * [[FEATURE]: Plugin Hook for Registering Additional Config Directories #6347](https://github.com/anomalyco/opencode/issues/6347) proposes a hook for registering config directories (workaround) > * [[FEATURE]: Skill Registry + Installer for Awesome-Claude-Skills (Make OpenCode the One Tool) #8386](https://github.com/anomalyco/opencode/issues/8386) proposes a completely new Skill Registry system (overkill IMO) > > Both of those would be unnecessary if we just add `skill` to the plugin return type: > > export const MyPlugin: Plugin = async (ctx) => { > return { > skill: { > "my-skill": skill({ ... }) > }, > } > } > This keeps the plugin system as the single distribution mechanism for all OpenCode extensions, which is much cleaner than having separate systems for tools vs skills vs commands. > > Any updates on this? Would love to see it prioritized. @thdxr, do you have any thoughts on this proposal?
yindo commented 2026-02-16 17:41:26 -05:00
Author
Owner
Copy Link
Copy Source

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

I've opened a PR that implements this: #9010

Instead of a programmatic skill() builder, the implementation uses an array of paths (with glob support):

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

This approach is simpler and lets plugins bundle existing SKILL.md files without requiring changes to the skill format. Paths are relative to the plugin file.

Would love feedback from the community!

@kvnwolf commented on GitHub (Jan 16, 2026): I've opened a PR that implements this: #9010 Instead of a programmatic `skill()` builder, the implementation uses an array of paths (with glob support): ```typescript export const MyPlugin: Plugin = async () => ({ skill: ['./skills/pdf', './skills/docs/*'] }) ``` This approach is simpler and lets plugins bundle existing SKILL.md files without requiring changes to the skill format. Paths are relative to the plugin file. Would love feedback from the community!
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#3776
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?