Custom Skills for an AI Agent — Teaching a Model to Work by Your Own Rules
How to give a model your own procedures, checklists, and answer style through Markdown skills — so you stop repeating the same instructions in every chat. Using the Doka desktop agent as the example.
If you use an assistant every day, you've probably noticed: the same instructions keep coming up, chat after chat. "Answer briefly," "blockers first, then the small stuff," "format it like this." You can write that down once — as a skill. Here's how.
What a skill is
A skill is a short, reusable instruction for an agent: a checklist, a working procedure, a style rule, or a preferred answer format. You describe it once, and the agent picks it up on its own whenever a task resembles what the skill is for.
Worth being clear on what a skill isn't: it doesn't replace your request and it doesn't remove the need to check facts. It's a way to stop dictating the same thing every time, not an autopilot standing in for you.
How this works in Doka
Doka reads skills from a local folder, ~/.doka/skills/ — each skill is a
separate Markdown file. On every request, Doka compares it against the skill
descriptions and mixes in only the relevant ones — those that fit the current
task. Everything else stays out of the way.
Skills sit as regular files on your computer. No cloud involved: both the instructions themselves and whatever they get applied to stay on your machine.
How to write your own skill
A skill is a Markdown file with a small settings block (YAML frontmatter) at the
top and an instruction body. Here's an example file,
~/.doka/skills/my-review-style.md:
---
name: my-review-style
description: Apply my code review checklist.
triggers:
- code review
- review this code
---
# My Review Style
1. Blockers first, everything else after.
2. Don't nitpick style unless it affects correctness.
3. End with a short verdict: merge or not.
Three fields are required:
- name — a short identifier in Latin characters:
my-review-style. - description — one sentence about when to apply the skill. This is what Doka uses to decide whether it's relevant to a request.
- triggers — a list of phrases that should pull the skill in more readily.
The body after the settings is the instruction itself. Write it compactly: what to do, in what order, and how to check the result. Keep the most important part at the top — when a skill gets mixed into the work, a long body gets truncated.
What makes a good skill
- Short: usually 20–80 lines, one repeatable procedure.
- Clear triggers, and a result check at the end.
- No secrets, API keys, or tokens — a skill isn't a place for sensitive data.
A bad skill tries to replace everything at once: it crams in a dozen unrelated rules or stores one-off notes like task numbers. That just gets in the way.
The bottom line
A skill is a way to write your rule down once and stop repeating it. One Markdown file per procedure, clear triggers — and from there Doka pulls out the right skill on its own whenever a task calls for it. More on tuning things to your own workflow is in the documentation and the use cases by profession.