There's a pattern I keep seeing: LLMs used to replace things we already know how to do deterministically. Parsing a known HTML structure, transforming a table, running a financial simulation. It works, but it's like using a helicopter to cross the street: expensive, slow, and not guaranteed to land exactly where you intended.
The real opportunity with Agent Skills isn't just packaging prompts. It's providing a mechanism that enables a clean split: LLM as the control plane (planning, choosing tools, handling ambiguous steps) and code or sub-agents as the data/execution plane (fetching, parsing, transforming, simulating, or executing NL steps in a separate context).
This requires well-defined input/output contracts and a composition model. I opened a discussion on whether Agent Skills should support this kind of composability:
The same applies to context vs a database. If a reasoning model makes a decision about something, it should be put off to the side and stored as a value/variable/entry somewhere. Instead of using pages and pages of context, it makes sense for some tasks to "press" decisions that become more permanent to the conversation. You can somewhat accomplish that with notebooklm, by turning results into notes into sources, but notebooklm is insular and doesnt have the research and imaging features of gemini.
And also, in writing, writing from top to bottom has its disadvantages. It makes sense to emulate human writing process and have passes, as you flesh out, and conversely summarize writing.
Current LLMs can brute force these things through emulation/observation/mimicry but they arent as good as doing it the right way. Not only would I like to see "skills" but also "processes" where you create a well defined order that tasks are accomplished in sequence. Repeatable templates. This would essentially include variables in the templates, set for replacement.
I've recently been doing some work with Autodesk. It would be great for an LLM to be as comfortable with the "vocabulary" of these applications as they are with code. Maybe part of this involves creating a language for CAD design in the first place. But the principle that we need to build out vocabularies and subsequently generate and expose "sentences" (workflows) for LLM's to train on seems like a promising direction.
Of course this requires substantial buy in from application owners - create the vocabulary - and users - agree to expose and share the sentences they generate - but the results would be worth it.
Additionally, I can't even get claude or codex to reliable use the prompt and simple rules (use this command to compile) in an agents.md or whatever required markdown file is needed. Why would I assume they will reliably handle skills prompts spread about a codebase?
I've even seen tool usage deteriorate while it's thinking and self commanding through its output to say.. read code from a file. Sometimes it uses tail while other times it gets confused on the output and then writes a basic python program to parse lines and strings from the same file to effectively get what was the same output as before. How bizarre!
Skills are about empowering LLMs with tools, so the heavy lifting can still be deterministic. Furthermore, pipelines written in LLMs are simpler and less brittle, since handling variation is the essence of machine learning.
Isn't atleast part of that GH issue something that this https://docs.boundaryml.com/guide/introduction/what-is-baml is also trying to solve? LLM inputs and outputs must be functions with defined functions. That was their starting point.
IIUC their most recent arc focuses on prompt optimization[0] where you can optimize — using DSPy and an optimization algo GEPA [1] — using relative weights on different things like errors, token usage, complexity.
Where in this post's article are you seeing this pattern?
> Parsing a known HTML structure
In most cases, HTML structures that are being parsed aren't known. If they're known, you control them, and you don't need to parse them in the first place. If they're someone else's, who knows when they'll change, or under what condition they're different.
But really, I don't see the stuff you're talking about happening in prod for non-one-off usecases. I see LLMs used in prod usecases exactly for data where you don't know exactly what its shape will be, and there's an enormous amount of such cases. If the same logic is needed every time, of course you don't have an LLM execute that logic, you have the LLM write a deterministic script.
Skills are essentially boiling down to distributed parts of a Main Prompt. If you consider a state model you can see this pattern: Task is the state and combining the task's specifics skills defines the current prompt augmentation. When the task changes, another prompt emerges.
In the end, it is the clear guidance of the Agent that is the deciding factor.
> Parsing a known HTML structure, transforming a table, running a financial simulation.
Transforming an arbitrary table is still hard, especially a table on a webpage or in a document. Sometimes I even struggle to find the right library. The effort does not seem worth it for one-off need of such transformation too. LLM can be a great tool for doing the tasks.
How likely are we to look back on Agent/MCP/Skills as some early Netscape peculiarity? I would dive into adoption if I didn't think some new thing would beat the paradigm in a fortnight.
I've built a number of MCP servers, including an MCP wrapper. I'd generally recommend you skip it unless you know you need it. Conversely, I'd generally recommend you write up a couple skills ASAP to get a feel for them. It will take you 20 minutes to write and test some.
MCP does three things conceptually: it lets you build a bridge between an agent and <something else>, it specifies a UI+API layer between the bridge and the LLM, and it formalizes the description of that bridge in a tool-calling format.
It's that UI+API layer that's the biggest pain in the ass, in my opinion. Sometimes you need it; for instance, if you wanted an agent to access your emails, a high quality MCP server that can't destroy your life through enthusiastic tool calling makes sense.
If, however, you have, say a CLI tool or simple API that's reasonably self documenting and you're willing to have it run, and/or if you need specific behavior with a different context setting, then a skill can just be a markdown file that explains what, how, why.
Agent/MCP/Skills might be "Netscape-y" in the sense that today's formats will evolve fast. But Netscape still mattered: it lost the market, not the ideas. The patterns survived (JavaScript, cookies, SSL/TLS, progressive rendering) and became best practices we take for granted.
The durable pattern here isn't a specific file format. It's on-demand capability discovery: a small index with concise metadata so the model can find what's available, then pull details only when needed. That's a real improvement over tool calling and MCP's "preload all tools up front" approach, and it mirrors how humans work. Even as models bake more know-how into their weights, novel capabilities will always be created faster than retraining cycles. And even if context becomes unlimited, preloading everything up front remains wasteful when most of it is irrelevant to the task at hand.
So even if "Skills" gets replaced, discoverability and progressive disclosure likely survive.
Yes this 100%. Every person i speak with who is excited about MCP is some LinkedIn Guru or product expert. I'm yet to encounter a seriously technical person excited by any of this.
I've found the "too many tools polluting context" problem to be real. The challenge is that MCP servers often expose everything upfront, even when you only need a subset. The on-demand capability discovery pattern 'irrationalfab' mentioned makes sense having a lightweight index that the model can query, then pulling full tool details only when needed. This mirrors how we actually work with APIs we don't load all endpoints into memory, we discover them as needed.
How likely is it to even remember “the AI stuff” 2-3 years from now? What we’re trying to do with LLMs today is extremely unsustainable. NVidia/openai will run out of silly investors eventually…
Skills are just prompt conventions; the exact form may change but the substance is reasonable. MCP, eh, it’s pretty bad, I can see it vanishing.
The agent loop architectural pattern (and that’s the relevant bit) is going to continue to matter. There will be new patterns for sure, but tool calling plus while loop (which is all an “agent” is) is powerful and highly general.
It's basically just a way for the LLM to lazy-load curated information, tools, and scripts into context. The benefit of making it a "standard" is that future generations of LLMs will be trained on this pattern specifically, and will get quite good at it.
It's the description that gets inserted into the context, and then if that sounds useful, the agent can opt to use the skill. I believe (but I'm not sure) that the agent chooses what context to pass into the subagent, which gets that context along with the skill's context (the stuff in the Markdown file and the rest of the files in the FS).
This may all be very wrong, though, as it's mostly conjecture from the little I've worked with skills.
BUT what makes them powerful is that you can include code with the skill package.
Like I have a skill that uses a Go program to traverse the AST of a Go project to find different issues in it.
You COULD just prompt it but then the LLM would have to dig around using find and grep. Now it runs a single executable which outputs an LLM optimised clump of text for processing.
“inserted at the start of any query” feels like a bit of a misunderstanding to me. It plops the skill text into the context when it needs it or when you tell it to. It’s basically like pasting in text or telling it to read a file, except for the bit where it can decide on its own to do it. I’m not sure start, middle, or end of query is meaningful here.
The agentic development scene has slowly turned into a full-blown JavaScript circus—bright lights, loud chatter, and endless acts that all look suspiciously familiar. We keep wrapping the same old problems in shiny new packages, parading them around as if they’re groundbreaking innovations. How long before the crowd grows tired of yet another round of “RFC” performances?
Well, these agentic / AI companies don't even know what an RFC is, let alone how to write one. The last time they attempted to create a "standard" (MCP) it was not only premature, but it was a complete security mess.
Apart from Google Inc., I have not seen a single "AI company" propose an RFC that was reviewed by the IETF and became a proper internet standard. [0]
"MCP" was one of the worst so-called "standards" ever built since the JWT was proposed. So I do not take Anthropic seriously when they create so-called "open standards" especially when the reference implementation is in Javascript or TypeScript.
It’s a fast moving field. People aren’t coming up with new ideas to be performative. They see issues with the state of the art and make something that may or may not advance things forward. MCP is huge for getting agents to do things in the “real world”. However, it’s costly! Skills is a cheap way to fill that gap for many cases. People are finding immediate value in both of these. Try not to be so pessimistic.
I have no idea why I’m about to defend OpenAI here. BUT OpenAI have released some open weight models like gpt-oss and whisper. But sure open weight not open source. And yeah I really don’t like OpenAI as a company to be clear.
I noticed a similar optimization path with skills, where I now have subagents to analyze the performance of a previous skill/command/hook execution, triggered by a command. I've pushed this to my plugin marketplace https://github.com/athola/claude-night-market
One thing that is interesting to think about is given a skill which is just "pre-context", how can it be _evolved_ to create prompts given _my_ context? e.g. here is their web artifact skill builder from desktop app:
```
web-artifacts-builder
Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Use for complex artifacts requiring state management, routing, or shadcn/ui components - not for simple single-file HTML/JSX artifacts.
```
Say I want to build a landing page with some relatively static content — I don't know it yet but its just gonna be bootstrap CSS, no SPA/React(ish), it'll be fine with templated server side thing. But I don't know how to express this in words. Could the skill _evolve_ based on what my preferences are and what is possible for a relative novice to grok and construct?
This is a simple example, but it could extend to say using sqlite+litestream instead of postgres or using Gradient boosted trees instead of an expensive transformer based classifier.
I feel inspired and would like to donate my standard for Agent Personas to the community. A persona can be defined by a markdown file with the following frontmatter:
---
persona: hacker
description: logical, talks about computers a lot, enjoys coffee, somewhat snarky and arrogant
---
<more details here>
1. For an experienced Claude Code user, you can already build such an agent persona quite trivially by using the /agents settings.
2. It doesn't actually replace agents. Most people I know use pre-defined agents for some tasks, but they still want the ability to create ad-hoc agents for specific needs. Your standard, by requiring them to write markdown files does not solve this ad-hoc issue.
3. It does not seem very "viral" or income-generating. I know this is premature at this point, but without charging users for the standard, is it reasonable to expect to make money off of this?
Skills are a pretty awkward abstraction. They emerged to patch a real problem, generic models require fine-tuning via context, which quickly leads to bloated context files and context dilution (ie more hallucinations)
But skills dont really solve the problem. Turning that workaround into a standard feels strange. Standardizing a patch isn’t something I’d expect from Anthropic, it’s unclear what is their endgame here
Skills don’t solve the problem if you think an llm should know everything. But if you see LLMs mostly as a text plan-do-check-act machine that can process input text, generate output text, and can create plans how to create more knowledge and validate the output, without knowing everything upfront, skills are perfectly fine solution.
The value of standardizing skills is that the skills you define work with any agentic tool. Doesn't matter how simple they are, if they dont work easily, they have no use.
You need a practical and efficient way to give the llm your context. Just like every organization has its own standards, best practices, architectures that should be documented, as new developers do not know this upfront, LLMs also need your context.
An llm is not an all knowing brain, but it’s a plan-do-check-act text processing machine.
How would you solve the same problem? Skills seem to be just a pattern (before this spec) that lets the LLMs choose what information they need to "load". It's not that different from a person looking up the literature before they do a certain job, rather than just reading every book every time in case it comes in handy one day. Whatever you do you will end up with the same kind of solution, there's no way to just add all useful context to the LLM beforehand.
Marketing. That defines pretty much everything Anthropic does beyond frontier model training. They're the same people producing sensationalized research headlines about LLMs trying to blackmail folks in order to prevent being deleted.
> Standardizing a patch isn’t something I’d expect from Anthropic
This is not the first time, perhaps expectation adjustment is in order. This is also the same company that has an exec telling people in his Discord (15m of fame recently) Claude has emotions
All the talk about "open" standards from AI companies feels like VC-backed public LLM experiments. Even if these standards fade, they help researchers create and validate new tools. I see this especially with local models. The rise of CLI-based LLM coding tools lets me use models like GPT OSS 20B to build apps locally and offline.
I wish agentic skills were something other than a system prompt or a series of step-by-step instructions. feels like anthropicide and opportunity here to do something truly groundbreaking but ended up with prompt engineering.
Interesting move. One thing I’m curious about is how opinionated the standard is supposed to be.
In practice, agent “skills” tend to blur the line between capabilities, tools, and workflows, especially once statefulness and retries enter the picture.
Is the goal here mostly interoperability between agent frameworks, or do you see this evolving into something closer to a contract for agent behavior over time?
I can imagine standardization helping a lot, but only if it stays flexible enough to avoid freezing today’s agent design assumptions.
Could one make a copyleft type license such that the generated code must be licensed free and open and under the same license? How enforceable are licenses on these skills anyway, if one can take in the whole skill with an agent and generate a legally distinct but functionally close variant?
I have been switching between OpenCode and Claude - one thing I like about OpenCode is the ability to define custom agents. These can be ones tailored to specific workflows like PR reviews or writing change logs. I haven't yet attempted the equivalent of this with skills in Claude.
These two solutions look feel and smell like the same thing. Are they the same thing?
Any OpenCode users out there have any hot or nuanced takes?
Claude Code has subagents as well. I created a workflow with multiple agents to build iOS apps, including agents for orchestration, design, build, and QA.
I'd love to see way more interest, rigor, tooling, etc in the industry regarding Skills, I really think they have solved the biggest problems that killed Expert Systems back in the day. I'd love to see the same enthusiasm as MCPs for these, I think in the long term they will be much more important than MCPs (still complementary).
I had developed a tool for Roo Code, and have moved over to anti-gravity with no problem, that basically gives playwright the ability to develop and test user scripts in an automated fashion.
It is functionally a skill. I suppose once anti-gravity supports skills, I will make it one officially.
In a way yes, you can reduce context usage by a non-negligible amount approaching it this way. I'm investigate this on my skill validation/analysis/bidirectional MCP server project and hope to have it as a released feature soon: https://github.com/athola/skrills
This is the right direction but this implementation is playdough and this needs to be a stone mansion. I’m working on a non-LLM AI model that will blow this out of the water.
Or if we wrote these things in a language with real imports and modules?
I'm authoring equivalent in CUE, and assimilating "standard" provider ones into CUE on the fly so my agent can work with all the shenanigans out there.
Love seeing this become an open standard.
We just shipped the first universal skill installer built on it:
npx ai-agent-skills install frontend-design
20 of the most starred Claude skills ever, now open across Claude Code, Cursor, Amp, VS Cod : anywhere that supports the spec. Would love some feedback on it
“Agent skills” seems more like a pattern than something that needs a standard. It’s like announcing you’ve created a standard for “singletons” or “monads”
Why does this need to be a standard in the first place. This isn't DDR5 lol, it's literally just politely asking the model to remember some short descriptions and read a corresponding file when it thinks appropriate. I feel like these abstractions are supposed to make Claude sound more sophisticated because WOW now we can give the guy new skills! But really they're just obfuscating the "data as code" aspect of LLMs which is their true power (and vulnerability ofc).
That's not what this is. MCP is still around and useful- skills are tailored prompt frameworks for specific tasks or contexts. They're useful for specialization, and in conjunction with post-training after some good data is acquired, will allow the next generation of models to be a lot better at whatever jobs produce good data for training.
irrationalfab|2 months ago
The real opportunity with Agent Skills isn't just packaging prompts. It's providing a mechanism that enables a clean split: LLM as the control plane (planning, choosing tools, handling ambiguous steps) and code or sub-agents as the data/execution plane (fetching, parsing, transforming, simulating, or executing NL steps in a separate context).
This requires well-defined input/output contracts and a composition model. I opened a discussion on whether Agent Skills should support this kind of composability:
https://github.com/agentskills/agentskills/issues/11
basch|2 months ago
And also, in writing, writing from top to bottom has its disadvantages. It makes sense to emulate human writing process and have passes, as you flesh out, and conversely summarize writing.
Current LLMs can brute force these things through emulation/observation/mimicry but they arent as good as doing it the right way. Not only would I like to see "skills" but also "processes" where you create a well defined order that tasks are accomplished in sequence. Repeatable templates. This would essentially include variables in the templates, set for replacement.
gradus_ad|2 months ago
Of course this requires substantial buy in from application owners - create the vocabulary - and users - agree to expose and share the sentences they generate - but the results would be worth it.
ugh123|2 months ago
Additionally, I can't even get claude or codex to reliable use the prompt and simple rules (use this command to compile) in an agents.md or whatever required markdown file is needed. Why would I assume they will reliably handle skills prompts spread about a codebase?
I've even seen tool usage deteriorate while it's thinking and self commanding through its output to say.. read code from a file. Sometimes it uses tail while other times it gets confused on the output and then writes a basic python program to parse lines and strings from the same file to effectively get what was the same output as before. How bizarre!
esafak|2 months ago
itissid|2 months ago
IIUC their most recent arc focuses on prompt optimization[0] where you can optimize — using DSPy and an optimization algo GEPA [1] — using relative weights on different things like errors, token usage, complexity.
[0] https://docs.boundaryml.com/guide/baml-advanced/prompt-optim... [1] https://github.com/gepa-ai/gepa?tab=readme-ov-file
deaux|2 months ago
> Parsing a known HTML structure
In most cases, HTML structures that are being parsed aren't known. If they're known, you control them, and you don't need to parse them in the first place. If they're someone else's, who knows when they'll change, or under what condition they're different.
But really, I don't see the stuff you're talking about happening in prod for non-one-off usecases. I see LLMs used in prod usecases exactly for data where you don't know exactly what its shape will be, and there's an enormous amount of such cases. If the same logic is needed every time, of course you don't have an LLM execute that logic, you have the LLM write a deterministic script.
_the_inflator|2 months ago
Skills are essentially boiling down to distributed parts of a Main Prompt. If you consider a state model you can see this pattern: Task is the state and combining the task's specifics skills defines the current prompt augmentation. When the task changes, another prompt emerges.
In the end, it is the clear guidance of the Agent that is the deciding factor.
hintymad|2 months ago
Transforming an arbitrary table is still hard, especially a table on a webpage or in a document. Sometimes I even struggle to find the right library. The effort does not seem worth it for one-off need of such transformation too. LLM can be a great tool for doing the tasks.
reedf1|2 months ago
vessenes|2 months ago
MCP does three things conceptually: it lets you build a bridge between an agent and <something else>, it specifies a UI+API layer between the bridge and the LLM, and it formalizes the description of that bridge in a tool-calling format.
It's that UI+API layer that's the biggest pain in the ass, in my opinion. Sometimes you need it; for instance, if you wanted an agent to access your emails, a high quality MCP server that can't destroy your life through enthusiastic tool calling makes sense.
If, however, you have, say a CLI tool or simple API that's reasonably self documenting and you're willing to have it run, and/or if you need specific behavior with a different context setting, then a skill can just be a markdown file that explains what, how, why.
irrationalfab|2 months ago
The durable pattern here isn't a specific file format. It's on-demand capability discovery: a small index with concise metadata so the model can find what's available, then pull details only when needed. That's a real improvement over tool calling and MCP's "preload all tools up front" approach, and it mirrors how humans work. Even as models bake more know-how into their weights, novel capabilities will always be created faster than retraining cycles. And even if context becomes unlimited, preloading everything up front remains wasteful when most of it is irrelevant to the task at hand.
So even if "Skills" gets replaced, discoverability and progressive disclosure likely survive.
verelo|2 months ago
xnx|2 months ago
We'll see how many of these are around in a few years.
eddybenchek|2 months ago
isodev|2 months ago
wuliwong|2 months ago
veunes|2 months ago
smrtinsert|2 months ago
adw|2 months ago
The agent loop architectural pattern (and that’s the relevant bit) is going to continue to matter. There will be new patterns for sure, but tool calling plus while loop (which is all an “agent” is) is powerful and highly general.
DenisM|2 months ago
makestuff|2 months ago
cshimmin|2 months ago
stavros|2 months ago
This may all be very wrong, though, as it's mostly conjecture from the little I've worked with skills.
theshrike79|2 months ago
BUT what makes them powerful is that you can include code with the skill package.
Like I have a skill that uses a Go program to traverse the AST of a Go project to find different issues in it.
You COULD just prompt it but then the LLM would have to dig around using find and grep. Now it runs a single executable which outputs an LLM optimised clump of text for processing.
danielbln|2 months ago
Inversely, you can persist/summarize a larger bit of context into a skill, so a new agent session can easily pull it in.
So yes, it's just turtles, sorry, prompts all the way down.
dcre|2 months ago
langitbiru|2 months ago
gaigalas|2 months ago
https://github.com/alganet/skills/blob/main/skills/left-padd...
josteink|2 months ago
Either way, that’s hilarious. Well done.
debugnik|2 months ago
xd1936|2 months ago
mrbonner|2 months ago
isoprophlex|2 months ago
rvz|2 months ago
Apart from Google Inc., I have not seen a single "AI company" propose an RFC that was reviewed by the IETF and became a proper internet standard. [0]
"MCP" was one of the worst so-called "standards" ever built since the JWT was proposed. So I do not take Anthropic seriously when they create so-called "open standards" especially when the reference implementation is in Javascript or TypeScript.
[0] https://www.rfc-editor.org/standards
hugs|2 months ago
beoberha|2 months ago
toomuchtodo|2 months ago
veunes|2 months ago
unknown|2 months ago
[deleted]
wiseowise|2 months ago
It is not healthy when you have an obsession this bad, seriously. Seek help.
quacky_batak|2 months ago
Although Skills are just md files but it’s good to see them “donate” it.
There goal seems to be simple: Focus on coding and improving it. They’ve found a great niche and hopefully revenue generating business there.
OpenAI on the other hand doesn’t give me same vibes, they don’t seem very oriented. They’re playing catchup with both Google models and Anthropic
plufz|2 months ago
theshrike79|2 months ago
Many many MCPs could and should just be a skill instead.
ada1981|2 months ago
Paper & applications published here: https://earthpilot.ai/metaskills/
uhgrippa|2 months ago
babyshake|2 months ago
itissid|2 months ago
``` web-artifacts-builder
Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Use for complex artifacts requiring state management, routing, or shadcn/ui components - not for simple single-file HTML/JSX artifacts. ```
Say I want to build a landing page with some relatively static content — I don't know it yet but its just gonna be bootstrap CSS, no SPA/React(ish), it'll be fine with templated server side thing. But I don't know how to express this in words. Could the skill _evolve_ based on what my preferences are and what is possible for a relative novice to grok and construct?
This is a simple example, but it could extend to say using sqlite+litestream instead of postgres or using Gradient boosted trees instead of an expensive transformer based classifier.
an0malous|2 months ago
lxgr|2 months ago
allisdust|2 months ago
falcor84|2 months ago
1. For an experienced Claude Code user, you can already build such an agent persona quite trivially by using the /agents settings.
2. It doesn't actually replace agents. Most people I know use pre-defined agents for some tasks, but they still want the ability to create ad-hoc agents for specific needs. Your standard, by requiring them to write markdown files does not solve this ad-hoc issue.
3. It does not seem very "viral" or income-generating. I know this is premature at this point, but without charging users for the standard, is it reasonable to expect to make money off of this?
acedTrex|2 months ago
brap|2 months ago
InitialLastName|2 months ago
unknown|2 months ago
[deleted]
baobun|2 months ago
weitendorf|2 months ago
oblio|2 months ago
Please tell us how REALLY feel about JavaScript.
zikani_03|2 months ago
apf6|2 months ago
And of course Claude Code has custom slash commands which are also very similar.
Getting a lot of whiplash from all these specifications that are hastily put together and then quickly forgotten.
vedmakk|2 months ago
Other than that it appears MCP prompts end up as slash commands provided by an MCP Server (instead of client side command definitions).
But the actual knowledge that is encoded in skills/commands/mcp prompts is very similar.
seg_lol|2 months ago
verdverm|2 months ago
layer8|2 months ago
vladsh|2 months ago
But skills dont really solve the problem. Turning that workaround into a standard feels strange. Standardizing a patch isn’t something I’d expect from Anthropic, it’s unclear what is their endgame here
ako|2 months ago
The value of standardizing skills is that the skills you define work with any agentic tool. Doesn't matter how simple they are, if they dont work easily, they have no use.
You need a practical and efficient way to give the llm your context. Just like every organization has its own standards, best practices, architectures that should be documented, as new developers do not know this upfront, LLMs also need your context.
An llm is not an all knowing brain, but it’s a plan-do-check-act text processing machine.
brabel|2 months ago
root_axis|2 months ago
Marketing. That defines pretty much everything Anthropic does beyond frontier model training. They're the same people producing sensationalized research headlines about LLMs trying to blackmail folks in order to prevent being deleted.
verdverm|2 months ago
This is not the first time, perhaps expectation adjustment is in order. This is also the same company that has an exec telling people in his Discord (15m of fame recently) Claude has emotions
wuliwong|2 months ago
I think that they often do solve the problem, just maybe they have some other side effects/trade offs.
theshrike79|2 months ago
The best one we have thought of so far.
terminalkeys|2 months ago
exasperaited|2 months ago
It has been published as an open specification.
Whether it is a standard isn't for them to declare.
htrp|2 months ago
runtimepanic|2 months ago
liampulles|2 months ago
Could one make a copyleft type license such that the generated code must be licensed free and open and under the same license? How enforceable are licenses on these skills anyway, if one can take in the whole skill with an agent and generate a legally distinct but functionally close variant?
kristo|2 months ago
mkagenius|2 months ago
It does code execution in an apple container if your Skill requires any code execution.
It also proves the point that Skills are basically repackaged MCPs (if you look into my code).
theturtletalks|2 months ago
good-idea|2 months ago
These two solutions look feel and smell like the same thing. Are they the same thing?
Any OpenCode users out there have any hot or nuanced takes?
terminalkeys|2 months ago
0x008|2 months ago
abatilo|2 months ago
albingroen|2 months ago
fudged71|2 months ago
unknown|2 months ago
[deleted]
robertheadley|2 months ago
It is functionally a skill. I suppose once anti-gravity supports skills, I will make it one officially.
someguy101010|2 months ago
uhgrippa|2 months ago
theshrike79|2 months ago
user3939382|2 months ago
Seattle3503|2 months ago
verdverm|2 months ago
I'm authoring equivalent in CUE, and assimilating "standard" provider ones into CUE on the fly so my agent can work with all the shenanigans out there.
foobarqux|2 months ago
veunes|2 months ago
almosthere|2 months ago
langitbiru|2 months ago
esafak|2 months ago
delayedrelease|2 months ago
skillcreator|2 months ago
npx ai-agent-skills install frontend-design
20 of the most starred Claude skills ever, now open across Claude Code, Cursor, Amp, VS Cod : anywhere that supports the spec. Would love some feedback on it
github.com/skillcreatorai/Ai-Agent-Skills
officialchicken|2 months ago
pplonski86|2 months ago
jameslk|2 months ago
unbelievably|2 months ago
ath3nd|2 months ago
[deleted]
alexgotoi|2 months ago
[deleted]
asadm|2 months ago
observationist|2 months ago