Package expertise once, reuse it everywhere

How it works

For teams whose process is written down where nobody reads it

Most teams already have the standard — the review checklist, the brand voice, the incident runbook. It lives in a wiki page that gets opened twice a year. A skill is that document in a form an agent loads on demand, so the standard is applied rather than merely published.

1. Create a skill with a name, a description, the instructions themselves, a category, and an allowed-tools list naming the tools it may reach for.
2. Assign it to an agent. Every agent carrying that skill applies the same instructions.
3. Already have one written? Import it: POST /api/skills/import takes raw SKILL.md content — YAML frontmatter plus a markdown body.
4. Export any skill back out with GET /api/skills/:id/export to review it in a pull request and keep it under version control.
5. Skills can declare relations to other skills and record where they came from, both inside the spec’s free-form metadata map, so they stay portable rather than locked to this app.

The file you write or export (SKILL.md):

  ---
  name: "Release Notes"
  description: "Turns merged PRs into customer-readable notes."
  category: "general"
  icon: "fas fa-puzzle-piece"
  allowed-tools:
    - code-search
    - file-read
  ---

  Group changes by what the customer can now do, never by
  module. Lead with the verb. One line per change. If a change
  is invisible to customers, leave it out entirely.

Input on an ordinary Tuesday:

  "Write the notes for this week's release."

Output, in that shape, from any agent carrying the skill:

  - Export a workflow run as CSV from the run history page.
  - Retry a failed step without re-running the whole workflow.
  - Search past runs by the tool a step called.

...and the six refactor commits are absent, because the
skill says invisible changes are left out.

• A skill is instructions plus an allowed-tools list. It does not add a capability: if no tool can reach the system you need, no wording will conjure one. That is what a plugin is for.
• allowed-tools narrows what a skill reaches for as a matter of scope and focus. Treat it as scoping, not as a security sandbox.
• Instructions are guidance to a model. Adherence is high and consistent, but it is a strong default rather than an enforcement mechanism — for hard guarantees, put the rule in a workflow step or an approval gate.
• Skills are scoped to your user. Sharing one means exporting the SKILL.md or publishing it, not granting access in place.
• Import expects the documented frontmatter shape. A file that does not parse is rejected outright rather than partially applied.

Next: the Skills API reference, or see how skills sit alongside agents and plugins.