Compared to MCPs, this is a much faster and more approachable flow to add "capabilities" to your agents.

I'm having a hard time figuring out how could I leverage skills in a medium size web application project.

It's python, PostgreSQL, Django.

Thanks in advance.

I wonder if skills are more useful for non crud-like projects. Maybe data science and DevOps.

This is really an agentic harness issue, not an LLM issue per se.

In 2026, I think we'll see agentic harnesses much more tightly integrated with their respective LLMs. You're already starting to see this, e.g. with Google's "Interactions" API and how different LLMs expect CoT to be maintained.

There's a lot of alpha in co-optimizing your agentic harness with how the LLM is RL-trained on tool use and reasoning traces.

<Skills>

  <Skill>

    <Name>postgres</Name>

    <Description>Directions on how to query the pre-prod postgres db</Description>
            <File>skills/postgres.md</File>

  </Skill>

The harness then may periodically resend this notification so that the LLM doesn't "forget" that skills are available. Because the notification is only name + description + file, this is cheap r.e tokens. The harness's ability to tell the LLM "IMPORTANT: this is a skill, so pay attention and use it when appropriate" and then periodically remind them of this is what differentiates a proper Anthropic-style skill from just sticking "If you need to do postgres stuff, read skills/postgres.md" in AGENTS.md. Just how valuable is this? Not sure. I suspect that a sufficiently smart LLM won't need the special skill infrastructure.

(Note that skill name is not technically required, it's just a vanity / convenience thing).

So it's just like a standard way to bring in prompts/scripts to the LLM with support from the tooling directly.

A lot of the things we want continuous learning for can actually be provided by the ability to obtain skills on the fly.

Some paths are emerging popular, but in a lot of cases we’re still not sure even these are the long term paths that will remain. It doesn’t help that there’s not a good taxonomy (that I’m aware of) to define and organize the different approaches out there. “Agent” for example is a highly overloaded term that means a lot of things and even in this space, agents mean different things to different groups.

Tools are useful so the AI can execute commands, but beyond that it's just ways to help you build the context for your prompt. Either pulling in premade prompts that provides certain instructions or documentation, or providing more specialized tools for the model to use along with instructions on using those tools.

- you will be getting a TON of spam. Just look at all the MCP folks, and how they're spamming everywhere with their claude-vibed mcp implementation over something trivial.

- the security implications are enormous. You'd need a way to vet stuff, moderate, keep track of things and so on. This only compounds with more traffic, so it'd probably be untenable really fast.

- there's probably 0 money in this. So you'd have to put a lot of work in maintaining a platform that attracts a lot of abuse/spam/prompt kiddies, while getting nothing in return. This might make sense to do for some companies that can justify this cost, but at that point, you'd be wondering what's in it for them. And what control do they exert on moderation/curation, etc.

I think the best we'll get in this space is from "trusted" entities (i.e. recognised coders / personalities / etc), from companies themselves (having skills in repos for known frameworks might be a thing, like it is with agents.md), and maybe from the token providers themselves.

not ranked with comments but I’d expect solid quality from these and they should “just work” in Codex etc.

The non-deterministic statistical nature of LLMs means it's inherently an "inevitably unverifiable process" to begin with, even if you pass it some type-checked, linted, skills file or prompt format.

Besides, YAML or JSON or XML or free-form text, for the LLM it's just tokens.

At best you could parse the more structured docs with external tools more easily, but that's about it, not much difference when it comes to their LLM consumption.

There you go, you're welcome.

Otherwise, why not just keep the password in an .env file, and state “grab the password from the .env file” in your Postgres skill?

Why not the filesystem?

I would create a local file (e.g. .env) in each project using postgres, then in my postgres skill, tell the agent to check that file for credentials.

I do also like to make skills on things that are more niche tools, like marimo (a very nice jupyter replacement). The model probably does known some stuff about it, but not enough, and the agent could find enough online or in context7, but it will waste a lot of time and context in figuring it out every time. So instead I will have a deep thinking agent do all that research up front and build a skill for it, and I might customize it to be more specific to my environment, but it's mostly the condensed research of the agent so that I don't need to redo that every time.