Skills

A skill is a package of instructions, resources and executable code that the Digital Worker loads when it needs them. Rather than cramming every process into the Instructions, you split the repeatable parts into skills the Digital Worker can reach for at the right moment.

Two kinds of skill

Kind	What it means
Digital Worker-owned skill	Used only by this Digital Worker, usually created by the assistant while it builds
Workspace skill	Shared across several Digital Workers, attached with Connect workspace skill

Every skill carries a version number and an on/off state, along with how many Digital Workers are using it.

System skills (built-in)

Not to be confused with Digital Worker capabilities. System skills are document-handling skills (PDF, Word, Excel, PowerPoint) that live in the Skills screen. Digital Worker capabilities are the Digital Worker’s ten platform-level abilities (long-term memory, web search, code execution and so on), switched from Instructions, in the right column, under Advanced settings.

Besides the skills you write yourself, every Digital Worker ships with a set of built-in capabilities from the platform: reading files, and working with PDF, Word, Excel and PowerPoint documents, plus design guidance for building interfaces. You decide which ones to keep and which to switch off, so the Digital Worker does only the work you want it to.

Switching an agent's built-in capabilities on and off

Finding the list

Open the Skills screen

Open the Digital Worker and pick Skills in the left column of the Build screen. The Configuration column on the right of the Instructions screen also lists a few built-in capabilities with their switches; click View all to see the whole set.

Pick the System tab

The skill list has four tabs: All, Digital Worker’s own, Connected and System. The built-in capabilities sit in the last one, and each card carries a System label.

What each system skill does

Capability	What the Digital Worker can do
`file-reading`	Read files the user uploads. It works as a router: it looks at the file type and picks the right tool, instead of opening a file blindly
`pdf`	Read, extract, split, merge, rotate, watermark, fill forms and run OCR on PDF files
`docx`	Read and produce Word files (.docx, .doc)
`xlsx`	Read and produce Excel spreadsheets (.xlsx, .xls, .csv)
`pptx`	Read and produce PowerPoint decks (.pptx, .potx)
`frontend-design`	Design guidance for when the Digital Worker builds an interface or produces an HTML file

Switching one on or off

Each card has a switch in its top right corner. Flip it and you are done, there is nothing else to save. A card that is on reads Active. Switching a capability off means the Digital Worker can no longer call it, whatever the Instructions say. Turn pptx off and the Digital Worker cannot produce a deck; it will say so plainly rather than trying anyway.

Switching off what the Digital Worker does not need keeps it focused. A Digital Worker that only looks up policies on SharePoint has no use for pptx or frontend-design, and dropping those two leaves it less to weigh up when choosing a tool.

Built-in capabilities cannot be deleted, only switched on or off. They also do not take the place of your own skills: a Digital Worker carries its own skills, its workspace skills and the built-in capabilities all at once.

The setting belongs to the version

Flipping a switch changes the Digital Worker’s draft only. The Digital Worker serving real users keeps running the set of capabilities in the published version, until you publish a new one. In other words, every version records its own set of built-in capabilities. Roll back to an earlier version and that version’s set comes back with it.

Switch a capability off and forget to publish, and the Digital Worker on your deployment channels is still using it. After making a change, open the Publish dialog and read the Changes list before you release.

Adding a skill to a Digital Worker

Create skill - write a new skill for this Digital Worker alone.
Connect workspace skill - pull in one that already exists in the workspace.
Ask the assistant - describe the work that keeps repeating, and it proposes a matching skill for you to approve.

The Skills catalogue in Console

The Digital Worker’s Skills screen is split into four tabs, each with a count: All, Digital Worker’s own, Connected and System. The search box underneath filters by name.

The Skills catalogue with the actions menu of a shared skill open

The ⋯ menu on a skill card has three actions:

Action	What happens
Edit	Opens the form to change the skill
Share	Makes the skill available across the workspace
Delete	Removes the skill for good, shared ones included

Deleting a shared skill affects every Digital Worker using it. When in doubt, switch the toggle on the card off first and watch what happens.

Editing an older version directly

The version selector at the top of the screen lets you open a published version and switch skills on or off, or add one, right there. Guardrails work the same way.

Editing, deleting and switching skills off

Edit a skill

Click a skill card in the list to reopen the form - change the Name, Description, Skill type or Icon, or review the SKILL.md file tree and everything shipped with it. If other Digital Workers are using the skill, Console warns you first: “This skill is used by N Digital Workers - changes will affect all of them.”

Remove a skill from the Digital Worker

Click the bin icon next to the skill name. For a Digital Worker-owned skill, removing it deletes it outright. For a workspace skill, removing it here only unlinks it from this Digital Worker - the original stays in the workspace and other Digital Workers carry on using it.

