LE
LOKI
EVOLVED
Back to The Signal / Home
DERIVED / B1-A

Skills for coding agents: stop pasting the same prompt into your AI

If every session with your coding agent starts with you explaining the project rules again, you're missing a skill. This guide, inspired by Brais Moure's MoureDev workshop, explains what a skill is, where each agent keeps them, how they get triggered and what to check before installing someone else's, and shows a real skill we built and tested to review Loki's drafts.

By yenny astrid londoño monrroyReviewed

ASSOCIATED VIDEO & DEMO

Key Takeaways of this Analysis

  • A skill is a folder with a SKILL.md: a header with a name and description, and a body with instructions.
  • The description decides when the agent uses it: say what it does and when to use it, in the words you'd use to ask.
  • The format is an open standard, but each agent looks in its own folder: .claude/skills in Claude Code, .agents/skills in Codex.
  • Anything that must come out the same every time belongs in a script, not an instruction: text guides, code checks.
  • Installing a third-party skill means installing code: read it first, especially its scripts/ folder.
  • A few well-described skills beat a huge catalog with overlapping descriptions.

If you use an agent to write code, you know the routine: you open a new session and explain the project rules all over again, the format you expect and what it must not touch. The agent doesn't remember yesterday's conversation, so you paste the same long prompt every morning.

Skills exist for exactly that. Brais Moure explains them in a MoureDev workshop (in Spanish) that's worth watching in full. This guide starts from his ideas, checks the technical details against each tool's official documentation, and adds what we learned by writing our own skill.

What a skill is

A skill is a folder with a SKILL.md file. That file has two parts:

  1. A YAML header with, at minimum, name and description.
  2. A Markdown body with the instructions: steps, constraints, examples and the output format you expect.

The folder can hold more. The specification recommends three optional subfolders:

  • scripts/: code the agent can run, such as a validation or a test.
  • references/: documentation the agent reads only when it needs it.
  • assets/: templates, schemas or data files.

Anthropic created the format and released it as an open standard at agentskills.io. Today it's read by Claude Code, Codex, Cursor, OpenCode, GitHub Copilot in VS Code and many other agents.

The part that matters most: the description

The agent doesn't read all your skills when it starts. It loads only the name and description of each one, about a hundred words at most. When your request matches a description, it reads the full SKILL.md. It opens files in references/ and scripts/ only if the instructions tell it to. The specification calls this progressive disclosure.

That's why the description decides whether the skill is useful. If it's vague, the agent won't use it when you need it, or will use it when it shouldn't.

Compare these two:

description: Helps with articles.
description: Reviews a Loki Evolved article draft before publishing: voice, sources, internal links and frontmatter format. Use it when asked to review, fix or prepare an article, draft or post.

The second says what it does, when to use it and which words people will use to ask for it. The specification caps the description at 1,024 characters and the name at 64; the name allows only lowercase letters, numbers and hyphens, and must match the folder name.

Where each agent keeps its skills

This is where a common idea needs correcting: the skill format is the same, but each agent looks for skills in its own folder.

  • Claude Code: .claude/skills/<name>/SKILL.md inside the project, or ~/.claude/skills/ to have them in every project.
  • Codex: .agents/skills/ inside the repository, or ~/.agents/skills/ in your home folder.
  • Cursor and OpenCode also use .agents/skills/.

If you work with several agents, you don't need to copy the skill into each folder by hand. The npx skills installer, covered below, keeps one copy and creates symbolic links for each agent.

How a skill gets triggered

There are two ways, and both work in the main agents.

Explicit invocation: you call it by name.

  • In Claude Code, type /skill-name at the start of your message, for example /revisar-borrador.
  • In Codex, type $skill-name, or use /skills to see the list.

Implicit invocation: you ask for the task in your own words ("review this draft before I publish it") and the agent recognizes that the description matches.

Implicit is convenient, but you don't always want it. A skill that publishes, deploys or deletes something should run only when you call it. In Claude Code you get that with disable-model-invocation: true in the header; in Codex, with allow_implicit_invocation: false in the skill's configuration file. These fields aren't part of the shared standard, so check your agent's documentation before using them.

A real skill: the one that reviews our drafts

While preparing this guide we built a skill for our own editorial workflow. Every Loki Evolved article goes through the same review before it's published: the right Spanish voice (tú, not vos), a primary source for every fact, internal links to related guides and a complete frontmatter. Instead of explaining that in every session, we keep it in this folder in the site's repository:

.claude/skills/revisar-borrador/
├── SKILL.md
├── references/
│   └── guia-de-estilo.md
└── scripts/
    └── validar_frontmatter.py

Our skill is written in Spanish, because our articles are. This is its SKILL.md, translated:

---
name: revisar-borrador
description: Reviews a Loki Evolved article draft before publishing: voice, sources, internal links and frontmatter format. Use it when asked to review, fix or prepare for publishing an article, draft or post in content/articulos.
---

