Back to docsCore concepts

Skills

Reusable, named procedures that teach Zero how your team does work.

Last updated May 27, 2026 · 6 min read

A skill is a named, reusable procedure that teaches Zero how your team does a specific kind of work.

The first time you ask Zero to do something, you write a prompt. The second time, you might paste the same prompt with small tweaks. By the third time, you're copying a long prompt out of a Notion doc someone called the "team prompt library." That's the moment to make it a skill.

The problem skills solve

A one-off chat is fine for a one-off task. But almost every team has a backlog of work that recurs — different inputs, same shape:

  • A customer writes in → look up their history → draft a reply in their language → log the ticket
  • A bug report appears → extract repro steps → classify severity → file a structured issue
  • Monday morning → pull last week's numbers → compare to the week before → post a digest

Without skills, each of these is a 200-word prompt that everyone has to remember. With skills, they're a slash command: /triage-bug-report, /weekly-metrics, /customer-reply.

Every skill is named with a leading /. A visual skill picker is on the roadmap — for now, you create a skill, tell your agent it exists, and the agent uses it from then on.

When to make a skill

The honest rule: if you've written substantially the same prompt more than twice — or you can imagine a teammate writing it — it's a skill.

Concrete signals:

  • The work has a name your team already uses ("morning brief," "competitor scan")
  • The prompt mentions specific tools, channels, or templates that shouldn't change every run
  • The output has a fixed shape (a digest, a draft, a filed issue)
  • Multiple people on the team need to trigger it
  • You want it to run on a schedule

What's in a skill

A skill is a short markdown document with three sections:

  • Description. A one-line summary that tells Zero when this skill applies. Zero matches incoming requests against descriptions, so phrasing matters — "triage a customer-facing bug report and file it to GitHub with severity" is better than "do bug stuff."
  • Body. The procedure itself. Plain prose works; you don't need pseudocode. Mention the tools Zero should use, the output shape, and any constraints. The body looks a lot like the original chat prompt that worked.
  • Allowed connectors (optional). A restriction list — if you only want this skill to touch Slack and GitHub, list them. By default the skill can use anything your workspace has connected.

That's it. No node graph, no YAML config, no triggers section.

Writing a skill from a chat

The fastest path is to write the prompt in chat first, get it working, then promote it. Zero can do this for you:

"Turn the last conversation into a reusable skill called triage-bug-report. Make the description tight."

Zero will:

  1. Read back the conversation
  2. Extract the procedure
  3. Propose a description
  4. Save the skill to your workspace
  5. Tell you the canonical name you can use later

Edit the saved skill from the Skills page in your workspace if you want to refine wording.

How Zero picks a skill

You don't have to invoke a skill by name. Zero loads the skill automatically when an incoming request matches its description. So if you wrote a skill called customer-reply-draft with description "draft a reply to a customer email using our voice and docs," then forwarding a customer email — or saying "draft a reply to this customer" — will trigger that skill without you naming it.

If you want to force a specific skill, mention it explicitly: "Use the customer-reply-draft skill on this email."

Built-in skills

Every Zero agent ships with a roster of cross-functional skills baked in by VM0 — covering research and analysis, finance and accounting, legal and compliance, product, marketing, customer support, and team communication. They're domain procedures, not connector workflows: each one teaches Zero how to handle a recurring kind of work.

Each is a slash command you can invoke directly. A sampler:

  • /deep-dive — structured research and solution design; gather facts, then explore options
  • /prd-writing — product requirements with structured problem framing and acceptance criteria
  • /copywriting — marketing copy across channels (blogs, emails, social, landing pages)
  • /competitor-matrix — feature comparison matrices, positioning teardowns, win/loss analysis
  • /customer-reply — empathetic, on-brand replies tailored to channel and urgency
  • /nda-screening — classify incoming NDAs as GREEN / YELLOW / RED and route them
  • /status-updates — progress reports and stakeholder updates tailored to any audience

Sharing skills across the team

Skills are workspace-scoped, not personal. Once you save a skill, every member of the workspace can use it. There's no separate "publish" step.

This matters: it means the first person to write a useful skill gives the whole team that capability. A team of five with ten well-named skills moves significantly faster than a team that handles each task individually.

Common patterns

A few shapes that show up repeatedly:

  • The intake form. A skill that takes a piece of input (an email, a bug report, a thread) and produces a structured artifact (an issue, a draft, a row).
  • The cadence brief. A skill paired with a schedule that runs daily or weekly and posts somewhere visible.
  • The mid-conversation helper. A skill triggered by @Zero in a channel that does a focused subtask (look up, summarize, classify).
  • The composer. A skill that produces a multi-format bundle — blog draft + social posts + cards — in one run.

Pitfalls to avoid

  • Skills that are too narrow. If a skill only fits one specific input, it's brittle. Aim for the shape of the work, not the input details.
  • Skills that are too vague. "Help with marketing" is so broad Zero won't know when to apply it. Be specific in the description.
  • Skills that hardcode credentials. Don't paste API keys into skill bodies. Use custom connectors instead.
  • Skills that bury the output shape. State explicitly what the artifact should look like — "a numbered list of three items" or "a draft reply under 150 words."

What's next