I had a discussion with <@U06QJHRBLQG> in a privat...
# proj-agent
l
I had a discussion with @chilly-france-44439 in a private thread, but I’m wondering what people think about deprecating our old way of doing skills/microagents and just going with the agentskills standard. (the other option is to try to support both) There’s some discussion on this thread by JM created: https://github.com/OpenHands/software-agent-sdk/issues/1452 Pro of supporting only agentskills: • supporting one standard is much easier than supporting 2. it would make the implementation and explanation much easier • there’s more functionality in here that we don’t have Con: • existing openhands users will have to migrate (by moving each skill md file into a directory, at least) • there is one piece of functionality that would be missing -- triggers (but we could possibly support that as an extension) @wooden-umbrella-84098 and @chilly-france-44439 what do you think? I’d lean towards supporting only agentskills, but could go either way.
q
Is it possible to do just agent skills and also support triggers via some kind of hook/tool ?
l
Yeah, we could also support triggers as an extension to the agent skills standard. The biggest conceptual change is that in agentskills standard the skills are a directory, where in our case the skills can be a single markdown file (edited the above to clarify this)
👍 1
c
existing openhands users will have to migrate (by moving each skill md file into a directory, at least)
I wonder if we keep a backward compatibility mode (i.e., we still load the old skills and convert to the latest agentskills standard, and throw a warning?)
✅ 1
i.e., 1. We rewrite the
Skill
class from scratch based on the agent skills standard a. plus the trigger feature 2. We rename the current
Skill
to
LegacySkill
and offer a conversion function to convert it to the
Skill
standard Upon load time, we first try to load markdowns as
Skill
, if it fails we fall back to
LegacySkill
and throw a warning? WDYT?
q
Only concern is that for saas users it wont be obvious since the warning logs will be hidden
c
I think we probably won't deprecate the old ways any time soon? We could offer a migrate feature that migrate them from old to new format (just add a few field to frontmatter & put it in a folder, which should be straight forward enough
q
OK! would that work for skills sitting inside github repos thonk Regardless agent skills only seems like a good idea imho!
l
I already wrote the Skill class to support the agentskills standard I think
🙌 1
It wasn’t too hard, there’s a lot of overlap between the two.
I’m mostly thinking about loading, but I’m implementing the loading now and I was mostly able to separate it into agentskills and legacy codepaths. I think probably we can keep it supported but remove it from our docs, then gradually fade it out
c
I do think the other side of this, the ‘repo’ skills, we could migrate them to
AGENTS.md
Those are expected fully in context, as opposed to progressive loading, from what I understand
@chilly-france-44439 for this > I think we probably won't deprecate the old ways any time soon? We could offer a migrate feature that migrate them from old to new format (just add a few field to frontmatter & put it in a folder, which should be straight forward enough Do we need the user to do it, or could we maybe have a
migrate
that puts the files in their own directories, contents in SKILL.md, and insert in prompt name/a sentence description? (with notification, warnings etc) Thinking that if it’s possible, maybe we could continue writing code only for agentskills from there 🤔
b
👋 (if my questions are based on flawed premises or my missing context, feel free to drop link and move on, ty) what about interop for folks who are experimenting or in environments where they need to go back and forth? say my work has a flexible policy and we can use whatever - and my buddy Anna has a directory of AgentSkills that they shared with me. Based on the AgentSpec PR, it seems this would just work with a clone/copy/whatever into the .plugins directory. Would the Skills I create in my openhands workspace be as easy for her to use? Phase 1 portability shows the AgentSkills -> .plugin 'it just works' requirement, but what about the other way? (eg if i need to support a skill being cross-compatible, would it be easier for me to build/test/deploy in my OpenHands context first - or in Anna's AgentSkills-other context?)
l
Hey @big-hydrogen-55184, no, this is a good question! I think that interop is a strong argument for supporting only the agentskills standard, especially because it’s becoming a standard. And @calm-artist-7206, great point, we could also provide a migration script or prompt
c
Yes, when you can create/use an AgentSkill in openhands, that can be copied anywhere supports AgentSkills and the reverse
b
🍰 if i can achieve everything in OpenHands that I can in the other kit, and I can do more - (phase 2 work) - then that domain is stickier. also, if the work i'm doing there is helping me get better at AgentSkills spec - then it's a dual-thread investment of time, yeah? 🔥
👍 1
c
Maybe we could look at it this way, please shut it down if missing something: • Agentskill (extended) ◦ with openhands triggers would mean: • loaded as Agentskill • from new format, or old openhands format (via migrate) • can be triggered by user message (keyword) • can be called by agent (name/description in prompt)
w
Yes I think standardizing on AgentSkills is a good idea. I'd just want to stay backward compat with people who already built microagents, e.g. by converting them to skills on the fly
👍 1
c
I do think the other side of this, the ‘repo’ skills, we could migrate them to
AGENTS.md
I think this is a good idea! But ideally we'd still need to support the old format and it can be pretty messy to use over time 😞 .. It seems like if we decide to do this, we should build extended "agentskill" (basically what @calm-artist-7206 shared), and map our existing skills: •
repo
skills ->
AGENTS.md
•
knowledge
(keyword triggered) skills ->
agentskills
standard w/ additional capability of trigger on "keywords"