Teach it once. It doesn't need re-explaining.
A skill is a small, named, reusable piece of knowledge — a saved procedure, a style preference, a checklist, a fact about how a particular project works. It's plain text, written the way you'd brief a capable colleague, and the agent finds it and follows it on its own once it's saved — never re-explained turn after turn.
What a skill actually is
Not a plugin, a script, or executable code — a skill is instructions, stored under a name. Every skill has exactly four real fields:
| Field | What it is |
|---|---|
| name | A short, memorable identifier — what it's referred to by later. |
| trigger | One sentence describing when this applies. This is what search matches a future request against — it's never shown to the model as an instruction, only used to find the right skill. |
| content | The actual procedure — up to 6,000 characters of what the model reads and follows once loaded. |
| scope | global (every repo) or repo (this one only). A repo-scoped skill overrides a global one of the same name. |
Up to 60 skills per scope — global, or each individual repo. Reaching the cap doesn't reject a new skill; it evicts the single least-recently-updated one in that scope, so a skill kept in active use is never the one that gets pushed out just for being old.
Four tools, always available to the agent
| Tool | What it does |
|---|---|
| save_skill | Create or update a skill. Saving under an existing name updates it, never duplicates it. Fires only on an explicit request — never on the agent's own initiative. |
| search_skills | Fuzzy-matches a task-shaped query against every skill's name and trigger, this repo's own plus every global one. Returns a short list, not the full content. |
| load_skill | Loads one skill's full content by exact name and follows it — how a match from search_skills actually gets used. |
| list_skills | Lists every saved skill by name, trigger, and scope — no query needed. The answer to "what skills do I even have," a question search_skills can't answer since it needs a task, not a browse request. |
The intended flow needs no prompting: describe a task, the agent recognizes it might match something saved, searches, finds it, loads it, and follows it — or it can be triggered directly (“use the deploy-staging skill”).
Four ways to create one
Ask the agent, mid-conversation
“Remember this as a skill” — the agent generalizes what just happened into a reusable procedure and saves it itself.
Fill out a form
Name, trigger, content, written directly — or attach a file and let Kryex's own offline extractor pull the text from a PDF, Word doc, or plain-text file.
Upload a SKILL.md file
The portable convention other tools already use — a skill written for one system reads fine in Kryex, and vice versa. Parsed into an editable review form before it's actually saved.
Ask Kryex to create one
Describe what you want in plain language — “create a skill for reconciling ledger entries” — and the agent designs and saves it, following a shared baseline for what a well-written skill covers without being boxed into a rigid template.
A skill can be attached directly to one message — and the client is never trusted with its content
If a skill is attached to a message by name, and the client sends that skill's actual saved text along with it, an out-of-date or tampered client could make the agent follow fake content as if it were a real saved skill.
Attaching a skill sends only its name. The server re-resolves the real, current, enabled content itself — the identical lookup the agent's own search_skills/load_skill tools use — so whatever is actually saved at send-time is what reaches the model, never a stale or spoofed copy.
A skill is attached to a draft message, then edited before the message is actually sent. The old content the client originally saw never reaches the model — the current, just-edited version does, because the server looks it up fresh at send-time rather than trusting anything the client already had.
A skill's content can never be forged or replayed stale by a compromised or out-of-date client — the same 'server is the only source of truth' principle that governs every other action on Kryex.
Repo beats global
A skill scoped to one repository always wins over a global skill of the same name in that repository — the same “more specific wins” rule Kryex's standing project instructions use for nested files. A skill written for how this project does things never has to fight the general, every-repo version of the same idea.
A fresh install seeds one example skill so the list isn't empty on day one — explicitly labeled as a starting point, meant to be edited or deleted rather than kept as-is.