Skip to main content

Skills overview

A skill is a package of instructions — in Markdown, with rules, examples and sub-references — that teaches an AI assistant to execute a specific workflow from start to finish, always the same way. Think of it as a "good colleague's playbook" that the assistant loads into context the moment you invoke it.

Unlike a one-off question, when you invoke a skill the assistant follows that skill's rules — the right order, the required fields, the known gotchas — instead of improvising based on what it learned during training.

What a skill ships with​

Every skill typically includes:

  • SKILL.md — the entry point, with the workflow summary, cross-cutting rules and the map of sub-references.
  • references/ — detailed sub-references per topic or domain (endpoints, DTOs, sample payloads, business rules).
  • Internal conventions — what to ask before starting, what to avoid, which common mistakes have already been mapped.

The assistant reads SKILL.md at open time and opens sub-references only when the topic calls for them — this keeps context lean and avoids guess-based answers.

How to invoke a skill​

You invoke a skill in two ways:

  1. Direct command — type /skill-name in the assistant. E.g. /phoenix-bug, /anymarket-backoffice-api-guide.
  2. Natural language — describe what you need and the assistant detects the right skill from the trigger phrases declared inside it. E.g. "run RCA for bug 12345", "help me integrate product registration with ANYMARKET".

Once invoked, a skill will usually ask clarifying questions before acting (environment, credentials, project context) — that's intentional and prevents rework.

Where skills live​

Physically, skills live in versioned folders — each one with its own SKILL.md and references/. The assistant discovers available skills from the directory configured in your harness (the AI client/IDE you use) or from a team's internal repository. Each harness has its own default directory and its own way of reloading skills — check the docs of the harness you use for the exact path.

Skills catalog​

SkillWhat it doesHow to invoke
ANYMARKET Backoffice API GuideFull guide to ANYMARKET's v2 Backoffice API — 17 domains (products, SKUs, orders, stock, prices, listings, NF-e, callbacks etc.), authentication rules, environments, pagination, rate limit and the greenfield vs brownfield flow for integrations./anymarket-backoffice-api-guide — or ask anything in natural language related to ERP ↔ ANYMARKET integration (TOTVS, Winthor, Protheus, SAP, custom ERP).

How to install a skill​

The idea is always the same, regardless of the harness you use:

  1. Clone (or download) the skill's repository.
  2. Copy the skill folder into the skills directory your harness reads.
  3. Reload the harness (restart, reload command, or equivalent).
  4. Confirm the skill appears in the list of available skills (/help, settings panel, etc., depending on the harness).

The exact directory path and the reload mechanism vary from harness to harness — check your harness's official docs before you start.

If the skill ships an install.sh or specific instructions in SKILL.md, follow those — some skills require environment variables (tokens, endpoints) to work.

How to create a new skill​

To propose a new skill:

  1. Draft the workflow you want to automate (input → steps → expected output) and which decisions the assistant needs to take along the way.
  2. Write SKILL.md following the existing pattern — frontmatter with name and description (trigger phrases live here), body with rules and the sub-reference map.
  3. Break content into sub-references (references/<topic>.md) to keep each file focused — the assistant only opens what it needs.
  4. Test the skill with real cases before publishing. Iterate on the trigger phrases until the assistant detects it correctly.
  5. Open the proposal with the AI & Automation team for review and publishing in the internal skills repository.

Best practices​

  • The skill's description matters. It's what the assistant reads to decide whether to invoke the skill — vague trigger phrases cause false positives and negatives.
  • One skill, one workflow. If you need to cover two very different workflows, they're probably two skills.
  • Questions before action. Skills that make sensitive changes should clarify environment / credentials / context before firing any call — it prevents rework and production errors.
  • Lean sub-references. Each file in references/ should fit a single topic. Big context costs tokens and degrades answer quality.