# Review a Loki Evolved draft

Don't edit the file. Deliver a report; the editor decides on changes.

1. Run `python3 .claude/skills/revisar-borrador/scripts/validar_frontmatter.py <file>`
   and copy its output.
2. Read `references/guia-de-estilo.md` and flag every sentence using vos
   ("tenés", "pedile") with its tú version.
3. List every figure, date, price or product feature and say whether
   it links to a source. If it doesn't, mark it "no source".
4. Suggest two to four links to other articles in content/articulos
   on the same topic, using the /signal/<slug> path.

## Output format

- Frontmatter: OK or the list of script errors
- Voice: table with original sentence and suggestion
- Claims without a source: list
- Suggested internal links: list with the reason

Notice how the work is split. What must come out the same every time, checking that the frontmatter has a title, slug, cluster and code, is done by a script, because a script doesn't interpret: it answers the same way every time. What needs judgment, deciding whether a sentence sounds natural or which article to link, stays in the instructions. Brais sums it up in the workshop with an idea we share: a language model never answers the same way twice, and a skill puts a harness on it. We'd add one nuance: a skill reduces variation, but the only thing that truly behaves the same every time is the code in scripts/.

We tested it in Claude Code with an ordinary request that didn't name the skill: "Review the draft content/articulos/rag-cuando-si-cuando-no.md before publishing it." The agent picked the skill on its own, ran the script, left the file untouched and delivered the report with all four sections. It also caught something we had missed: that article doesn't link to a single source. That's what a skill is for: the careful review you'd do on a good day, applied the same way to every draft.

When to use a skill and when to use a rules file

Not everything should be a skill. Many agents read a project rules file in every session, such as AGENTS.md or CLAUDE.md.

  • Put in the rules file what always applies: the stack, how tests run, the folders nobody touches.
  • Make a skill for what applies to a specific task: reviewing a draft, preparing a release, migrating a component.

The difference is context. The rules file loads in full in every session. A skill takes up only its description until you need it.

Installing community skills safely

You don't have to write everything from scratch. In the workshop, Brais shows how to install skills made by other developers. The most used tool is Vercel Labs' skills CLI, with its directory at skills.sh:

# See which skills a repository has, without installing anything
npx skills add owner/repository --list

# Install a single skill in the current project
npx skills add owner/repository --skill skill-name

# Search skills by topic
npx skills find testing

With -g it installs in your home folder and becomes available in all your projects.

Some well-known skills mentioned in the workshop:

  • frontend-design, by Anthropic: guides the agent to design interfaces with visual judgment instead of the usual generic look.
  • skill-creator: helps you write new skills. It ships with Codex and is also in Anthropic's skills repository.
  • find-skills, from Vercel Labs' own repository: searches for skills that fit what you need.
  • Matt Pocock's collection, with skills like /tdd or /grill-me, built for working test-first and for challenging a plan before writing code.

Before installing any of them, remember that a skill is code your agent runs with your permissions. Three quick checks:

  1. Read the whole SKILL.md. Look for instructions unrelated to what the description promises.
  2. Open every file in scripts/. If it downloads something, reads environment variables or sends data out, you need to know why.
  3. Prefer repositories with an identifiable author, history and releases. Install one specific skill with --skill, not the whole repository.

How many skills is too many

Brais warns in the workshop against over-engineering, and he's right, though it helps to understand why. Since the agent loads only the descriptions, having many skills doesn't flood the context at once. The real problem is different: when several descriptions look alike, the agent hesitates between them or picks the wrong one. And every skill you install without reviewing it is code you don't know.

Our rule: start with one skill for the task you repeat most. Add another only when you notice you're writing the same prompt for the third time. Skills that serve one project go in the project folder. The ones you use everywhere go in your home folder.

Where to start today

  1. Pick the task you explain to your agent most often.
  2. Write one sentence on what it does and another on when it's used. That's your description.
  3. Create the folder in your agent's path, with its SKILL.md.
  4. Test it twice: once by calling it by name and once by asking in your own words.
  5. If something must always come out the same, move it into a script.

Keep reading

Sources

ARTICLE PROMPT / TEMPLATE
I want to turn a task I keep repeating into a skill for my coding agent.

The task: [DESCRIBE THE TASK IN TWO OR THREE SENTENCES]
How I usually ask for it: [PASTE TWO OR THREE WAYS YOU PHRASE IT]
What it should deliver: [OUTPUT FORMAT]
What it must never do: [CONSTRAINTS]

1. Suggest a lowercase, hyphenated name (64 characters max).
2. Write a one- or two-sentence description that says what it does and when to use it, using the words from my examples.
3. Write the SKILL.md body: steps, constraints and output format, in under 100 lines.
4. Tell me which part should be a script instead of an instruction, and why.
5. Don't invent configuration options: if a field depends on my agent, say so.
LOKI EVOLVED RESEARCH HUB