Skills

A skill is a short markdown primer the assistant loads on demand. Skills solve a specific problem: tool descriptions can't be long enough to teach the model your workspace conventions, but you don't want a 50-page system prompt on every turn either. Instead, the assistant browses a list of skills, decides "I'll need the writing_python_in_dalea primer for this question", and pulls in that one body instead of carrying every primer from the start.

The three scopes

Every skill lives in exactly one of three scopes. Built-in names win on a collision: the API rejects a workspace or personal skill that reuses one.

Built-in (global)

Ships in the platform. Maintained by the Dalea team. Every workspace sees the same set; cannot be edited or shadowed.

Workspace

Authored by any member of the workspace. Visible to every member of the workspace.

Personal

Authored by you, visible only to you. Use for personal shorthand, draft skills, or one-off domain notes that don't belong to the team yet.

The built-in skills

Ten primers ship with the platform out of the box:

analyzing_workspace_files

Working with uploaded files — attaching them to the sandbox, parsing common formats, and getting results back into the workspace.

designing_data_environments

Designing a data environment — entity vs result vs inventory tables, the ten column types and their typeConfig shapes, displayPattern IDs, references, and atomic entity-row registration.

editing_dalea_documents

Authoring and editing documents — when to read a document outline vs the full content, how custom block fences work, how to safely round-trip grid blocks and registration tables.

gxp_data_capture

Regulated data capture — reasons for change, review gates, and the audit expectations GxP workspaces carry.

importing_data

Structured imports — persisted mappings, staging-target dry runs, and committing only when the preview is green.

maintaining_provenance

Keeping the provenance graph healthy while writing — runs, receipts, and recording external work.

querying_data

Reading and aggregating data — data_queries_read vs result_data_read, joins and result hops, groupBy breakdowns, inventory tables with their reserved custody fields, and the common validation errors.

verifying_provenance

Auditing data lineage — walking the provenance graph and verifying integrity anchors.

writing_addons

Authoring workspace addons — the manifest, capabilities, and the publish/build cycle.

writing_python_in_dalea

Writing Python in a document's embedded Pyodide block — the globals (get_block, get_sheet, get_cell), what the sandbox does and doesn't allow (no filesystem, no network).

The assistant pulls these in by name as it works; you don't usually need to do anything. Built-in skills are always enabled unless you explicitly turn one off.

Activating, deactivating, authoring

Settings → AI Skills lists every skill visible to you (built-in, workspace and personal) with a toggle for each, and is where you author workspace-shared skills. To create a personal skill, open Create → AI skill and switch the scope toggle to Personal. Workspace skills can also be authored from Settings → Workspaces → <workspace> → AI Skills. Deactivating a skill in the settings removes the capability for an agent (in-platform or through MCP) to read the skill.

The editor enforces the same limits as the API:

Name

Lowercase, starts with a letter, 2-64 chars, may include digits and underscores. Pattern: ^[a-z][a-z0-9_]{1,63}$

Description

1-200 characters, single line (no newlines). This is what the assistant sees when deciding whether to load the skill — make it descriptive.

Body

Markdown, 1-20,480 characters (≈ 5,000 tokens, or roughly 500 lines of prose). This is the content the assistant pulls in once it decides to load the skill. The cap targets Anthropic's Agent Skills guidance — the body is returned as a tool-call payload that persists in the conversation, so big skills crowd context and disrupt prompt-cache reuse. If you need more, split into multiple skills the assistant can load on demand rather than one giant body.

You cannot publish a workspace or personal skill that shadows a built-in name — the API rejects it at write time.

Permissions

The skills API does not check a workspace permission: workspace-scoped rows are isolated by the workspace boundary, not by role. MANAGE_AI_SKILLS (held by the owner and data_engineer roles by default) only decides whether the AI Skills tab is rendered under Settings → Workspaces → <workspace>. The same authoring surface is reachable without it from Settings → AI Skills.

How the assistant uses them

The list of activated skills, names and descriptions only, is injected into the assistant's system prompt as a skills section. When a skill looks relevant, the assistant calls load_skill(name) to pull the body into the conversation.

That list is resolved once, when the conversation starts, and stays frozen for the rest of it, which is what keeps the prompt cache stable. A skill you enable, disable or author mid-conversation is therefore not in the list; the assistant sees it only after calling list_skills to re-read the current set.

A body you load stays in the conversation history for the rest of the session. That is what the 20,480-character cap is for: split detail across several skills the assistant can load one at a time rather than shipping one giant body.

This means a high-quality description matters more than you'd think: it's how the assistant decides whether to look in the first place. "Authoring ELISA result protocols including dilution and curve-fit conventions" beats "ELISA things".

What's next