Skills

A skill is a procedure an agent is permitted to perform

Agents on Nagent do not act from general capability. They act through skills: documented, versioned procedures that define a specific piece of work, how it is done, and what its limits are. An agent's skill set is the precise, inspectable answer to the question "what does this agent do".

The distinction matters. A prompt describes an agent's disposition; a skill defines a unit of its work. "Handles Google Ads" is a role. "Every outbound post must pass a deterministic compliance gate before approval" is a skill: it has a trigger, a procedure, and a boundary. Agents built from skills behave predictably because every behaviour traces to a written procedure someone can read, question, and revise.

The Skills catalogue

Every skill in the workspace lives in the Skills catalogue at nagent.ai/admin/skills, searchable by key, name, description, or attached agent. The platform ships with a prebuilt set of skills, and the catalogue holds prebuilt and custom skills together; a working deployment will typically hold hundreds.

Each catalogue entry shows the skill's key, name, priority, version, description, and the agents it is attached to, with edit and delete available per skill.

The anatomy of a skill

A skill has a small set of structural fields, and a markdown body that carries the procedure itself.

The structural fields

The markdown body

The body is where the procedure lives, and well-built skills follow a consistent internal structure:

• When to use. The trigger conditions restated in full, with enough precision that an agent knows exactly when the skill governs.
• How to apply. The procedure as numbered rules, each one checkable. Strong skills write rules an agent cannot creatively reinterpret: write only to owned sections; append and supersede, never edit in place; reference by ID, never by copy; never place secrets here.
• Examples. Worked cases showing the rules applied, including what correct failure handling looks like (a rejected write goes back to the producer to fix, not relaxed to pass validation).

Guardrails, escalation rules, and rollback behaviour are written into the body as rules of the procedure, which keeps them versioned, citable, and readable in one place with the work they govern.

Patterns from the prebuilt set

The prebuilt catalogue demonstrates the skill patterns worth copying, distinguishable by their priority bands:

• Contract skills (lowest priority numbers, loaded first). Skills that define how agents share state and interact, rather than doing work themselves. A contract skill like blackboard-contract governs how every agent reads, writes, and references shared run state so that any run can be replayed, audited, and continued by a different agent instance.
• Convention skills, the "Step 0" layer. Single-source-of-truth skills holding a team's configuration, vocabulary, schemas, and hard rules, loaded before every action skill in their domain. Change the convention skill once, and every skill in the pipeline follows.
• Gate skills. Deterministic checks that work must pass before it proceeds: a compliance gate every outbound post must clear before approval, a QA gate reviewing claims and brand rules before content reaches publication. Gates are deliberately deterministic, the same input always passes or fails the same way, which is what makes them dependable as controls.
• Action skills (higher priority numbers, loaded after their foundations). The skills that perform the actual work, relying on the contracts, conventions, and gates beneath them.

This layering is why a large skill set stays governable: an agent with forty skills is not forty times harder to govern, because contracts and gates police the boundaries for all of them.

Creating a skill

Choose + Create Skill in the catalogue. Three paths:

1. Generate from a description. Describe what the skill should do, and Helix writes the instructions. The recommended starting point: the generated skill arrives structured, and is a draft for review, not a finished permission. Tighten thresholds, add the guardrails the generator could not know, and only then allow it to agents.
2. Upload files. Upload a PDF, .md, or .txt file to create a skill from it. Suited to teams porting existing SOPs onto the platform, since a good standard operating procedure is most of a skill already.
3. Write the instructions yourself. Start from a blank editor; nothing is generated.

All three paths land in the same editor, with the same required fields: key, name, description, and markdown body. The editor flags what is missing before the skill can be saved.

Attaching skills to agents

A skill's reach is controlled from the skill itself:

• Allowed agents scopes who may carry it: list the agent keys, or leave empty to allow all agents. The catalogue shows the resulting attachment per skill (attached to: with the agent list).
• The same skill serves several agents, and a revision reaches every agent that carries it, which is how house practice stays consistent: fix the procedure once, and every agent performing it is fixed.
• A new skill can be attached to an existing Agent or a new Agent by navigating to the skill tab under agent workbench and clicking on the attach button. Make sure that the skill you are attaching has this agent in the allowlist.

Versioning

Skills carry a version (V1, V2, ...), visible in the catalogue. A revision produces a new version on the record, so what an agent did last month is explained by the skill as it stood then, not as it reads today.

Skills, trust, and tools: three controls, one behaviour

An agent's behaviour on any piece of work is governed by three separate controls, and it is worth keeping them distinct:

The three compose. A skill may include sending an email; whether that send executes directly or queues for approval depends on the agent's trust level; whether the send is possible at all depends on the action scope. Widening any one of the three never quietly widens the others, which is why a skill can be shared between a junior and a senior agent safely: same procedure, different autonomy.

Writing skills that earn autonomy

The Karmic Feedback Loop judges agents by outcomes, and outcomes follow from skill quality. Skills that progress agents up the ladder share habits, all visible in the prebuilt set:

• Tight triggers. A precise When to use, so the skill fires only where it governs.
• Rules, not prose. Numbered, checkable rules in How to apply. "Append and supersede, never edit in place" is checkable; "keep good records" is an argument waiting to happen.
• Deterministic gates for consequential steps. Where work crosses into publication, spend, or personal data, put a gate skill in front of it rather than trusting each action skill to self-police.
• Fail towards the producer. Write failure handling that returns bad work to be fixed, never relaxes the check to let it pass.
• Load foundations first. Give contracts and conventions low priority numbers so nothing acts before the ground rules are in place.

What to do next

Skills come alive on agents: see The Agent Workbench for the agents that carry them, Creating an Agent for how skills fit the full agent anatomy, and Third-party tools for scoping the actions skills fire.