Skip to content

[FEATURE]: Skill Registry + Installer for Awesome-Claude-Skills (Make OpenCode the One Tool) #8386

Closed
Closed
[FEATURE]: Skill Registry + Installer for Awesome-Claude-Skills (Make OpenCode the One Tool)#8386
Assignees
thdxr
Labels
discussionUsed for feature requests, proposals, ideas, etc. Open discussion

Description

@super-unique-ai
super-unique-ai
opened on Jan 14, 2026

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

TL;DR: Add a Skill Registry plus Skills Manager to OpenCode so we can browse, install, pin, update, and remove skills from curated sources, starting with ComposioHQ/awesome-claude-skills.

🔗 Links

🧠 Motivation

OpenCode already supports Agent Skills via SKILL.md discovery. What’s missing is a distribution and management layer that makes skills easy to find, install, trust, and keep updated.

awesome-claude-skills is a large catalog of practical, repeatable workflows. Integrating it would expand OpenCode beyond coding into standardized workflows for docs, spreadsheets, research, automation, and more.

❗ Problem

Current state

  • Skills are manual to install (copy folders around).
  • No built-in way to:
    • 🔎 search a catalog
    • 📥 install and remove cleanly
    • 📌 pin versions
    • 🔁 update safely
    • 🧾 show provenance and licensing

Result

  • Skills are powerful but not discoverable.
  • Keeping skills updated is annoying and error-prone.
  • Duplication increases because reuse is hard.

✅ Proposal

1) Add a Skill Registry concept

A registry is a source of skills that OpenCode can index.

Default registry (MVP):

Future optional registries:

  • Any public Git repo
  • Private repos via auth
  • npm packages (later)

Registry metadata should include:

  • skill name
  • short description
  • category tags
  • license info plus warnings
  • version info (tag or commit SHA)
  • optional trust signals (verified registry, signed tags, etc.)

2) Add a Skills Manager (CLI and TUI first)

Ship core functionality behind commands first (UI can come later after design review).

Suggested commands

/skills search <query>
/skills info <skill>
/skills install <skill> [--version <sha|tag>] [--scope user|project]
/skills update [<skill>]
/skills remove <skill>
/skills list

Install scopes

  • User scope (global)
    ~/.config/opencode/skills/<skill>/SKILL.md

  • Project scope (local, preferred default)
    .opencode/skills/<skill>/SKILL.md

This complements the existing Agent Skills discovery model.

🎯 MVP Deliverables

📚 Registry indexing

  • Fetch registry source (git clone or pull)
  • Detect skill folders containing SKILL.md
  • Build an index (name, description, tags)

📥 Install plus provenance

  • Install copies skill folder into chosen scope
  • Write a manifest file recording provenance:
    • registry source URL
    • commit SHA or tag installed
    • installed timestamp
    • installed files list (optional but ideal)

Example manifest:

{
  "source": "https://github.com/ComposioHQ/awesome-claude-skills",
  "skill": "pdf",
  "version": "a1b2c3d4",
  "installedAt": "2026-01-13T00:00:00Z",
  "scope": "project"
}

🔁 Updates

  • skills update pulls latest registry changes
  • Update re-syncs installed skills (preferably with diff preview or confirmation)
  • Preserve user edits if skills are modified locally (either warn, or require --force)

🧾 Licensing

  • Display repo license (Apache-2.0) and warn that individual skills may differ
  • Warn (or optionally block) installs when license data is missing or unclear
  • Surface license info in /skills info <skill>

🛡️ Security and Safety Considerations

Third-party skills should be treated as untrusted content by default.

Install-time confirmation should show:

  • registry source plus URL
  • pinned version (SHA or tag)
  • files to be installed
  • best-effort risk hints (heuristics):
    • filesystem access
    • shell invocation
    • network calls
    • integrations and automation

Recommended defaults

  • Prefer project scope installs to reduce unexpected global changes
  • Default to pinned installs (commit SHA) for reproducibility
  • Provide a --verify mode to show exactly what will be written before installing

🌟 Why awesome-claude-skills first

  • Large catalog, actively maintained
  • Consistent SKILL.md pattern
  • Covers high-value workflows (docs, data, automation, productivity)

Source:

✅ Acceptance Criteria

  • /skills search pdf shows results from awesome-claude-skills
  • /skills info pdf shows description, tags, license, source URL, and available versions (tag or SHA)
  • /skills install pdf --scope project installs into .opencode/skills/pdf/
  • Installed skills are discoverable and usable via OpenCode Agent Skills behavior
  • /skills install ... --version <sha|tag> pins to a deterministic version
  • /skills update updates safely and preserves provenance
  • Each installed skill includes a manifest with source plus version
  • Clear provenance plus license warnings on install

