Skills

A skill is a small bundle of context that a single workflow node can load before it does its work. The model gets a short instruction set, a few examples, and any tool capabilities the skill declares, all wrapped up as one named thing. Useful when one specific node needs more setup than the rest of the workflow.

This page lives under Advanced because most workflows don't need skills. Reach for them when you've got a step where the model keeps getting the same kind of thing wrong, and you'd fix it by giving it more context.

What a skill looks like

Skills live at /skills/<skill-name>/SKILL.md in the repo (or in your global skills folder). The file is plain markdown with a frontmatter block:

---
name: meeting-summary-shape
description: Specific format and tone we use for meeting summaries.
---

# Meeting summary shape

Summaries are always three sections:

1. Decisions made (with the why).
2. Open questions (no speculation, just what's unresolved).
3. Action items (with owners if assigned).

Tone: direct, no filler, no "great meeting today!" openers.

Examples:

[Past examples that match the format...]

That entire file is what the model reads when the node calls the skill.

Calling a skill from a workflow node

nodes:
  - id: summarize-meeting
    type: prompt
    skills: [meeting-summary-shape]
    prompt: |
      Summarize this transcript using the meeting-summary-shape skill.

      $transcript.output

The skill file is loaded into the model's context before the prompt body. Multiple skills are loaded in order if you list multiple.

When to use a skill vs. a prompt template

The line is fuzzy but useful:

• Template is a reusable prompt body. The whole thing IS the instruction.
• Skill is context the prompt body references. The skill is loaded; the prompt body then says "use the skill to do X."

Templates are about saving the prompt. Skills are about giving the model knowledge it would otherwise need to learn from scratch every run.

Discovery

Skills get registered at server startup. The Web UI's Skills page lists every skill Z.E.N. found. zen skill list does the same from the terminal.

If you write a new skill while the daemon is running, the daemon picks it up on the next reload. There's no separate registration step.

Provider-specific behavior

Skills are loaded as preface context for the provider's first turn. Claude, Codex, and Pi all support this. The exact mechanism (system prompt, separate context document, MCP resource) varies by provider, but from the workflow's perspective the behavior is identical: the skill content is in the model's working memory when the prompt fires.

Inheritance

If a workflow declares skills at the workflow level, every node inherits them unless the node overrides:

name: meeting-pipeline
skills: [meeting-summary-shape]

nodes:
  - id: a
    type: prompt
    # inherits meeting-summary-shape

  - id: b
    type: prompt
    skills: [different-skill]
    # this node only gets different-skill, not the workflow-level one

When to add a skill

Watch for the pattern: a node keeps producing output that's close but not quite right, and every time you fix it by adding more context to the prompt. After the third correction, the corrections themselves probably belong in a skill, not in the prompt body.