Is there any specific reason the CLI doesn't suppo...
# proj-cli
a
Is there any specific reason the CLI doesn't support organization skills? How would we fill about implementing org skills the same way as GUI? (Cloning into a temp dir on conversation init and loading into memory) Possibly with a flag to allow, not allow, always allow specific orgs
c
It may have been lost in the V1 rebuild, and I think maybe I've seen we had some hesitation how needed they were
I would welcome a PR to the SDK if you wish 🤔 The way the rest work is like,
load skills from x
is implemented in the SDK, and then the CLI uses it with a boolean flag
Or maybe we might already have - or should have - a method to literally give a repo
e.g. run CLI with
openhands --with-skills "owner/repo"
if that makes sense? Just brainstorming a bit
a
I can lift what the GUI does which is pull to a temp folder -> load into memory -> delete temp folder But I also don’t want to slow down the CLI speed
nod 1
Yea, also maybe we could just provide a skills list which are links and we maintain them on the users machine? With a skill update or something
Like you said in the other thread
c
Yes, for other reasons than org, even, I feel some kind of references list... makes a lot of sense - there's a bit of a void we need to fill
a
Yea makes sense - I'll mess around with it Right now the biggest items I'm trying to figure out is User Org Project Levels of skills and MCPs
c
Sorry to jump to this too, are you familiar with the "plugins" a la Claude Code?
a
Only by name - I just moved to Claude this weekend (over codex)
c
I think what people are working on, is to make plugins and marketplaces work - specification is compatible with Claude Code definitions, and we have some extensions. As far as I know, the fundamentals are implemented, so this could also work maybe like: • write a simple json to define a "marketplace" - it has references to plugins • package the Skills you want in a plugin (or more, whatever makes sense to you) - again it's a simple json to say where it is, I think • then reference the marketplace/plugin -> a one-liner should be enough
openhands --plugin m/plugin
or something Or maybe even ignore the marketplace, and
openhands --plugin plugin_ref
A "plugin" is simply a way to package Skills, MCP configs, slash commands, hooks
a
This makes sense - so effectively create a marketplace for your organization (which can be private) and then put all our skills in their Kinda like a homebrew tap
Looks like @chilly-france-44439 already has PR drafts for sdk and cli plugin support
c
👀 1
a
c
Just a side thought I'd like to add: in my view, as of now, Agentskills are much more useful, much more widespread, than plugins. And they're not alike: • Agentskills (and MCPs) are an open standard, and seem "everywhere" • while plugins is an Anthropic attempt, which may or may get changed, "shipped" or "unshipped", may or may not get enough buy-in in general from people In other words, I feel it might still be useful anyway to support org Agentskills or random Agentskills references, not "require" to go through plugins. They're not mutually exclusive IMHO... That said, a "plugin" is the most lightweight packaging ever: just a directory, with sub-directory "skills" / other sub-dirs 😅
a
Yea, looks really simple Will still need to figure out how to support dynamic scope mcps as well https://code.claude.com/docs/en/mcp#project-scope
c