Repository navigation
feat: Pulling/Purging collections #3113
Description
Inspired by @Cluster444's agentic.
These features would be useful (GH the default server, otherwise OPENCODE_COLLECTION_SERVER):
opencode pull gituser/gitrepo --collection=ide --vendor=openai --global
This installs to global config (project config without --global):
agent/ide.md
agent/ide/tickets.md
....
command/ide/default.md
command/ide/ticket.md
...
rule/ide/*
tool/ide/*
plugin/ide/*
These files would need to be zipped so they could be unpacked reliably, so this could be a requirement for the repo maintainer to prepare (i.e does not require a git server, just any HTTP/S server):
server.com/gituser/gitrepo/ide-<vendor>.zip
# Or whenever the collection is vendor agnostic:
# server.com/gituser/gitrepo/ide-generic.zip
# When both files exist:
# - unpack *-generic.zip first.
# - unpack *-<vendor>.zip to overwrite relevant generic files.
The opencode purge gituser/gitrepo --collection=ide --vendor=openai --global would simply be to delete the above pattern of files.
Here command/ide/default.md is a convention that prevents clobbering an existing command/ide.md, the duplicate would be called as /ide/ide. Same convention could be applied for agents if agent/ide.md already existed.
Or just error out before unpacking the collection?
Not sure if you want to consider this directly or wait and see where/how @Cluster444's agentic evolves?
Activity
github-actions commentedon Oct 12, 2025
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
rekram1-node commentedon Oct 12, 2025
opencode will eventually have a way to manage plugins, agents, etc all really easily. The team also owns the
agents.devdomain so more to come heretaqtiqa-mark commentedon Oct 12, 2025
Just to be clear, the idea here is deliberately formulated to avoid such centralized sources.
Think of it as in line with the local-first/distributed ethos.
rekram1-node commentedon Oct 12, 2025
I think what im saying is that once we have better support to make all this easy, it'd be simple to point it wherever you wanted and it'd be easy to manage
We could have a centralized list so you can search them but ultimately you can install any plugin from npm so it wouldn't stop you from installing a completely custom private plugin for your org
TLDR: it shouldn't be locked to a centralized source and it will be easier to manage these things in near future
taqtiqa-mark commentedon Oct 12, 2025
Thanks for considering this.
Right now my itch is
agent/*andcommand/*content.My use of plugins will have to wait, if ever.... I really don't want to have to learn npm packaging (esp. the gnarly little residual corner cases AI doesn't catch) just to customize the LLM behavior.
I think 80% of use cases are covered outside of plugins, and for those cases vanilla zip files are just-fine?
rekram1-node commentedon Oct 12, 2025
You dont need to, i was just saying you could use other peoples plugins by listing an npm package in your config
taqtiqa-mark commentedon Oct 12, 2025
Won't I have to if I want to distribute my own non-plugin files?
taqtiqa-mark commentedon Oct 12, 2025
Any way its not critical, there is already @Cluster444's
agentictool, or some other overlay if that experiment doesn't work.I'll close this since you already have something on the roadmap, and it is substantively not what this proposal had in mind.
Cluster444 commentedon Oct 12, 2025
This will be likely be a little bit tricky to implement because it's very easy to end up degrading the model with context pollution.
My feeling right now is to give package management concepts some time until the ecosystem matures. Otherwise you're likely going to be depreciating whole solutions as things change.
As for agentic. Even that is an evolution of someone else's work that I have already superseded. I think that workflow is a step up from basic prompts, but there's more missing here that agents and commands aren't good solutions for.
taqtiqa-mark commentedon Oct 12, 2025
Agreed, as I said:
But it is useful to track the direction of things, and especially when things are moving fast it helps to have a shared effort, even if things fork quickly.
Not sure how open you are to agentic moving in the direction I outlined (zipped collections)? If it appeals open an issue and ping me I'll follow there.
Agreed, see #3112 for a discussion.