---
sidebar_position: 0
title: Skills reference
---

# Skills reference

Per-skill reference for everything shipped in `@zibby/skills`. For the mental model and how to attach skills to nodes, see [Concepts → Skills](../concepts/skills.md). For the package-level API (`skill()` factory, `registerSkill`, middleware), see [`@zibby/skills`](../packages/skills.md).

## Built-in skills

| Skill | ID | Tools | Setup |
|---|---|---|---|
| [Browser](./browser.md) | `browser` | Playwright (navigate, click, type, snapshot, video) | None — bundled with `@zibby/cli` |
| [Sentry](./sentry.md) | `sentry` | `sentry_list_projects`, `sentry_list_issues`, `sentry_get_issue` | OAuth (PKCE) |
| [Lark](./lark.md) | `lark` | `lark_send_message`, `lark_reply`, `lark_list_chats`, `lark_get_chat_history` | App ID + App Secret |
| [GitHub](./github.md) | `github` | Repos, PRs, issues, commits, file reads, clone | GitHub App or `GITHUB_TOKEN` |
| GitLab | `gitlab` | Repos, MRs, issues, pipelines (self-hosted or SaaS) | `GITLAB_TOKEN` (+ base URL) |
| [Slack](./slack.md) | `slack` | Channels, post/reply, reactions, history, users | Bot token + team ID |
| [Jira](./jira.md) | `jira` | Issues, sprints, comments, transitions | Atlassian OAuth |
| Linear | `linear` | `linear_list_issues`, `linear_get_issue`, `linear_add_comment`, `linear_update_state`, `linear_list_teams/states/labels` | `LINEAR_API_KEY` |
| Plane | `plane` | Projects, work items, cycles, modules, epics, comments (official MCP) | `PLANE_API_KEY` (+ `PLANE_WORKSPACE_SLUG`, `PLANE_BASE_URL`) |
| Notion | n/a | Not an attachable MCP skill — a [connectable integration](../integrations/notion.md). Agents publish a `report` object to Notion blocks (`reportToNotionBlocks`), e.g. the `notify-notion` template | OAuth (dashboard) / `NOTION_API_KEY` (SDK) |
| [Memory](./memory.md) | `memory` | Test history, selectors, page model (Dolt) | `zibby init --mem` |
| [Chat memory](./chat-memory.md) | `chat-memory` | `memory_store`, `memory_recall`, `memory_brief`, `task_log`, `task_history` | None (Dolt or mem0) |
| [Core tools](./core-tools.md) | `core-tools` | `read_file`, `write_file`, `list_directory`, `run_command`, `open_url`, `wait` | None |
| [Function skill](./function-skill.md) | n/a | Author-defined | Define with `skill()` |

## Attaching a skill

```js
import { WorkflowAgent, WorkflowGraph } from '@zibby/core';
import { SKILLS } from '@zibby/skills';

graph.addNode('triage', {
  agent: 'claude',
  skills: [SKILLS.SENTRY, SKILLS.SLACK],
  prompt: (state) => `Find unresolved Sentry issues and post a summary to #alerts.`,
});
```

## MCP architecture in one paragraph

When a node executes, the strategy reads its `skills` array. For each skill it calls `skill.resolve(...)`, which returns either a stdio spawn spec (`{ command, args, env }`) or `null` for in-process skills. The Agent SDK launches each spec as an MCP server and exposes its tools to the LLM under the prefix `mcp__<serverName>__<tool>`. The skill's `promptFragment` is appended to the system prompt so the model knows the tools exist. In-process skills (`core-tools`, `chat-memory`, function skills with a `handler`) skip the spawn and the strategy dispatches tool calls directly via `handleToolCall`.

See [`@zibby/skills`](../packages/skills.md) for the full skill object shape and how to author your own.