alt Hacker NewsIt seems to me that skills are:
1. A top level agent/custom prompt
2. Subagents that the main agent knows about via short descriptions
3. Subagents have reference files
4. Subagents have scripts
Anthropic specific implementation:
1. Skills are defined in a filesystem in a /skills folder with a specific subfolder structure of /references and /scripts.
2. Mostly designed to be run via their CLI tool, although there's a clunky way of uploading them to the web interface via zip files.
I don't think the folder structure is a necessary part of skills. I predict that if we stop looking at that, we'll see a lot of "skills-like" implementations. The scripting part is only useful for people who need to run scripts, which, aside from the now built in document manipulating scripts, isn't most people.
For example, I've been testing out Gemini Enterprise for use by staff in various (non-technical) positions at my business.
It's got the best implementation of a "skills-like" agent tool I've seen. Basically a visual tree builder, currently only one level deep. So I've set up the "<my company name> agent" and then it has subagents/skills for thing like marketing/supply chain research/sysadmin/translation etc., each with a separate description, prompt, and knowledge base, although no custom scripts.
Unfortunately, everything else about Gemini Enterprise screams "early alpha, why the hell are you selling this as an actual finished product?".
For example, after I put half a day into setting up an agent and subagents, then went to share this with the other people helping me to test it, I found that... I can't. Literally no way to share agents in a tool that is supposedly for teams to use. I found one of the devs saying that sharing agents would be released in "about two weeks". That was two months ago.
Mini rant over... But my point is that skills are just "agents + auto-selecting sub-agents via a short description" and we'll see this pattern everywhere soon. Claude Skills have some additional sandboxing but that's mostly only interesting for coders.
Replies
Looking for a way to do this with ADK as well, looks like skills can be a sweet spot between giant instruction and sprawling tools/subagents.
I have found that scripts, and the environment that runs them, are the skills' superpower.
Computability (scripts) means being able build documents, access remote data, retrieve data from packaged databases and a bunch of other fundamentally useful things, not just "code things". Computability makes up for many of the LLM's weaknesses and gives it autonomy to perform tasks independently.
On top of that, we can provide the documentation and examples in the skill that help the LLM execute computability effectively.
And if the LLM gets hung up on something while executing the skill, we can ask it why and then have it write better documentation or examples for a new skill version. So skills can self-improve.
It's still so early. We need better packaging, distribution, version control, sharing, composability.
But there's definitely something simple, elegant, and effective here.