TL;DR don't have your agent write skills using only its latent knowledge, otherwise you may as well not use a skill in the first place and let it summon that latent knowledge on the fly.
Not sure if this take is correct though. I suspect self-generated skills help the agent avoid having to "decompress" its latent knowledge, which might save tokens? idk, I am not an expert
I've been able to avoid this kind of markdown library architecture with very chatty tool feedback. Interaction with a responsive environment is much better than static chunks of "skill" text. For example, imagine a domain constraint:
"You must use tool ABC before calling tool XYZ"
This can either be in some static prompt scheme somewhere, or it can be the live result of a tool call.
If you make everything tool calling and environmental, you effectively have a lazily evaluated & dynamic prompt scheme.
I like to think of this as context for the context. The better you map the environment and descriptions of it to the agent, the less top-down prompting is required.
If you set up the harness correctly, you can run circles around a lot of what passes as AI innovation with powershell in a while loop. Adding static markdown document soup on top of this would only reduce performance in the general case.
A good agent and harness should notice that an instruction like "You must use tool ABC before calling tool XYZ" is best implemented as a pretooluse hook
I read this post thinking "Finally! Finally someone will explain to me what I've been missing because 'skills' just seem to be re-usable text that help make prompting faster."
yeah, thats what they are, but thats useful! you have an agents.md, that gets put into every conversation. But studies and experience both show that as that gets longer, the agent becomes less capable. so instead of telling it everything useful under the sun, you put only really important things there, and the rest of the advice for common but not every time actions you put into skills. I personally have like, 5 skills. one that works with the database, and has a bunch of context about the schema, how to connect and work with documents, example queries written just how I like them (and pre-written with filters to reduce the risk of ai ingesting a million rows worth on tokens for no reason), a python script I wrote to do certain common operations and how to use it for different tasks.
So in essence, the ideal skill imo is pretty much a list of shell commands with a sentence next to each of when to use them
With these, I personally have skills for:
- dealing with our metrics and tracing platform
- dealing with jira
- dealing with confluence (mostly finding info I need via different search strategies without using too many tokens)
- dealing with database
- doing reviews (this one is more prompting about what info I need to review well myself, rather than commands, though it does instruct the agent to download the branch into a new worktree and clean it up after its done with specific commands)
Im generally suspicious of people with hundreds of skills, especially those I open and find ai generated writing inside. skills should be a list of commands, maybe with some pitfalls for the agent to avoid, added only by human experience (agents are terrible at prompting)
It always feels a bit vexing when people complain about skills: Personally, we treat them as if manuals where the goal is to patch knowledge, not (typically) be a from-scratch primer.
Letting an instruction following llm deep research and iterate has given fantastic results before.
Being able to construct non-trivial Zig 0.16 programs without slowing down for version-hallucinating compilation errors is nice as a random example.
The solution: you have to beat the AI agents like you did the cow avatar in Black and White because it watered the fields while the temple was on fire :DDD.
The article assumes that the skills need to be used by the same model. If a model like Opus develops a skill that is then used by another model like Qwen3.6, that feels like it could also add value.
15 comments
[ 3.2 ms ] story [ 36.4 ms ] threadNot sure if this take is correct though. I suspect self-generated skills help the agent avoid having to "decompress" its latent knowledge, which might save tokens? idk, I am not an expert
Eg. Ask the agent to write a skill then get it to prompt a subagent to use the skill, then iterate until it verifies the task was completed correctly
"You must use tool ABC before calling tool XYZ"
This can either be in some static prompt scheme somewhere, or it can be the live result of a tool call.
If you make everything tool calling and environmental, you effectively have a lazily evaluated & dynamic prompt scheme.
I like to think of this as context for the context. The better you map the environment and descriptions of it to the agent, the less top-down prompting is required.
If you set up the harness correctly, you can run circles around a lot of what passes as AI innovation with powershell in a while loop. Adding static markdown document soup on top of this would only reduce performance in the general case.
Nope. Still the same.
So in essence, the ideal skill imo is pretty much a list of shell commands with a sentence next to each of when to use them
With these, I personally have skills for:
- dealing with our metrics and tracing platform
- dealing with jira
- dealing with confluence (mostly finding info I need via different search strategies without using too many tokens)
- dealing with database
- doing reviews (this one is more prompting about what info I need to review well myself, rather than commands, though it does instruct the agent to download the branch into a new worktree and clean it up after its done with specific commands)
Im generally suspicious of people with hundreds of skills, especially those I open and find ai generated writing inside. skills should be a list of commands, maybe with some pitfalls for the agent to avoid, added only by human experience (agents are terrible at prompting)
Letting an instruction following llm deep research and iterate has given fantastic results before.
Being able to construct non-trivial Zig 0.16 programs without slowing down for version-hallucinating compilation errors is nice as a random example.