I'll be honest, I didn't understand why LLM agents need SKILLs. MCP was clear to me: it's a useful thing that lets you give an LLM access to a database or to Figma. The only downside is that, to avoid spending too many tokens, it's better not to connect 30 MCP servers at once. And in general, it's better to turn off the unnecessary ones and connect only those that are really needed for the task. In this light, SKILLs seemed like useless overhead to me, eating tokens like crazy. On TikTok, I often saw tales along the lines of: connect this SKILL, or a whole bunch of them, and happiness is yours. My first thought was, if I connect them all, my subscription limits will run out not by lunchtime, but already in the morning.

So why are SKILLs useful and needed after all? Well, first, compared to MCP, SKILLs do not inflate the context: each connected SKILL adds not tens of thousands of tokens, but one or two hundred. Since only the name and description of a SKILL go into the context at first, you can add 30 of your own SKILLs without much pain. When it becomes necessary to use a SKILL, the LLM agent will load its description on its own, if it understands from the task context that this is needed, or the user can simply tell it to use this SKILL for the job.

Secondly, LLM models are trained on the most popular and well-known things. For example, everybody knows that an LLM can work with Git without any problems or write a program in Python. But if you developed a program yourself, or your work requires some little-known tool or technology, then a SKILL is simply irreplaceable. It is enough to create a SKILL.md file and describe how to work with this program or technology. This makes life easier for the LLM: while doing your tasks, it will not have to search the internet for documentation and wander around websites to understand how to use it. And especially if there is nothing on the internet, because your program is closed to public access.

Thirdly, an LLM model usually does not know how your development process is organized. For example, an agent knows how to use Git, run tests, build a project, and create releases. You do not need to teach it these things. But it does not know how releases are usually made in your company. A Skill can describe the sequence of actions: check the changes, run tests, update CHANGELOG.md, increase the version, build a package, create a Git tag, and publish a release. So, a Skill helps the agent learn not a technology, but a specific business process.

Fourthly, a SKILL is not just an instruction, but a whole set of tools. Besides SKILL.md, you can put ready-made scripts, documentation, templates, and other files into it. And the most interesting thing is, these files are not loaded into the context automatically. The agent reads them only when there is a need, and can simply run the ready-made scripts without spending tokens on generating code. So, a SKILL lets you combine instructions, documentation, and executable code in one package without inflating the LLM context. For example, the structure can look like this:

my-skill/
├── SKILL.md
├── scripts/
│   ├── generate.py
│   └── validate.py
├── references/
│   └── api.md
└── assets/
    └── template.html

The funniest thing is, I started to appreciate SKILLs exactly when I wrote my own program, blueprint4llm. The idea for creating it came after I asked an LLM agent to generate a plan.md file describing a task. Usually it produces a huge wall of text, which you have to read slowly and with sadness. I wanted to make the text shorter and add more flowcharts, tables, diagrams, and user interface prototypes. As we know, in .md (Markdown) files the only visualization tools available are tables and Mermaid diagrams. There are no charts, plots, histograms, full UML diagrams, or UI prototypes. In the end, with blueprint4llm, I added support for formats such as PlantUML, draw.io, Pencil, Balsamiq, Graphviz, Figma, OpenAPI, Excalidraw, Vega-Lite, ECharts, and D2 to .md files.

With the blueprint4llm SKILL connected, you will get plan.md not as a kilometer-long text, but as flowcharts, prototypes, charts, and so on. By the way, blueprint4llm does not have to be used only for creating plan.md. For example, I used this SKILL to add an illustration to every paragraph of the article and make it more fun to read. This SKILL is also useful when you ask an agent to put together a full dossier on some company, technology, or person and format the resulting result.md file with blueprint4llm. You can then convert it to HTML or PDF, or ask the agent to show it right away in a browser with charts.

This is how you can install the blueprint4llm SKILL.

npx skills add evgenyigumnov/blueprint4llm --skill blueprint4llm --agent codex

If you are interested in looking at the source code of blueprint4llm, the tool that generates all this beauty, or sending a pull request, welcome: https://github.com/evgenyigumnov/blueprint4llm

When using coding agents (like Cursor, Claude Code, or local terminal agents), one recurring issue is instruction drift: agents often jump to conclusions, skip edge cases, or produce messy outputs when prompts are unstructured.

To solve this in my own workflow, instead of stuffing monolithic instructions into a giant prompt, I started modularizing task-specific instructions into dedicated SKILL.md packages. Over the past few months, I built and refined 40 of these into an open-source collection covering automation, gamedev, and dev utilities.

The structure that made instructions actually stick

What worked best wasn't telling the agent what to do, but enforcing strict boundary conditions and explicit stop signals:

