# Three open-source agent skills examples your agent will load > Agent skills examples are easy to copy, and getting an agent to load one is the hard part. A router, a release checklist and a link check show three complete SKILL.md files, each with a description written for the moment the task appears. Kortix is the open-source AI Operating System, and a skill in a Kortix project is skills//SKILL.md. URL: https://agentskillsguide.dev/agent-skills-examples ## Three complete skills, at the three sizes a repo needs. Every file is a valid `SKILL.md` you can paste into `skills//`, and each description names the moment the agent should reach for it. ### Router `skills/inbox-router/SKILL.md` ``` --- name: inbox-router description: Route one inbound request to the billing team or the platform team by reading the message and the account record. Use when a ticket, chat or email arrives with no owner assigned, or when someone asks who should take it. --- # Inbox router Pick exactly one queue. Do not draft a reply. 1. Read the request and the account record: plan, region, open invoices. 2. Choose `billing` for invoices, refunds and plan changes; choose `platform` for API errors, rate limits and deploys. 3. Write the queue into `owner` and the sentence that decided it into `route_reason`. 4. If both queues apply, leave `owner` empty and say so in `route_reason`. Exit criterion: `route_reason` quotes the sentence from the request that decided the queue. Once it is written, the task is finished. ``` ### Release `skills/release-checklist/SKILL.md` ``` --- name: release-checklist description: Walk a release from a green branch to a pushed tag, with a stop condition. Use before a production deploy, when preparing a change request for a release, and when a release has to be halted or rolled back. --- # Release checklist 1. Confirm `main` is green and the version in `package.json` is not already tagged. 2. Run `npm ci && npm test`. Stop here and report the failing test name and file if any test fails. 3. Generate the changelog from the merge commits since the last tag. 4. Open the release change request with the changelog and the test summary. 5. After a person merges it, tag the merge commit with the version and push the tag. Stop condition: a failing test, a merge conflict, or a tag that already exists ends the run at the step where it appears. Do not skip forward. Exit criterion: the tag is on the remote and points at the merge commit a person approved. Report the tag, the commit and the test summary; that report is the finished work. ``` ### Script `skills/docs-link-check/SKILL.md` ``` --- name: docs-link-check description: Check every relative link in the docs folder with the bundled script and report the ones pointing at a file that does not exist. Use after editing documentation, before opening a change request, and when a reader reports a dead link. --- # Docs link check Run the check from the repo root, with the folder that holds the Markdown: ```sh python scripts/check_links.py docs ``` - Exit code `0` means every relative link resolved. Report the file count and stop. - Exit code `1` prints one `file:line: link` per broken target. Fix the ones this edit introduced and list the older ones separately. - Open an external URL before changing it; the script does not test those. Exit criterion: the exit code is reported, and every link the edit introduced resolves. ``` ## A description written for the trigger beats one written about the topic Every skill carries two fields an agent sees before it decides anything: `name` and `description`. The [Agent Skills specification](https://agentskills.io/specification) requires both in frontmatter. Metadata is about 100 tokens and loads for every skill at startup. The rest of a `SKILL.md` loads once the skill is activated. That asymmetry decides the craft of the file. Kortix's own brand skill shows the shape: ```yaml name: kortix-brand description: "Load FIRST for anything that carries the Kortix look or voice: product or mobile UI, copy of any kind, decks, social, images, email, CLI output, anything with the logo, and reviews of these. Routes you to the exact files. Triggers: choosing a spacing, color, radius, shadow, duration or word that a user or buyer will read." ``` The first clause names the moment. The last sentence lists triggers in the vocabulary of the work: a spacing, a color, a duration, a word a buyer will read. You can read the file in [Kortix on GitHub](https://github.com/kortix-ai/suna). Set that beside a description like "Brand style guidelines for the design system." The second is accurate and does nothing at load time. It describes the folder's contents, so the agent has to infer which tasks those contents serve. It also competes with every other skill whose description reads like a table of contents. The version written for the trigger did that inference once, in the repo, where a person could review it. A description written about the topic fails in one of two ways. The skill gets loaded after the agent has already answered in the wrong register. The reply is already written. Or it never loads, and the agent improvises a house style from the prompt. A skill described by its trigger loads before the first paragraph is written. The load order follows the description. The fix is cheap to apply: name the task in the first clause, then list the phrases, file types and moments a person would use. ## What each of the three files does that prose cannot The router skill ends with a tie-break. When both queues apply, it leaves `owner` empty and says why. A paragraph explaining how a company routes tickets hands that decision back to the model on every run, and the model settles it differently from one session to the next. A procedure can be tested against twenty tickets and corrected once. The next session reads the corrected file. The release checklist carries two lines a prose description cannot express. Both are in the file. Its stop condition, a failing test or an existing tag, ends the run at a named step. Its exit criterion, a tag on the remote pointing at the merge commit a person approved, defines finished in terms the agent can check. Remove either line and the agent has to judge for itself whether a partly green test run is green enough. A release process exists to take that decision away from it. The third skill delegates to a script. `docs-link-check` names the command, the argument and the two exit codes, so the answer comes from a program that reads the same files every time. A person can rerun it and get the same list. Prose saying "validate the links" leaves the model to invent a check, and an invented check will occasionally pass a broken link because the sentence around it reads well. The script itself is short enough to keep beside the skill: ```python """Print every relative link under a docs root that points at a missing file.""" import re, sys from pathlib import Path LINK = re.compile(r"\[[^\]]*\]\(([^)]+)\)") def broken(md: Path): for n, line in enumerate(md.read_text().splitlines(), 1): for href in LINK.findall(line): if href.startswith(("http://", "https://", "mailto:", "#")): continue target = (md.parent / href.split("#")[0]).resolve() if not target.exists(): yield f"{md}:{n}: {href}" rows = [row for md in Path(sys.argv[1]).rglob("*.md") for row in broken(md)] print("\n".join(rows)) sys.exit(1 if rows else 0) ``` The specification reaches the same conclusion from its own side. It recommends step-by-step instructions, examples of inputs and outputs, and common edge cases inside the body. It also says the agent loads the entire file on activation. None of those three survive being written as an essay, because a step is a line the agent follows and an edge case is a condition it tests. ## Keeping the body inside the format's budget The specification's limits are generous, which makes them easy to exceed without noticing. The body has under 5,000 tokens recommended, and the main `SKILL.md` should stay under 500 lines, with detailed reference material moved into separate files. The router's body runs 89 words. It sits inside both limits and answers a question the agent meets hundreds of times a day. A skill that needs a 300-line table of field names should keep the decision in the body and put the table in `references/`, with one line saying when to read it, so the agent loads the rule first and opens the reference only when the rule sends it there. Progressive disclosure does the rest. Files under `scripts/`, `references/` and `assets/` load only when a step reaches for one. Long bodies fail in a quieter way than long descriptions, because a skill that eats 4,000 tokens to answer a small question still loads and then crowds out the context the task needs. As of October 2026, the specification's reference library `skills-ref` validates a skill's frontmatter and naming. A `name` that breaks the character rules becomes a failing check, not a skill that quietly never loads. The rules are worth knowing before that check runs: `name` is 1 to 64 characters of lowercase letters, digits and hyphens, and must match the folder name. ## Where the files live, and how the agent picks one A skill is a directory containing, at minimum, a `SKILL.md` file. The folder name is the `name` field, and scripts go in `scripts/`, reference documents in `references/`, and templates, images or data in `assets/`. In a Kortix project a skill is `skills//SKILL.md`, and reference files can sit beside it. Which skills an agent may load is a grant in `kortix.yaml`, set for each agent. A skill in `skills/` is usable only when that agent's grant allows it, so the grant is a separate decision from what the skill says. Lookup is ordered and predictable. A session looks in the managed `kortix-*` skills, then `skills/`, then `.kortix/opencode/skills/`. pi also reads `harnesses/pi/skills/`, and the first skill of a name wins. The order matters when a team keeps an old copy in a second directory. The copy in the earlier location is the one the agent reads, and the later one is dead weight nobody notices. The [Kortix docs](https://kortix.com/docs/project/agents) document the order. Skills in a repo are files like any other. A diff shows what changed, and a change to a skill lands through the same review as a change to code. Kortix keeps its own skills as folders under `.agents/skills/` in the repository, each one a `SKILL.md`, from `kortix-brand` and `kortix-release` to `ponytail`, `composio` and `agent-browser`. `skills-lock.json` pins each skill by source repository, `skillPath` and a `computedHash`. The lockfile is what stops a skill borrowed from another repo from changing underneath the agent. Start with the smallest file that changes an outcome. A router that resolves a tie earns its place in a week. So does a checklist that stops on a red test. A 200-line reference nobody reads earns nothing. A router, a checklist and a script skill are the shapes that survive that test, and each one is short enough to review in a single sitting. ## What people ask about skill examples Short answers, each one true of any repo that keeps skills beside its code. ### Can you give me some examples of agent skills? Yes. A router that sends a request to the right team, a release checklist that stops on a failed test, and a docs link check that runs a bundled script are three common shapes, and each is a valid `skills//SKILL.md` you can copy. ### Which agent skills are best? The ones shaped like a procedure: numbered steps, a stop condition, a stated exit criterion, and a description that names the situations that should load it. Those four parts matter more than length. ### What are 10 examples of skills? Ten common ones: release checklist, changelog writer, incident triage, pull request review, documentation link check, brand voice, SQL review, migration rollback, inbox routing and support reply. Each is a folder with a `SKILL.md`, and most fit in twenty lines. ### What are examples of skills in AI agents? A skill in an AI agent is a folder of instructions the agent loads when a task matches. Common examples route a request to a team, walk a release from test to tag, check links in documentation, or apply a house writing rule to copy. ## Copy one skill and keep its shape. Skills live in the repo with your agents, so a change to one is reviewed like any other change. [Try Kortix](https://kortix.com) · [What a skill is](https://agentskillsguide.dev/what-are-agent-skills) Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. · Session work reaches main through a change request · Merge is default-deny for agents