🧱 Implementation Strategy (Incremental)

  1. Registry fetch plus index
  2. Install plus manifest
  3. List and remove
  4. Update
  5. Trust model plus warnings
  6. Optional: UI layer after design review

🔁 Alternatives Considered

Manual installs (copy folders, submodules)

✅ Works for power users
❌ Not discoverable
❌ No update UX
❌ No provenance or pinning

One big bundled pack

❌ Hard to update selectively
❌ Poor provenance and attribution
❌ Doesn’t scale

🚀 Optional Path: Start as an Official Plugin

If maintainers prefer keeping core small initially, ship this as an official plugin that:

  • indexes registries
  • manages install, update, remove
  • writes into existing skills discovery paths

Then graduate parts into core once validated.

🙌 Notes for Maintainers

  • This issue is intentionally scoped to be incremental and reviewable.
  • UI can be deferred; the CLI and TUI commands provide immediate value.
  • Registry schema can start minimal and evolve (name, description, tags, license, version).

Activity

  1. super-unique-ai
    added
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    on Jan 14, 2026

  2. github-actions commented on Jan 14, 2026

    @github-actions
    github-actionsBot
    on Jan 14, 2026 – with GitHub Actions
    Contributor

    This issue might be a duplicate of or closely related to existing issues. Please check:

    This feature request goes beyond these issues by proposing a complete registry system with install, update, and version management capabilities. However, understanding these related issues may help inform implementation and prevent duplicating efforts in the UI/discovery layer.

  3. github-actions
    assigned
    thdxr
    on Jan 14, 2026

  4. super-unique-ai commented on Jan 14, 2026

    @super-unique-ai
    super-unique-ai
    on Jan 14, 2026
    Author

    This issue might be a duplicate of or closely related to existing issues. Please check:

    This feature request goes beyond these issues by proposing a complete registry system with install, update, and version management capabilities. However, understanding these related issues may help inform implementation and prevent duplicating efforts in the UI/discovery layer.

    No, This is a new feature request.

  5. n-pll commented on Jan 14, 2026

    @n-pll
    n-pll
    on Jan 14, 2026

    Looking forward to this feature

  6. kvnwolf commented on Jan 16, 2026

    @kvnwolf
    kvnwolf
    on Jan 16, 2026

    I think we're overcomplicating this. OpenCode already has a distribution mechanism that works: plugins via npm.

    Before creating a parallel Skill Registry system, we should consider that this problem has already been raised in:

    The simpler solution: let plugins export skills the same way they already export tools.

    import { type Plugin } from "@opencode-ai/plugin"

export const MyPlugin: Plugin = async (ctx) => {
  return {
    // This already works
    tool: {
      myTool: tool({ ... }),
    },
    
    // This should also work
    skill: {
      "pdf": skill({ ... }),
    },
  }
}

    Benefits over a separate Skill Registry:

    • No new infrastructure - npm IS the registry
    • Consistent model - one mechanism for all extensions
    • Composability - a plugin can bundle skills + complementary tools + hooks together
    • Already familiar - developers know npm, no new commands to learn

    The /skills install UX is nice, but it's essentially duplicating what "plugin": ["package-name"] in opencode.json already does.

    I'd suggest focusing effort on #6013 and #6347 first, which would solve this problem without adding a parallel system.

  7. kvnwolf commented on Jan 17, 2026

    @kvnwolf
    kvnwolf
    on Jan 17, 2026

    As an alternative to a full Skill Registry system, I've opened a PR that extends the existing plugin mechanism: #9010

    Plugins can now bundle skills:

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

    This keeps npm as the distribution mechanism and allows plugins to package skills + tools + hooks together. It's a simpler foundation that could later support a discovery layer like the one proposed here.

    Would appreciate feedback from the community!

  8. TomLucidor commented on Jan 20, 2026

    @TomLucidor
    TomLucidor
    on Jan 20, 2026

    How many registries are there on GitHub for Claude Code? Seems like there are at least a dozen that are used by many?

  9. wang-silas commented on Jan 21, 2026

    @wang-silas
    wang-silas
    on Jan 21, 2026

    How about reuse claude plugin marketplaces? Plugins Document for Claude

  10. github-actions commented on Mar 28, 2026

    @github-actions
    github-actionsBot
    on Mar 28, 2026 – with GitHub Actions
    Contributor

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

  11. github-actions
    closed this as completedon Mar 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

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

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions