Yay a post about LLMs.

MCP (Model Context Protocol)

In the beginning, there were Large Language Models.

Then they learned to imitate human thinking.

Then came MCP (Mira-Cra Park!), and there was much happiness in the world.

MCPs (Model Context Protocol) add functionality to models.

How is it different from a tool call? I have no idea. But I did read some rants saying it is very to make your own MCP.

SKILL.md

Whereas a SKILL.md is just a Markdown file with instructions and maybe some scripts, so it is much easier.

The design is self-evident as well; the coding agent sees each skill’s names and description, then decides whether to use it or not.

Workflow skills

Several workflow skills have made the rounds, such as grill-me, superpowers, and gsd.

But I personally think that these are a bit too rigid, and I hope models will get better such that we do not need them.

Projects like gsd ended up moving up the stack and implement their own coding agents; There are also some coding agents that advertise malleability, like Pi and Hermes.

So maybe even for those who like workflow skills, perhaps it is not the right level of abstraction.

Domain expertise skills

Do you know how to maximize Soul Egg production in Egg Inc.?

Given enough time, Reddit API calls, and trial-and-error, an LLM can probably figure it out.

But we lack these things, nor do we have perfect RAG to search documentation; so we condense them into skills.

“Turn your ex-coworker into a skill!” says the advertisements. There is a moral dimension to this; I’ll leave discussion to the experts.

Documentation

I have not been writing documentation at work.

For the specific problem space that I work in, there are a lot of components and interactions. Therefore, I am beginning to think that documentation is a liability.

On the creation side, documentation is like another version of your code, only impossible to test, and always needing an update.

On the consumption side, competent LLMs can read code to figure out what happens; code is the single source of truth here.

These are the things I do document though:

  • Domain expertise and quotes
  • The occasional comment to explain what is happening here
  • Problem space, general shape of the problem and solution
  • APIs and guides for upstream and downstream

Documentation skills

I use a Python package manager called uv.

The oldest LLMs don’t know how to use uv, so I had to instruct them to not install packages.

Then they started calling uv pip, the compatibility interface.

Then finally, the newest models know to uv add requests.

If you would like to speed up the process, or work with a lesser-known tool, like just, you will probably want to write a documentation skill for that. just is a great example because it has some quirks, such as Bash-like behavior, even on Windows.

But both just and uv have --help; I am hopeful that future LLMs can render this obsolete. That they should be able to read --help, research, experiment, hit a wall, backtrack, and remember findings, just like we do.

Which expands this issue to memory, RAG (Retrieval-augmented generation), and more topics that I guess are out of scope.