Skills

Skills are named, versioned instructions that add one focused capability to an Assistant, App, or Personal Chat.

Choose your path

• New to Skills: read The mental model and When to use a Skill.
• Building an Assistant or App: follow Create and attach a Skill, then read Versions and adoption. If the Skill describes an external capability, also read Use a Skill with MCP.
• Administering Eneo: start with Scopes and permissions and Governance and audit.
• Handling an incident: go to Emergency execution block.

The mental model

A Skill contains a name, a description, a stable identifier, and Markdown instructions. The description tells builders what the Skill does and when it is relevant. The instructions tell the model how to perform that capability.

A Skill is not a separate Assistant. It does not choose a model, grant access, add a tool, or own a knowledge source. It can explain how to use capabilities that the parent already has.

When to use a Skill

Good examples include employee leave guidance, IT support triage, formal decision-document structure, and safe intranet navigation.

Reuse one Skill when the capability has one real owner and release cycle. Do not merge Skills only because parts of their text look similar.

Use a Skill with MCP

Think of the two parts separately:

• Skill = guidance: explains the domain, when a capability is appropriate, which already-visible tool to use, its expected input and result, and safe failure behavior.
• MCP tool = capability: performs the external action under the target resource’s existing configuration, permissions, approval, identity, and availability checks.

For example, a municipal BI Skill can explain the data warehouse vocabulary, when to use the approved BI tool, how to form a query, and how to present the result. The Skill does not connect the BI server or grant access to it.

Before attaching that Skill:

1. Enable and approve the MCP server and tool through the existing organisation and Space controls.
2. Expose the tool to the target Assistant and keep any narrower user or policy controls in place.
3. Select a model that supports tool calling.
4. Test an allowed request, a denied request, an approval-required call, an unavailable server, and a request outside the Skill’s scope.

An Assistant cannot currently use knowledge and MCP at the same time. Tool availability can also change after a Skill is saved. Eneo therefore does not treat Skill text as a dependency declaration or perform a save-time MCP health check: the existing MCP runtime remains the source of truth and fails closed.

Create and attach a Skill

1. Open Skills in the relevant Space. Tenant admins use Organisation → Skills for organisation-wide content.
2. Name one recognisable capability.
3. Describe what it does and when a builder should choose it.
4. Write a short procedure, decision boundaries, known failure cases, and a final quality check.
5. Test typical, ambiguous, and out-of-scope requests.
6. Attach the reviewed version only to the Assistants or Apps that need it.

Keep broad organisation policy in one clear owner instead of copying it into every Skill. The Agent Skills specification  and creation guidance  provide useful authoring conventions.

Versions and adoption

Saving changed content creates the next immutable version. Unchanged content does not create a duplicate. Restoring an older version copies its content into a new latest version; history is never rewritten.

Every Assistant, App, and Personal Chat attachment points to an exact version. Editing or publishing a Skill therefore does not silently update existing resources. A builder or administrator chooses when to adopt a newer version.

On an organisation Skill’s detail page, the adoption view shows:

• how many Assistants and Apps are configured with the Skill;
• the number of distinct Spaces represented;
• whether Personal Chat pins a version;
• how bindings are distributed across versions; and
• whether each binding is current, behind, or unpublished relative to the published version.

Configured resources load 25 at a time. The count shows how many are visible, and Show more resources loads the next page.

These are structural configuration facts:

The adoption view proves configured, not model use or outcome attribution. In the current release, all attached Skills enter each request in their listed order. Selective per-question activation is not implemented.

Scopes and permissions

How a Skill reaches users

A Space controls where local Skills can be authored and attached. It does not silently add them to every resource or user in that Space. Organisation publication makes an approved version available; it does not attach the Skill by itself.

Space Skills

Space Skills are authored and reused inside one Space. Local authoring requires:

• Use Skills;
• Manage Skills; and
• the matching create, edit, or delete action on that Space.

Removing an author’s permission does not break an existing, permitted exact-version attachment.

Organisation Skills

Organisation Skills form the reviewed catalogue inside one Eneo installation. Only tenant admins author, revise, publish, unpublish, restore, and delete eligible organisation Skills.

A builder needs Use Skills and edit access to the target Assistant or App to preview and attach a published organisation Skill. Manage Skills does not grant access to organisation authoring.

Personal Chat

Tenant admins select and order published organisation Skill versions in the existing Personal Chat administration page. The organisation catalogue owns content and publication. Personal Chat settings own which approved versions apply to Personal Chat.

Default roles

The predefined Owner role receives Use Skills and Manage Skills by default. The predefined User and AI Configurator roles do not. Owners can delegate either permission through custom roles. Administrators should review custom roles after an upgrade because earlier releases did not record why each grant was assigned.

