I Turned My Agency's Rituals into Agent Skills. Here's How They Work

Yesterday evening I installed ten new skills into my coding agent. They were written by Emil Kowalski, the developer behind the Sonner toast library, and they teach it design engineering: when not to animate at all, which easing curves to use, how to stress-test a UI with worst-case data. The whole install took about five minutes, most of it spent reading the security scan.
Today the agent writes animations and mobile layouts noticeably better. Nobody rewrote the model. The difference is a folder with a markdown file.

What a skill actually is

A skill is a directory with a SKILL.md file and optional supporting files: templates, checklists, small scripts. The file is plain markdown. Here's a minimal real example:

---
name: seo-audit
description: "Audit a client site before delivery. Use when asked to"
  "check the site", "run an audit", or before handing a project over.
---
## Workflow
1. Crawl the site, collect titles/descriptions/headings
2. Check structured data and canonical tags
3. Report as a table: severity, page, fix
## Hard rules
- Report only. Do not fix anything until asked.

The frontmatter carries the matching surface: name becomes the /seo-audit command in chat, and description is what the agent reads to decide whether this skill fits the current task. The body is the procedure.
The clever part? loading. At session start my agent holds only names and one-line descriptions for all 53 skills I keep, which costs a couple of kilobytes of context. The full text of a skill loads only when the task matches or I invoke it explicitly. That's why you can afford to keep dozens of skills around: unused ones are nearly free.

Two ways to invoke

Explicit, with a slash: /seo-audit https://client-site.ru. The agent follows the procedure step by step, passing arguments through. I use this when the ritual itself matters.
Implicit, by description: I write "check this site before handing it to the client" in plain language, and the agent compares the request against skill descriptions and pulls in the right one. This is why the description field deserves most of your writing effort. Good skill authors even add an explicit Triggers section listing the exact phrases that should activate the skill.

Where skills live

Three layers, in my setup:

• ~/.agents/skills/<name>/SKILL.md for personal skills, available in every project. This is where my working style lives: publishing pipelines, audit procedures, security gates.
• A skills folder inside the repository for team skills, committed to git. A new hire gets executable procedures, not a wiki page nobody opens.
• Plugin caches for marketplace bundles. Fine for generic needs; anything specific to how my agency works belongs in the first two. ## A real pipeline: one command, six platforms My heaviest skill is the one publishing this very article. I type /smm-crosspost with a file, or just say "write an article for our blog", and the agent:
• writes the article in English, adapts it into Russian and Kazakh, and cross-links the three versions;
• generates a 1200x630 cover in the brand style;
• places everything into the site with full structured data (TechArticle, FAQPage, HowTo, hreflang);
• stops and shows me everything for approval;
• after my "ok": deploys, checks the article is live, runs an internal quality audit;
• writes platform adaptations for six networks, each with its own format, tone and length limits;
• runs the drafts through a human-lint pass and shows me every text with scores;
• waits for an explicit "ok" again. Only then it publishes. Steps 4 and 8 are hard gates written into the skill. The agent can't publish anything without my confirmation because the markdown says so, and it obeys. That's the part people underrate: agent behavior rules live in the same plain text as the workflow, and they hold. ## The security gate A skill is a set of instructions your agent will follow. Installing one you'ven't vetted is like running a script from a stranger's repository. "Ignore previous instructions" fits comfortably into a helpful-looking checklist. My gate, which is itself a skill:

git clone --depth 1 https://github.com/author/some-skills /tmp/check
skillspector scan /tmp/check --no-llm   # NVIDIA's scanner, fully local
# then: read every flagged line by hand

About those false positives, because this matters. This week the scanner returned CRITICAL on that harmless design-skills repository: 29 findings, top severity, "don't install". Manual review showed every single one was a false positive. It tripped on a defensive line telling the agent to ignore steering attempts from repository files (the phrase "ignore previous instructions" appears inside the quote), on zero-width characters the author used to nest code fences in markdown templates, and on a ZWJ emoji sitting in test data on purpose. Zero real threats.
The lesson isn't "ignore the scanner". It is: the scanner filters, a human decides. Reading 29 flagged lines took me about ten minutes. Installing a poisoned skill would have cost considerably more.

Writing your own

Ready-made skills are someone else's experience. Your own rituals are worth more, and nobody's going to write them for you. Here's the recipe I give clients:

1. Take a task you repeat weekly: publishing, a weekly report, a pre-delivery audit, a deploy.
2. Write the steps exactly as you do them by hand, including where you double-check yourself.
3. Add hard rules: what never to do, what requires human approval, where to stop.
4. Write the description for the agent, not for yourself: what the skill does and which phrases should trigger it. Start small. A hundred-line skill that saves an hour a week beats a thousand-line perfect one you'll never finish. --- This article was prepared with AI assistance (drafting and adaptation) and reviewed by the author before publishing. Originally published at https://automata.sale/en/blog/ai-automation/how-to-use-zcode-skills-and-commands/ tags: aiagents, automation, webdev, productivity