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

Activity

1. wch-abc

   added

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   on Dec 23, 2025
2. github-actions

   assigned

   thdxr

   on Dec 23, 2025
3. github-actions commented on Dec 23, 2025

   

   github-actionsBot

   on Dec 23, 2025 – with GitHub Actions

   Contributor

   More actions

   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.
4. kvnwolf commented on Jan 16, 2026

   

   kvnwolf

   on Jan 16, 2026

   More actions

   +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 proposes a hook for registering config directories (workaround)
   • [FEATURE]: Skill Registry + Installer for Awesome-Claude-Skills (Make OpenCode the One Tool) #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.

   👍React with 👍1Reacted by Chief Technology Officer

   😄React with 😄1Reacted by Chief Technology Officer

   🎉React with 🎉1Reacted by Chief Technology Officer

   😕React with 😕1Reacted by Chief Technology Officer

   ❤️React with ❤️1Reacted by Chief Technology Officer

   🚀React with 🚀1Reacted by Chief Technology Officer

   👀React with 👀1Reacted by Chief Technology Officer
5. super-unique-ai commented on Jan 17, 2026

   

   super-unique-ai

   on Jan 17, 2026

   More actions

   +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 proposes a hook for registering config directories (workaround)
   • [FEATURE]: Skill Registry + Installer for Awesome-Claude-Skills (Make OpenCode the One Tool) #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!

   👍React with 👍1Reacted by Chief Technology Officer

   🚀React with 🚀2Reacted by Chief Technology Officer and Kevin Wolf

   👀React with 👀1Reacted by Chief Technology Officer
6. kvnwolf commented on Jan 17, 2026

   

   kvnwolf

   on Jan 17, 2026

   More actions

   +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 proposes a hook for registering config directories (workaround)
   • [FEATURE]: Skill Registry + Installer for Awesome-Claude-Skills (Make OpenCode the One Tool) #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?

   👍React with 👍1Reacted by Chief Technology Officer

   🚀React with 🚀1Reacted by Chief Technology Officer

   👀React with 👀1Reacted by Chief Technology Officer
7. kvnwolf commented on Jan 17, 2026

   

   kvnwolf

   on Jan 17, 2026

   Last edited by kvnwolf

   More actions

   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!

   👍React with 👍2Reacted by wch789 and jeremysamuel13
8. thdxr commented on Mar 25, 2026

   

   thdxr

   on Mar 25, 2026

   Member

   More actions

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

   closed this as completedon Mar 25, 2026