Skills in CC have been a bit frustrating for me. They don't trigger reliably and the emphasis on "it's just markdown" makes it harder to have them reliably call certain tools with the correct arguments.
The idea that agent harnesses should primarily have their functionality dictated by plaintext commands feels like a copout around programming in some actually useful, semi-opinionated functionality (not to mention that it makes capability-discoverability basically impossible). For example, Claude Code has three modes: plan, ask about edits, and auto-accept edits. I always start with a plan and then I end up with multiple tasks. I'd like to auto-accept edits for a step at a time and the only way to do that reliably is to ask CC to do that, but it's not reliable—sometimes it just continues to go into the next step. If this were programmed explicitly into CC rather than relying on agent obedience, we could ditch the nondeterminism and just have a hook on task completion that toggles auto-complete back to "off."
PantaloonFlames 17 minutes ago [-]
You can publish scripts with skills you author, right? With carefully constructed markdown that should allow the agent to call tools the right way.
RyanShook 10 minutes ago [-]
So far my experience with skills is that they slow down or confuse agents unless you as the user understand what the skill actually contains and how it works. In general I would rather install a CLI tool and explain to the agent how I want it used vs. trying to get the agent to use a folder of instructions that I don't really understand what's inside.
airstrike 4 minutes ago [-]
[delayed]
ms170888 1 hours ago [-]
[flagged]
naillang 1 hours ago [-]
[flagged]
chasd00 6 minutes ago [-]
> is there a mechanism to pin a version, or is it always HEAD? Skills that evolve can silently break downstream workflows.
don't forget these skills are just text that goes into the llm for it to read, interpret, and then produce text that then gets executed in bash. The more intricate and specific the skill definition the more likely the model is to miss something or not follow it exactly.
I actually think SKILLS.md is such a janky way of doing this sort of thing, let alone the fact that's reliant on the oh-so-brittle Python ecosystem. Also way too much context/tokens being eaten up by something that could be piece-wise programmatically injected in the token stream.
Imo a bad idea, but alas.
PantaloonFlames 16 minutes ago [-]
Wait - how are skills dependent on python?
Isn’t python just an option ?
dvt 7 minutes ago [-]
It is, but to do the "useful" stuff, it's more or less mandatory. Either Python or bash scripts (which are equally as janky tbh).
armcat 1 hours ago [-]
I think you are spot on there, and I am not sure such things exist (yet), but I may be wrong. Some random thoughts:
1. Using the skills frontmatter to implement a more complex YAML structure, so e.g.
Except they're still not accepting any feedback around AGENTS.md as a standard. You need to explicitly symlink CLAUDE.md to AGENTS.md in a workspace in order to Claude to work like every other agent when it comes to loading context.
Rendered at 20:28:35 GMT+0000 (Coordinated Universal Time) with Vercel.
The idea that agent harnesses should primarily have their functionality dictated by plaintext commands feels like a copout around programming in some actually useful, semi-opinionated functionality (not to mention that it makes capability-discoverability basically impossible). For example, Claude Code has three modes: plan, ask about edits, and auto-accept edits. I always start with a plan and then I end up with multiple tasks. I'd like to auto-accept edits for a step at a time and the only way to do that reliably is to ask CC to do that, but it's not reliable—sometimes it just continues to go into the next step. If this were programmed explicitly into CC rather than relying on agent obedience, we could ditch the nondeterminism and just have a hook on task completion that toggles auto-complete back to "off."
don't forget these skills are just text that goes into the llm for it to read, interpret, and then produce text that then gets executed in bash. The more intricate and specific the skill definition the more likely the model is to miss something or not follow it exactly.
For example, on Proposal: AgentFile — Declarative Agent Composition from Skills + Filesystem-Native Skill Delivery
https://github.com/agentskills/agentskills/discussions/179
Imo a bad idea, but alas.
Isn’t python just an option ?
1. Using the skills frontmatter to implement a more complex YAML structure, so e.g.
2. Using a skills lock file ;-)