Governance and audit

The governance model has four separate controls:

1. Authoring: who may create and change content.
2. Approval: which exact organisation version is published.
3. Attachment: who may connect that version to a resource they can edit.
4. Runtime: what the parent resource is already allowed to use.

When audit logging is enabled, Eneo records lifecycle events including creation, new versions, restoration, publication changes, deletion, and attachment changes. Audit metadata includes identity, version, digest, position, status, and actor information. Full Skill instruction bodies are not duplicated into audit metadata.

Each new chat question records which Skill revisions were eligible, blocked, and included. The record also contains the selected model, measured Skill-context tokens, configured allowance, and counter source. It follows the Question’s existing Assistant, Space, or tenant retention and deletion rules. It excludes prompts, Skill instructions, incident reasons, tool results, and hidden reasoning, and the standard chat response does not expose it.

See the Audit Logging Guide for access, retention, and export behavior.

Emergency execution block

A tenant admin can block execution of any organisation Skill that has been published before. Use this for a confirmed safety, security, compliance, or operational incident. Reading or changing the incident state requires a signed-in tenant admin or their user-owned tenant admin API key; service credentials cannot operate this human-audited control.

• The block covers every saved version in Personal Chat, Assistants, and Apps.
• New Personal Chat and Assistant requests omit the blocked Skill while the parent continues to run.
• Apps configured with the Skill fail before provider work, including queued runs whose saved snapshot predates the block. Runners see a generic stop message; only tenant admins can read the incident reason.
• A request whose Skill plan was already resolved may finish. The next request sees the block.
• New attachments and revision changes are rejected while the block is active. Unchanged exact-version pins remain visible and survive unrelated saves or reordering.
• Bindings, publication state, versions, and adoption evidence remain intact.
• Blocking and unblocking both require a reason. The lifecycle record remains durable even when optional audit logging is disabled.

Unblocking restores the Skill to Personal Chat and Assistants and lets affected Apps run again. This applies immediately to resources pinned to older versions. Review the adoption view and update or remove unsafe versions before unblocking.

Current boundaries

• Skills contain instructions and metadata. They do not execute scripts or import bundled files.
• Skills do not grant models, tools, knowledge, or permissions.
• Every attached Skill currently enters every request in its listed order.
• Organisation approval and exact pins do not update existing resources automatically.
• This release has no external Skill marketplace or package installation flow.

Planned next steps

The next runtime change will let Assistant builders and tenant admins choose between always and on demand for each approved binding. On-demand Skills will advertise a compact description and load the exact pinned instructions only when a tool-capable model requests them. Apps will remain eager.

Eneo will show the selected model, measured Skill budget, and whether every attached Skill is discoverable. Tenant admins will be able to change the seeded 10% total Skill-context share in Admin > Overview without a code change or deployment; the model window and platform safety bounds still apply. Eneo will reject a new configuration in which an advertised Skill could never be loaded, instead of hiding a subset. Models without tool calling will keep only always Skills and show that limitation.

Editable Space copies with explicit source updates come later. External Marketplace distribution remains a separate final phase.

FAQ

Does editing a Skill immediately change every Assistant that uses it?

No. Attachments point to an exact version. Each parent must explicitly adopt a newer version.

Can an organisation Skill reach every user?

Not by publication alone. Publication makes one exact version available. Builders still need Use Skills and edit access to attach it to an Assistant or App. Tenant admins separately decide whether it applies to Personal Chat.

Can a Skill grant access to a tool or knowledge source?

No. It can guide use of capabilities the parent already has, but the parent, Space, and organisation policies remain the access owners.

What does “behind” mean?

The resource pins an older exact version than the currently published one. It is configuration drift, not evidence that the Skill ran or affected an answer.

What happens if a published update is worse?

Compare the history and restore the earlier content. Eneo creates a new latest version, which an admin can review and publish without deleting history.

Why keep Personal Chat configuration separate?

It preserves one policy owner. The catalogue governs approved Skill content; Personal Chat settings govern which approved instructions apply to all Personal Chat requests.

Does an emergency block remove the Skill from configured resources?

No. It stops runtime composition while preserving exact pins and adoption evidence. This lets administrators see the full impact, remediate resources, and later unblock with an auditable reason. Removing the bindings would erase that operational context and make recovery a manual reconfiguration task.

When can I delete a Skill?

First detach it from every Assistant, App, and Personal Chat policy. A queued or running App run whose history still exists also blocks deletion until it completes or fails. Completed and failed runs keep only the Skill and revision IDs, revision number, digest, and position—not the instruction body. Previously published organisation Skills remain as audit history and cannot be hard-deleted.