Switch a skill on or off

Workspace skills only. Go to Resources > Skills, find the skill and flip the Enabled switch off. Switching it off makes it unavailable to EVERY Digital Worker that has it attached, not just the one you are looking at - use it when you want to pause a skill without throwing away its configuration.

Digital Worker-owned skills - the ones created inline while building a Digital Worker - have no on/off switch. They can only be edited or deleted outright.

Uploading a skill from a file

Instead of writing one out in the form, you can upload a skill prepared elsewhere - handy when it was authored outside Console, shared between teams or kept in git. Console accepts three formats: .md, .zip and .skill (a .skill file is really just a zip with a different extension).

.md - instructions only

Use this when the skill is plain text guidance with nothing attached. The file has to open with a YAML block between two --- lines:

SKILL.md

---
name: email-triage
description: Use when the user asks to process the inbox - classify, label, summarize emails and propose actions. Trigger words: classify email, process inbox, triage inbox.
version: 1.0.0
---

# Email triage and summary

The repeatable process for working through the inbox: classify, label, summarise...

Field	Required	How to write it
`name`	Yes	Lowercase, hyphen-separated. Best kept the same as the file name or the package root folder
`description`	Yes	One sentence answering “when should this skill be used”. The model reads exactly this line to decide whether to call the skill, so include the trigger words
`version`	Recommended	In the form `1.0.0`. Console shows it on the skill card

Everything below the YAML block is the Markdown guidance itself - what the Digital Worker reads and follows once the skill fires.

.zip / .skill - a skill with resources

When a skill needs reference material, runnable code or template files, package it all into a zip. The only rule the system enforces: there must be a SKILL.md at the root of the package. How you arrange the rest is up to you, though the convention below helps the Digital Worker find its way:

debt-reconciliation/
├── SKILL.md                  # required - YAML plus the main instructions
├── references/               # reference material, opened only when needed
│   ├── matching-rules.md
│   └── error-codes.md
├── scripts/                  # executable code
│   ├── reconcile.py
│   └── export_excel.py
└── assets/                   # templates and output shells
    ├── report-template.html
    └── company-logo.png

Once uploaded, opening the skill shows the file list in the package next to SKILL.md, with buttons to view the contents and download the package.

A package keeps every file type

When you upload a .zip or .skill package, nothing inside is filtered out by format. The Digital Worker can read binary files that travel with the package, so a skill can carry an Excel template, a PDF, an illustration or a sample data file and use them while it runs.

File requirements on upload:

Format	Condition
.md	Must carry a name and a description in YAML
.zip or .skill	Must include a SKILL.md file

.skill is just a zip with a different extension, so both formats are packaged exactly the same way.

Put resources in subfolders by purpose, then point to them from SKILL.md. The Digital Worker opens a file only when it needs it, so a tidy package runs faster and goes wrong less often.

Why split it up instead of putting everything in SKILL.md

The Digital Worker does not load the whole package into context on every run. It reads in three tiers:

Read the description

The description line is always in context. The Digital Worker uses it to decide whether the current request needs this skill at all.

Load SKILL.md

Once the skill fires, the full set of instructions in SKILL.md is loaded.

Open attached files on demand

Files under references/, scripts/ and assets/ are only read or run when SKILL.md points at them.

That is how a skill carrying a few hundred pages of regulation still costs nothing in context until the Digital Worker actually needs it. The rule of thumb: keep SKILL.md short - the procedure, the stopping conditions and the paths to the detail - and push the long material into references/.

Example: a debt reconciliation package

At the end of every month, accounting has to reconcile bank statements against the debt tracker on SharePoint and produce a report for the department head. The process is fixed, but it runs to many steps and leans on a long table of matching rules. Packaged up:

File in the package	What it holds
`SKILL.md`	The six steps of the process, where to stop and ask the user, and paths to the three files below
`references/matching-rules.md`	The matching rule table and the variance thresholds that can be ignored
`scripts/reconcile.py`	Reads both sources, matches them and returns the list of discrepancies
`assets/report-template.html`	The report shell for the Digital Worker to fill in

When an accountant types “reconcile August debt”, the Digital Worker recognises it from the description, loads SKILL.md, runs reconcile.py, opens matching-rules.md only when it hits a mismatch, then builds the report from report-template.html.

Keep skill names lowercase and hyphen-separated - email-triage, debt-reconciliation - and matching the root folder inside the zip. Names with spaces or accented characters tend to break when the Digital Worker calls the skill.

A skill is worth splitting out when it has a clear procedure and gets used repeatedly - summarising a recurring report, say, or triaging incoming email. Something you do once is tidier left in the Instructions.

Introduction

FPT AI Console

Two kinds of skill