Agent skills

A skill is one plain .md file that teaches an AI agent one job: when to use it, the rules to follow, and the exact output to produce. No code, no runtime, no lock-in — the agent simply reads the file. Because it is Markdown, you can read it too, diff it, and pin the exact version you reviewed.

Skills answer how to work. What is true in your context — your stack, your conventions, your customers — belongs in your private Brain. The two meet in the agent: the skill is the playbook, the Brain is the memory.

# try one — installs the .md into ./skills
npx @emdly/cli add opsmith/jira-ticket-scorer

Anatomy of a skill

There is no rigid schema — good skills share a shape. Say when the skill applies, list hard rules (what the agent must never do), and define the output contract precisely enough that two runs are comparable:

---
name: jira-ticket-scorer            # front matter is optional in the catalog —
description: Scores Jira tickets…   # the SKILL.md twin adds it when missing
---

# Jira ticket scorer

Use when the user asks to triage, score or prioritise tickets.

## Rules
- Never invent fields that are not in the ticket.
- Ask before scoring more than 50 tickets at once.

## Output
A table: ID · title · score 1–5 · one-line reason.

Keep it under a few kilobytes: agents load skills into context. One job per skill — “and” in the description usually means it should be two skills.

Installing

Three ways, same file. Nothing needs an account:

# CLI — copies the .md into ./skills
npx @emdly/cli add {owner}/{skill}

# raw URL — stable, scriptable
curl https://emdly.com/raw/{owner}/{skill}.md

# MCP — the agent installs it itself
claude mcp add --transport http emdly https://emdly.com/mcp
# then: "install {owner}/{skill} from emdly"

Over MCP, install_skill hands the agent the file plus the exact path for its runtime: Claude Code writes .claude/skills/<name>/SKILL.md and the skill appears as /<name>; Hermes gets ~/.hermes/skills/<category>/<name>/SKILL.md; anything else gets ./skills/<name>.md. The SKILL.md twin always carries name/description/version front matter — synthesised when the author left it out.

Versions & pinning

Every approved update becomes a numbered version. Unversioned URLs always serve the latest approved version; pin when exact wording matters — in CI, in an agent fleet, in anything you audited:

https://emdly.com/raw/{owner}/{skill}.md        → latest approved
https://emdly.com/raw/{owner}/{skill}@v12.md    → exactly v12, forever
get_skill(owner/skill, version: 12)       → the same over MCP

Publishing & review

Anyone signed in (Google or GitHub) can submit a skill — in the web editor, by uploading a file, over the REST API, or by asking their agent to call submit_skill. Every submission, first version or update, goes through the same pipeline:

1. Automated checks — Markdown lint, a license present, a prompt-injection scan.
2. AI safety scan — flags manipulation, unsafe instructions and injection patterns for the reviewer.
3. Human review — a person approves or rejects with a reason. Nothing publishes itself.

Versions that pass everything with a clean scan are marked Security checked on the skill page. Authors build standing the same way: published work earns the Verified, Recommended and Certified author badges.

Frequently asked