Skip to main content
A skill packages specialized know-how — a procedure, a checklist, a set of decision rules — that a worker can call on without you cramming it into the worker’s core instructions. Skills sit quietly in the background until a task actually needs them, then load in full.

​
Why skills beat longer instructions

Every worker’s instructions ride along on every turn of every task, so they’re the right place for house rules, voice, and conventions that always apply. They’re the wrong place for a deep, occasional procedure. Pile enough specialized how-tos into instructions and two things go wrong: the worker’s core guidance gets diluted by content that’s only relevant some of the time, and every task pays the token cost of that content even when it never comes up. Skills fix this by living outside the instructions and loading only when the task at hand actually calls for them — the worker’s core setup stays lean, and specialized know-how is still one call away.

​
What’s inside a skill

Conceptually, a skill is a small package built around a SKILL.md file with three parts:
  • Name — a short identifier the worker uses to refer to the skill.
  • Description — one or two sentences saying what the skill does and when to use it. This is the only part shown to the worker up front, so a precise, specific description is what makes the worker reach for the right skill at the right moment.
  • Body — the actual instructions: the procedure, decision branches, and known fixes the worker follows once it decides the skill applies. A skill’s body can also point to other bundled files (scripts, templates, references), so the worker pulls in exactly the resource it needs, one layer at a time.
A good skill description reads like a menu blurb, not a table of contents. “Reconciles two CSV exports and flags mismatched line items” tells the worker exactly when to reach for it; “Reconciliation helper” doesn’t.

​
Progressive, on-demand loading

At the start of a task, a worker sees only a short index of its enabled skills — name and description, nothing more. No skill body loads until the worker decides that skill is relevant to the job in front of it. This progressive disclosure — index first, full body second, any linked files last — is what keeps a worker’s context window from filling up with know-how it isn’t using on a given task. It’s the same discipline that governs how a worker’s tools and connections come into context; see Context & memory for the fuller picture of how skills fit alongside instructions, memory, and the rest of what a worker carries into a task.
Loading a skill only affects the current task. It doesn’t change the worker’s core setup, so the same worker starts its next task exactly as lean as before.

​
Attaching skills to a worker

Skills come from a catalog — some ready-made by CogniAgent, others created for your workspace. To give a worker access to one, turn it on from the worker’s skills list. Once enabled, the worker can draw on that skill in any task it runs, without you re-explaining the procedure every time it’s relevant. Skill changes, like other worker edits, take effect on the worker’s next task rather than retroactively changing a task already in progress.

​
Skills vs. capabilities: know-how vs. tools

Skills and capabilities solve different problems, and it’s worth keeping them separate in your head:
  • Capabilities are what a worker can do — integrations and connections, wired up through the Connection Manager, exposed to the worker as callable tools.
  • Skills are what a worker knows — the judgment, procedure, or checklist for doing a job well, often by using capabilities it already has.
A skill doesn’t grant a worker any new tool access on its own. It’s guidance layered on top of the capabilities a worker already has — so a “customer refund” skill might tell a worker how to decide when a refund is warranted, but the worker still needs a billing connection to actually issue one.

​
Capturing skills from a session

The best skills often come from watching a worker actually do the job well once. A planned Learn capability will let you turn a finished task into a reusable skill: the worker proposes one, you review and edit it, and only then does it join the worker’s library.
Learn is on the roadmap and not yet available. See Self-improvement & learning for the current thinking on capturing skills from real sessions.

​
Next steps

Capabilities & connections

Give a worker tools to act, not just know-how to draw on.

Context & memory

See how skills fit alongside instructions and memory in a worker’s context.

Self-improvement & learning

Where automatic skill capture from sessions is headed.

Workers overview

See the full anatomy of a worker, instructions included.