(implemented) skills.md

[michaelneale]

NOTE: skills were implemented in goose and are supported in it. This discussion was proposal for it, kept for historical purposes and discussion.

Claude and anthropic have implented this very simple extension model called Skills: https://code.claude.com/docs/en/skills

which seem very suited for inrepo sharing or even (especially) personalisation. It is very roughly a SKILLS.md and potential optional supporting scripts, which are not loaded until they are needed, and then progressively loaded to keep the context small .

These are:

• lightweight (no context impact)
• trivial to author (can just write markdown)
• local first (you put it in a dir)

They seem to have some popularity, so if they are taking off, it is easy enough to implement it in goose:

• look in ~/.claude/skills or ~/.config/goose/skills, as as well as working_dir .goose/skills or .claude/skills
• have a platform extension which will load the skill, only when needed (and only minimally)
• platform extension will only have the "front matter" yaml in the context (tiny) just so it is aware of the skill, as per "spec" for skills
• this can be done baked right into goose, similar to todo, chatrecall (so you can have it off if not needed).

It was easier to implement to try for me than spend too much time further analyzing:

#5760

shows how it can work (you can build it, and add a skill to ~/.claude/skills or ~/.config/goose/skills etc) - if you already use claude it will automatically pick them up and should work the same.

[cbruyndoncx]

I was thinking a recipe is an advanced version of skills as a concept implemented in yaml not markdown and frontmatter, but more advanced in its (repo) shareing abilities for team use.
What i miss is having the recipe more dynamic in session.

[michaelneale]

I think difference with recipes is that skills are closer to mcps - ie they are always available, but with recipe, you pick it up front based on the task, and for that session it brings along what it can do. (ie you dont' dynamically load it).

In that sense, skills are basically mini-mcps or mini-tools IMO. Could make an argument that could be unified with recipes, as a format, so the recipe name/description is available and then on demand, goose loads it into context (which would basically be same functionally as SKILL.md - but yaml) - if that makes sense @cbruyndoncx ?

[cbruyndoncx]

yes, that is basically what i meant

[michaelneale]

I guess benefit of the .md approach is - people alredy doing it, its a common format (!), vs yaml, for this (but we could support both, recipes as skills as well as recipes) - but was mostly thinking about the pool of skills people are already building up out there, but can see both, love your thought on it.

[cbruyndoncx]

Have you looked at Gemini extensions ? I think we need a 'compatibility mode' to understand whatiswhat ...

[michaelneale]

no have not.
are they good? something to learn from?

skills seem very lightweight extensions, are gemini extensions like that?

[cbruyndoncx]

Google seems to use extensions for own first party connections as well as mcp servers, now too. I need to play a bit more with the google ecosystem of tools to understand it better.

[michaelneale]

@cbruyndoncx worth including SKILLS.md extension for goose in meantime or need more time to research?

[BenceBakos]

This is very similar to what I've been looking for. There are certain kind of tasks, you can make a recipe of, but sometimes I would love to see goose invoke a recipe without me asking explicitly. It could very easily make the decision of "oh, I can delegate this, gime the results when you are done". sooner or ater every daily task I have could get a recipe, and the main, ainteractive goose session would just be an orchestrator of these recipe calls.

[BenceBakos]

https://block.github.io/goose/docs/guides/context-engineering/using-skills

[michaelneale]

BTW skills are now part of goose - not sure if we should close discussion or leave it as a place to chat about them?