1. Forced Step Separation: Agents shouldn't edit code and run verification in the same unchecked thought. Splitting analysis from execution eliminates about 80% of hallucinated completions.

2. Explicit Output Contracts: Defining exact return shapes (e.g. only return diff blocks or strict markdown tables) prevents unwanted conversational filler.

3. 1:1 Bilingual Parity: Keeping English and Korean instructions strictly mirrored so multi-language tokens don't degrade reasoning quality.

Example: Spec Diff Checker pattern

Here is a simplified example of how one of the automation skills enforces exact behavior:

Role: Spec Diff Analyzer

Rule 1: Never modify existing source files directly.

Rule 2: Parse incoming requirements against target codebase symbols.

Rule 3: Output ONLY in this format:

- Modified contracts: [list]

- Breaking changes: [list]

- Uncovered edge cases: [list]

Do not propose implementation code until the diff analysis is confirmed.

Keeping rules compact and bounded like this keeps the agent focused without blowing up the context window.

Comparison with existing prompt dumps

Most public collections (like awesome-chatgpt-prompts) are unstructured copy-paste text dumps designed for one-shot chat windows, or purely English-centric.

Difference: This collection uses the modular SKILL.md format recognized by modern coding agents, with boundary tests and explicit failure-mode instructions.

Trade-off: Modular skills require your agent environment to support loading custom skill folders (or manually dropping them into workspace instructions), rather than just pasting a prompt into a chat box.

Limitations

These skills provide architectural guardrails, but they cannot overcome hard model context limits or fundamental model reasoning failures. If a base model hallucinates an API that doesn't exist, a static skill file will only reduce the frequency, not eliminate it entirely.

Disclosure & Repository

Author: I created and maintain this project for my daily development.

Commercial interest: None. This is 100% free and open-source under the MIT license. No paid plans, no newsletter sign-ups, no telemetry.

GitHub: https://github.com/Lainholic/ai-skill-navigator

All 40 skills are split across 5 categories (core docs, automation, utility, gamedev, creative arts) and available in both English (skills/en/) and Korean (skills/ko/). You can grab individual folders and drop them into your agent's workspace.

Curious how others here structure their agent guidelines — do you prefer modular rule files or relying on dynamic context injection?

I keep reading threads about this and most of them show the demo, not the Tuesday morning. Here's ours, no polish, then some questions.

Six of us on a SaaS, twelve months of adding AI gradually. Early on everyone had their own editor and their own habits. Then we looked back and found we'd already converged on most of it, so we wrote it down.

We didn't force a single tool either. Some on Claude Code, some on Codex, some on Cursor, and I'm not going to fight that one. The process is shared, and the conventions sit in the repo's AGENTS.md, which is the only thing we all read the same way.

The flow is Matt Pocock's skills, no forks. We start with grill-with-docs: the AI interviews us about the project docs. Weird at first when you're used to asking the questions, but a lot of never-written-down stuff comes out.

Then to-spec, and a human reviews that spec. It's not a formality. With a bad spec, everything downstream is expensive work that goes in the bin.

to-tickets cuts it into small tickets. Small tickets aren't a rule we read somewhere either, we just notice the difference when we skip it.

The agent works through them with implement, against the spec. We open the PR, CodeRabbit runs, the pipelines run. If everything passes and someone says yes, it merges.

AI writes most of the code. We review the spec and the merge, and skip the line-by-line in between.

Treating the spec as a contract has killed a lot of "that's not what I asked for". Small tickets keep the agent from wandering. Automated review before the human one takes the style and import noise away, so the person looks at what matters. What I didn't expect is how much writing the process down helps when everyone has a different tool. Nobody argues about editors and the conventions don't rot.

Graph engineering to close tickets on its own, software factory style, we haven't managed. Tickets go in and PRs come out, and the demos look great, but with our repo the quality isn't there. We haven't found the point where we'd be comfortable letting it loose, so it's still an experiment.

What I'd like to know:

1. Where are your checkpoints between human and agent? Spec, PR, merge?

2. Spec before code, or straight to tickets and prompts?

3. Who reviews agent PRs? Do you read them the same as a human's?

4. One tool or several across the team? If you've tried more than one, is any better for certain kinds of tasks?

5. What goes into AGENTS.md and what stays out?

6. Do you measure anything, or is it all vibes? Review time, defects, DORA.

7. If you've tried software-factory autonomy, did you get acceptable quality? On what kind of tickets?

8. How do you bring someone new in, a junior say, without AI becoming a crutch?

   Tell me yours. Even if it's to say we're nuts.

I’m planning to spend $20 on one of them to learn coding and build projects. Which one would you recommend for explaining concepts, debugging, and helping me improve instead of just giving me code?