@zibby/skills 0.1.33 → 0.1.34

package/docs/integrations/lark.md

@@ -9,7 +9,7 @@ Connect a Lark (Feishu) self-built app so your agents can send messages, reply,
 
 ## How It Works
 
-You create a self-built app in the Lark Developer Console and paste its App ID and App Secret into Zibby. Optionally add a Verification Token and Encrypt Key if you want inbound Lark events to trigger Zibby workflows. The `lark` skill then exposes Lark's API to any node that declares it.
+You create a self-built app in the Lark Developer Console and paste its App ID and App Secret into Zibby. Optionally add a Verification Token and Encrypt Key if you want inbound Lark events to trigger Zibby agents. The `lark` skill then exposes Lark's API to any node that declares it.
 
 ## Connect Lark
 
@@ -32,7 +32,7 @@ Nodes that attach the [`lark` skill](../skills/lark.md) get `lark_send_message`,
 
 ## Inbound events
 
-Adding the Verification Token (and Encrypt Key, if enabled) lets Lark events fire your Zibby workflows. Leave them blank for outbound-only (notifications).
+Adding the Verification Token (and Encrypt Key, if enabled) lets Lark events fire your Zibby agents. Leave them blank for outbound-only (notifications).
 
 ## Troubleshooting
 

package/docs/integrations/linear.md

@@ -34,7 +34,7 @@ Once connected, nodes that attach the [`linear` skill](../skills/index.md) get t
 
 ## Reference key (SDK / CLI)
 
-When running workflows directly (local or CI), the same connector reads from the `LINEAR_API_KEY` environment variable instead of the dashboard-stored credential.
+When running agents directly (local or CI), the same connector reads from the `LINEAR_API_KEY` environment variable instead of the dashboard-stored credential.
 
 ## Troubleshooting
 

package/docs/integrations/notion.md

@@ -20,11 +20,11 @@ You authorize Zibby against a Notion workspace via OAuth. Notion returns a long-
 
 ## What Agents Can Do
 
-Workflows can render a `report` object straight to Notion blocks (`reportToNotionBlocks`) and publish it to a connected page or database — the same digest you can route to Slack or Lark. The `notify-notion` template is the shipped example.
+Agents can render a `report` object straight to Notion blocks (`reportToNotionBlocks`) and publish it to a connected page or database — the same digest you can route to Slack or Lark. The `notify-notion` template is the shipped example.
 
 ## Reference key (SDK / CLI)
 
-When running workflows directly, the connector reads `NOTION_API_KEY` from the environment (a Notion internal-integration token works for the SDK path).
+When running agents directly, the connector reads `NOTION_API_KEY` from the environment (a Notion internal-integration token works for the SDK path).
 
 ## Troubleshooting
 

package/docs/integrations/plane.md

@@ -33,7 +33,7 @@ Nodes that attach the [`plane` skill](../skills/index.md) get tools for projects
 
 ## Reference keys (SDK / CLI)
 
-When running workflows directly, the connector reads `PLANE_API_KEY`, `PLANE_WORKSPACE_SLUG`, and `PLANE_BASE_URL` from the environment.
+When running agents directly, the connector reads `PLANE_API_KEY`, `PLANE_WORKSPACE_SLUG`, and `PLANE_BASE_URL` from the environment.
 
 ## Pairs well with hosted Plane
 

package/docs/integrations/slack.md

@@ -24,7 +24,7 @@ Nodes that attach the [`slack` skill](../skills/slack.md) get tools to list chan
 
 ## Reference (SDK / CLI)
 
-When running workflows directly, the connector reads the bot token and team ID from the environment.
+When running agents directly, the connector reads the bot token and team ID from the environment.
 
 ## Troubleshooting
 

package/docs/intro.md

@@ -9,7 +9,7 @@ pagination_next: get-started/install
 
 **The cloud platform for AI agents — built on Claude Code, Cursor, Codex, and Gemini.** Compose real coding-agent CLIs into structured agents with Zod-validated handoff between nodes, then deploy them to the cloud. Vendor-neutral. JavaScript-first.
 
-> **"Agent" is the product noun** for a deployed automation. Under the hood, an agent is a *workflow* — a graph of agent-CLI calls — and the CLI / SDK / API still speak "workflow". The CLI command is `zibby agent` (`zibby workflow` still works as an alias).
+> An **Agent** is a deployed automation — a graph of coding-agent CLI calls with Zod-typed handoff between nodes. Build and ship one with the `zibby agent` CLI.
 
 ```
             ┌──────────┐    ┌──────────┐    ┌──────────┐
@@ -29,7 +29,7 @@ graph
 
 ## Try it now
 
-The CLI command is `zibby agent` (`zibby workflow` still works as an alias):
+Get started in seconds:
 
 ```bash
 npm install -g @zibby/cli
@@ -55,7 +55,7 @@ zibby template add <name>                  # add a template later (overwrites =
 
 ## What you get
 
-- **Multi-vendor** — mix Claude Code + Codex + Cursor + Gemini in one pipeline. Anthropic will never help you orchestrate Codex; multi-vendor neutrality is structural.
+- **Multi-vendor** — mix Claude Code + Codex + Cursor + Gemini in one agent. Anthropic will never help you orchestrate Codex; multi-vendor neutrality is structural.
 - **Schema-enforced handoff** — Zod validates every node's output before the next runs. No prompt-stuffing.
 - **Run anywhere** — local with hot reload, or cloud with Heroku-style bundles (~3s cold start).
 - **Session replay** — every run lands as on-disk JSONL + artifacts. Re-run any node via `--session <id> --node <name>`.
@@ -72,7 +72,7 @@ zibby template add <name>                  # add a template later (overwrites =
 | Billing | Per execution | Per minute, while running |
 | Best for | "When ticket lands, classify it" | "Host Grafana for the team" |
 
-An **Agent** is a deployed automation (a workflow graph under the hood). An **App** is a hosted open-source application. Pick by how long the thing needs to run — see [Apps overview](./apps/) for the decision tree.
+An **Agent** is a deployed automation. An **App** is a hosted open-source application. Pick by how long the thing needs to run — see [Apps overview](./apps/) for the decision tree.
 
 ## How it compares
 

package/docs/legacy/test-automation.md

@@ -63,7 +63,7 @@ npx playwright test tests/login.spec.js
 
 ## Customizing Your Setup (Optional)
 
-If you want to customize the workflow, config, or nodes:
+If you want to customize the agent, config, or nodes:
 
 ```bash
 zibby init --agent cursor
@@ -82,7 +82,7 @@ This scaffolds:
 └── result-handler.js      # Post-execution hooks
 ```
 
-Without `zibby init`, the CLI uses the built-in default workflow automatically.
+Without `zibby init`, the CLI uses the built-in default agent automatically.
 
 ## Environment Variables
 

package/docs/packages/cli.md

@@ -16,18 +16,18 @@ zibby --version
 
 ## What it does
 
-- **Scaffolds** workflows: `zibby workflow new <name>`
-- **Runs** workflows locally (one-shot): `zibby workflow run <name>`
-- **Deploys** to Zibby Cloud (Heroku-style bundles): `zibby workflow deploy <name>`
-- **Triggers** deployed workflows: `zibby workflow trigger <uuid>`
-- **Tails** logs: `zibby workflow logs <uuid> -t`
+- **Scaffolds** agents: `zibby agent new <name>`
+- **Runs** agents locally (one-shot): `zibby agent run <name>`
+- **Deploys** to Zibby Cloud (Heroku-style bundles): `zibby agent deploy <name>`
+- **Triggers** deployed agents: `zibby agent trigger <uuid>`
+- **Tails** logs: `zibby agent logs <uuid> -t`
 - **Manages** auth: `zibby login`, `zibby logout`, `zibby status`
 
 The full command catalog lives at [CLI Reference](../cli-reference).
 
-## Self-contained workflow projects
+## Self-contained agent projects
 
-`zibby workflow new` creates a workflow as a **self-contained npm project** — its own `package.json`, its own `node_modules`. So a workflow can pull in arbitrary deps (PDF libraries, custom MCP servers, your own SDK) without polluting the parent project.
+`zibby agent new` creates an agent as a **self-contained npm project** — its own `package.json`, its own `node_modules`. So an agent can pull in arbitrary deps (PDF libraries, custom MCP servers, your own SDK) without polluting the parent project.
 
 ```
 my-app/
@@ -35,14 +35,14 @@ my-app/
 ├── src/
 └── .zibby/
     └── workflows/
-        └── my-pipeline/
-            ├── package.json     # workflow's own deps
+        └── my-agent/
+            ├── package.json     # agent's own deps
             ├── node_modules/
             ├── graph.mjs
             └── nodes/
 ```
 
-The cloud bundle build does the same — `npm install` runs *inside* the workflow folder, scoped to its own package.json.
+The cloud bundle build does the same — `npm install` runs *inside* the agent folder, scoped to its own package.json.
 
 ## Configuration
 
@@ -65,7 +65,7 @@ export default {
 };
 ```
 
-`zibby workflow deploy` resolves this file locally and ships the result as `zibby.config.json` inside the deploy bundle, so the cloud runtime sees the same `agent` block, per-node `models`, and other declarative knobs as your local runs. Function values are dropped at deploy time (config is data, not code) — if you need runtime variation in cloud, use [per-workflow env vars](../cloud/env-vars).
+`zibby agent deploy` resolves this file locally and ships the result as `zibby.config.json` inside the deploy bundle, so the cloud runtime sees the same `agent` block, per-node `models`, and other declarative knobs as your local runs. Function values are dropped at deploy time (config is data, not code) — if you need runtime variation in cloud, use [per-agent env vars](../cloud/env-vars).
 
 ## Source
 

package/docs/packages/core.md

@@ -7,7 +7,7 @@ title: '@zibby/core'
 
 [![npm](https://img.shields.io/npm/v/@zibby/core.svg)](https://www.npmjs.com/package/@zibby/core)
 
-The batteries — five built-in agent strategies, the runtime, and a re-export of the `@zibby/agent-workflow` engine. This is what `zibby workflow new` scaffolds workflows against.
+The batteries — five built-in agent strategies, the runtime, and a re-export of the `@zibby/agent-workflow` engine. This is what `zibby agent new` scaffolds agents against.
 
 ```bash
 npm install @zibby/core
@@ -63,7 +63,7 @@ Functions used by the cloud executor and Studio integration — `ZibbyRuntime`,
 
 | Goal | Pick |
 |---|---|
-| Build a workflow with built-in agents (cursor/claude/codex/gemini/assistant) | `@zibby/core` |
+| Build an agent with built-in strategies (cursor/claude/codex/gemini/assistant) | `@zibby/core` |
 | Embed the engine in your own app with custom agents only | `@zibby/agent-workflow` |
 | Use the CLI | `@zibby/cli` (transitively pulls both) |
 

package/docs/packages/mcp-cli.md

@@ -22,17 +22,17 @@ A Model Context Protocol (MCP) server that exposes the Zibby CLI surface — dep
 | `zibby_logout` | Clears the saved session. |
 | `zibby_status` | Who is logged in, how many projects are cached, whether the session is still valid. |
 | `zibby_list_projects` | List the Zibby projects the user has access to. |
-| `zibby_list_templates` | List official workflow templates (browser-test-automation, code-analysis, generate-test-cases, …). |
-| `zibby_scaffold_workflow` | Scaffold `.zibby/workflows/<name>/` from an official template. |
-| `zibby_validate_workflow` | Static-check a local workflow (~30 ms, no API call). |
-| `zibby_list_workflows` | List workflows: local, remote, or both. |
-| `zibby_deploy_workflow` | Deploy a local workflow to a project. |
-| `zibby_trigger_workflow` | Trigger a deployed workflow by UUID. Returns `jobId`. |
-| `zibby_workflow_logs` | Fetch the latest N log lines from a run (one-shot — call again for newer lines). |
-| `zibby_run_workflow_local` | Run a workflow on the user's machine one-shot, for debugging. No cloud. |
-| `zibby_download_workflow` | Pull a deployed workflow back to local. Requires explicit `confirm: true` from the agent. |
-
-**Destructive operations are intentionally not exposed.** Workflow deletion, env-var mutation, schedule changes, and credential management stay in the `zibby` CLI directly. The agent has to involve the user out-of-band for those.
+| `zibby_list_templates` | List official agent templates (browser-test-automation, code-analysis, generate-test-cases, …). |
+| `zibby_scaffold_agent` | Scaffold `.zibby/workflows/<name>/` from an official template. |
+| `zibby_validate_agent` | Static-check a local agent (~30 ms, no API call). |
+| `zibby_list_agents` | List agents: local, remote, or both. |
+| `zibby_deploy_agent` | Deploy a local agent to a project. |
+| `zibby_trigger_agent` | Trigger a deployed agent by UUID. Returns `jobId`. |
+| `zibby_agent_logs` | Fetch the latest N log lines from a run (one-shot — call again for newer lines). |
+| `zibby_run_agent_local` | Run an agent on the user's machine one-shot, for debugging. No cloud. |
+| `zibby_download_agent` | Pull a deployed agent back to local. Requires explicit `confirm: true` from the agent. |
+
+**Destructive operations are intentionally not exposed.** Agent deletion, env-var mutation, schedule changes, and credential management stay in the `zibby` CLI directly. The agent has to involve the user out-of-band for those.
 
 ## Install
 
@@ -128,14 +128,14 @@ If your agent on Windows can't find `npx`, wrap with `cmd /c`:
 ```
 User:  Deploy the browser-test template to my "playhouse" project.
 Agent: → zibby_list_projects
-       → zibby_scaffold_workflow (browser-test-automation → .zibby/workflows/playhouse-tests/)
-       → zibby_validate_workflow
-       → zibby_deploy_workflow
+       → zibby_scaffold_agent (browser-test-automation → .zibby/workflows/playhouse-tests/)
+       → zibby_validate_agent
+       → zibby_deploy_agent
        → "Deployed v1 of playhouse-tests. UUID 988…"
 
 User:  Run it against staging.zibby.dev.
-Agent: → zibby_trigger_workflow (input: { url: "https://staging.zibby.dev" })
-       → zibby_workflow_logs (lines: 200, jobId: "abc-123")
+Agent: → zibby_trigger_agent (input: { url: "https://staging.zibby.dev" })
+       → zibby_agent_logs (lines: 200, jobId: "abc-123")
        → "Run completed. Found 0 errors."
 ```
 
@@ -144,7 +144,7 @@ Agent: → zibby_trigger_workflow (input: { url: "https://staging.zibby.dev" })
 Two-stage by design (mirrors how the `zibby` CLI works):
 
 1. **Session token** (`zibby_login`) — device-code OAuth via browser. Identifies the user.
-2. **Per-project API tokens** — fetched at login time and cached locally. The MCP server picks the right token automatically when you call a project-scoped tool like `zibby_deploy_workflow`.
+2. **Per-project API tokens** — fetched at login time and cached locally. The MCP server picks the right token automatically when you call a project-scoped tool like `zibby_deploy_agent`.
 
 All credentials live in `~/.zibby/config.json` (mode `0600`). The same file `zibby login` writes — so if you've already done `zibby login` from a terminal, the MCP server picks up that session.
 
@@ -156,7 +156,7 @@ The user's password never touches the MCP server: login is OAuth in the browser,
 - **Minimum env passthrough** — only `HOME`, `USER`, `PATH`, and the project-scoped `ZIBBY_API_KEY` reach the child CLI process.
 - **API tokens never returned to the agent** — they live in `~/.zibby/config.json` only, read server-side per call.
 - **Destructive ops excluded** — see the table above.
-- **`zibby_download_workflow` requires `confirm: true`** — the schema rejects calls without it. Agents must explicitly opt in after confirming the destination path with the user.
+- **`zibby_download_agent` requires `confirm: true`** — the schema rejects calls without it. Agents must explicitly opt in after confirming the destination path with the user.
 
 ## Troubleshooting
 

package/docs/packages/skills.md

@@ -17,7 +17,7 @@ npm install @zibby/skills
 
 ## What Are Skills?
 
-A **skill** is a declarative description of an MCP (Model Context Protocol) server and the tools it exposes. Skills are the bridge between your workflow nodes and external capabilities like browser automation, Jira, GitHub, Slack, and test memory.
+A **skill** is a declarative description of an MCP (Model Context Protocol) server and the tools it exposes. Skills are the bridge between your agent nodes and external capabilities like browser automation, Jira, GitHub, Slack, and test memory.
 
 Skills are **agent-agnostic** — the same skill definition works across Cursor, Claude, and Codex. The framework resolves the skill into the right MCP configuration for whichever agent is active.
 
@@ -46,7 +46,7 @@ export const executeLiveNode = {
 };
 ```
 
-When the workflow runs:
+When the agent runs:
 1. The framework reads the node's `skills` array
 2. For each skill, calls `skill.resolve()` to get the MCP server config
 3. Injects the resolved MCP server into the agent's environment

package/docs/packages/ui-memory.md

@@ -51,7 +51,7 @@ zibby memory init
 
 Creates `.zibby/memory/.dolt/` with the schema for runs, selectors, page model, navigation, and insights.
 
-### 3. Enable memory in your workflow
+### 3. Enable memory in your agent
 
 Add `SKILLS.MEMORY` to any node that should have memory access:
 

package/docs/recipes/bug-autofix.md

@@ -78,7 +78,7 @@ Plus the children's own config: Jira connected (triage/poll/writeback), GitHub c
 ## Deploy
 
 ```bash
-zibby agent templates                         # browse the marketplace (zibby workflow templates still works)
+zibby agent templates                         # browse the marketplace
 zibby agent new bug-autofix -t bug-autofix    # scaffold the orchestrator
 # ...also scaffold + deploy ticket-triage, code-fix, tracker-writeback in the same project
 zibby agent deploy bug-autofix

package/docs/recipes/index.md

@@ -5,9 +5,9 @@ title: Agent Marketplace
 
 # Agent Marketplace
 
-Zibby ships a set of **ready-made agents** — production-ready automations you can deploy today. Each one is a real Zibby agent (a workflow graph under the hood), eating its own dog food. Browse them, deploy with one command, and tune them to your project.
+Zibby ships a set of **ready-made agents** — production-ready automations you can deploy today. Each one is a real Zibby agent, eating its own dog food. Browse them, deploy with one command, and tune them to your project.
 
-> **"Agent" is the product noun** for a deployed automation. The CLI / SDK / API still speak "workflow" — the CLI command is `zibby agent` (`zibby workflow` still works as an alias), the package is `@zibby/agent-workflow`.
+> An **Agent** is a deployed automation built on coding-agent CLIs. Build and ship one with the `zibby agent` CLI.
 
 ```
                        ┌──────────────────┐
@@ -53,7 +53,7 @@ Three reasons we ship ready-made agents alongside the platform:
 If you have an agent you'd want shipped as a built-in:
 
 ```bash
-zibby agent new my-agent          # scaffold (zibby workflow new still works)
+zibby agent new my-agent          # scaffold
 # ... build it out ...
 zibby agent run my-agent          # test locally
 zibby agent deploy my-agent       # ship to your cloud account

package/docs/recipes/pipeline-supervisor.md

@@ -11,7 +11,7 @@ v1 is strictly **READ → PROPOSE → NOTIFY**. It never edits another agent's g
 
 ```
 scan_pipelines        (deterministic + Zibby REST API, PAT-authed)
-   → propose_improvements (LLM — one proposal per flagged pipeline)
+   → propose_improvements (LLM — one proposal per flagged agent)
    → notify               (LLM + SKILLS.CHAT_NOTIFY — one review card)
 ```
 
@@ -21,7 +21,7 @@ If `scan_pipelines` flags nothing, the graph short-circuits straight to `notify`
 
 A direct authed `GET /executions?projectId=<id>&limit=200` against the Zibby REST API (the same route the dashboard and remote MCP server use), carrying a **user personal access token** in `Authorization: Bearer`.
 
-It must be a USER PAT (`zby_pat_…`), **not** the Fargate-injected `PROJECT_API_TOKEN`: every cross-pipeline read route requires a `userId` from the authorizer, and a project token carries none — so it 401s.
+It must be a USER PAT (`zby_pat_…`), **not** the Fargate-injected `PROJECT_API_TOKEN`: every cross-agent read route requires a `userId` from the authorizer, and a project token carries none — so it 401s.
 
 ## Config (ENV tab)
 
@@ -40,9 +40,9 @@ Optional:
 | Field | Default | Meaning |
 |---|---|---|
 | `lookbackHours` | 24 | Hours of execution history to scan |
-| `minFailRate` | 0.4 | Flag a pipeline failing ≥ this fraction of recent runs |
+| `minFailRate` | 0.4 | Flag an agent failing ≥ this fraction of recent runs |
 | `targetWorkflowTypes` | — | Optional name filter (case-insensitive substring) |
-| `maxPipelines` | 25 | Cap on distinct pipelines analyzed per run |
+| `maxPipelines` | 25 | Cap on distinct agents analyzed per run |
 
 ## Trigger
 

package/docs/recipes/sentry-triage.md

@@ -5,7 +5,7 @@ title: Sentry triage recipe
 
 # `sentry-triage` — agent-driven Sentry triage
 
-An hourly Sentry triage workflow that fetches unresolved issues, classifies them by severity, and **routes them to the right human**. Three nodes, end-to-end agent-driven, deployed from the marketplace in one click.
+An hourly Sentry triage agent that fetches unresolved issues, classifies them by severity, and **routes them to the right human**. Three nodes, end-to-end agent-driven, deployed from the marketplace in one click.
 
 ```
 fetch_issues  →  classify  →  dispatch_alerts
@@ -27,12 +27,12 @@ The agent uses [`slack_lookup_user_by_email`](../skills/slack), [`slack_list_use
 ## Deploy from the marketplace
 
 ```bash
-zibby workflow templates deploy sentry-triage --project <project-id>
+zibby agent templates deploy sentry-triage --project <project-id>
 ```
 
 Or via the dashboard: `/marketplace/workflows` → Sentry Triage → Deploy.
 
-After deploy, configure ENV (Apps → workflow → ENV tab):
+After deploy, configure ENV (Apps → agent → ENV tab):
 
 | Env var | Required? | Default | What it does |
 |---|---|---|---|
@@ -79,15 +79,15 @@ If you deployed your backend with `RELEASE_SHA` Sentry release-tracking on, susp
 Each node's prompt lives in its own module — fork the template, edit, redeploy:
 
 ```bash
-zibby workflow download <uuid>
+zibby agent download <uuid>
 # edit nodes/dispatch-node.js
-zibby workflow deploy ./sentry-triage   # same UUID, new version
+zibby agent deploy ./sentry-triage   # same UUID, new version
 ```
 
 Or fork the whole template repo if you want long-term divergence — it's just a `@zibby/workflow-templates/sentry-triage/` directory in the published package.
 
 ## Cadence
 
-Default: hourly cron, fires `sinceMinutes=60`. Change in the trigger config (Apps → workflow → Triggers) — keep the SQL safe `since` between 5 and 1440 minutes (`inputSchema` enforces this).
+Default: hourly cron, fires `sinceMinutes=60`. Change in the trigger config (Apps → agent → Triggers) — keep the SQL safe `since` between 5 and 1440 minutes (`inputSchema` enforces this).
 
-→ Next: [`zibby test`](./test) (the browser-testing recipe) or [Build your own workflow](../get-started/your-first-workflow).
+→ Next: [`zibby test`](./test) (the browser-testing recipe) or [Build your own agent](../get-started/your-first-workflow).

package/docs/recipes/test.md

@@ -7,7 +7,7 @@ title: Browser test recipe (zibby test)
 
 The browser-test recipe takes a plain-English spec, drives a real browser via a coding agent (Cursor / Claude / Codex / Gemini), runs the assertions, and produces a Playwright script + verification video.
 
-It's a worked example of what the Zibby platform does — every step is a regular workflow node with Zod-validated handoff. You can read the source, fork it, or build your own variation.
+It's a worked example of what the Zibby platform does — every step is a regular agent node with Zod-validated handoff. You can read the source, fork it, or build your own variation.
 
 ## Quick start
 
@@ -38,7 +38,7 @@ zibby test test-specs/checkout.txt --agent claude
 
 Open the session in [Zibby Studio](https://zibby.app/studio) to scrub through the run, swap the prompt, re-execute any node.
 
-## The graph (this is just a Zibby workflow)
+## The graph (this is just a Zibby agent)
 
 Under the hood, `zibby test` is a 3-node graph:
 
@@ -115,10 +115,10 @@ Auto-pull on test start, auto-push on test pass. Failing runs don't pollute team
 
 ## Forking the recipe
 
-If the built-in recipe doesn't fit your case, scaffold a custom workflow and copy the structure:
+If the built-in recipe doesn't fit your case, scaffold a custom agent and copy the structure:
 
 ```bash
-zibby workflow new my-test-pipeline
+zibby agent new my-test-agent
 ```
 
 Then in `graph.mjs`, define your own nodes:
@@ -170,7 +170,7 @@ That's the platform. The recipe is just a starter.
     npx @zibby/cli test test-specs/checkout.txt --headless
 ```
 
-For workflows triggered remotely (rather than per-CI-run), use [`workflow trigger`](../cloud/triggering) on a deployed graph.
+For agents triggered remotely (rather than per-CI-run), use [`agent trigger`](../cloud/triggering) on a deployed graph.
 
 ## Why this is different from Playwright codegen / a basic LLM script
 
@@ -187,4 +187,4 @@ For workflows triggered remotely (rather than per-CI-run), use [`workflow trigge
 
 - [Recipes overview](./)
 - [Concepts: graph](../concepts/graph) — the primitives this recipe uses
-- [Cloud triggering](../cloud/triggering) — fire workflows from CI/CD
+- [Cloud triggering](../cloud/triggering) — fire agents from CI/CD

package/docs/skills/browser.md

@@ -5,7 +5,7 @@ title: Browser
 
 # Browser skill
 
-Playwright-driven browser automation. Click, type, navigate, snapshot, record video. Used by `zibby test` and by any workflow node that needs to drive a web UI.
+Playwright-driven browser automation. Click, type, navigate, snapshot, record video. Used by `zibby test` and by any agent node that needs to drive a web UI.
 
 - **ID:** `browser`
 - **MCP server:** `playwright` (tools exposed as `mcp__playwright__*`)
@@ -45,7 +45,7 @@ npm install @zibby/mcp-browser
 
 Override the bin path with `MCP_BROWSER_PATH` if you need to point at a local checkout.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/chat-memory.md

@@ -72,7 +72,7 @@ Turn `infer` on when you want mem0 to consolidate noisy inputs into clean facts;
 
 On Zibby Cloud, mem0 state **persists across Fargate tasks**. mem0's SQLite vector + history stores are rooted under the workspace's tenant-scoped `.zibby/memory/` tree, which is tarball-synced between executions — so a memory written in one run is recallable in the next, even though each run is a fresh, ephemeral container. mem0 user IDs are workspace-scoped (`workspace:<name>`, overridable via `ZIBBY_MEMORY_USER_ID`), keeping each project's memory isolated.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/core-tools.md

@@ -27,7 +27,7 @@ Most Claude/Cursor/Codex nodes get these tools by default from their agent strat
 
 None. The skill has no env keys, no auth, no external dependencies.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/function-skill.md

@@ -34,7 +34,7 @@ export const myTool = skill('my_tool', {
 
 Calling `skill()` both creates and **registers** the skill in the global registry, so just importing the module is enough to make it available.
 
-## Use in a workflow
+## Use in an agent
 
 Once registered, reference by id:
 

package/docs/skills/github.md

@@ -37,11 +37,11 @@ Two options:
 
 **GitHub App (recommended).** In **Settings → Integrations**, click **Connect GitHub**, install the Zibby GitHub App on the orgs/repos you want, and authorize. Tokens auto-refresh; you don't manage them. See the [GitHub Integration page](../integrations/github.md) for the full app permissions list.
 
-**Personal access token.** Set `GITHUB_TOKEN` in your workflow's env (locally) or via **Cloud → Env vars** (cloud runs). Scope `repo` for private read+write, `public_repo` for public-only.
+**Personal access token.** Set `GITHUB_TOKEN` in your agent's env (locally) or via **Cloud → Env vars** (cloud runs). Scope `repo` for private read+write, `public_repo` for public-only.
 
 The skill reads `envKeys: ['GITHUB_TOKEN']` and the official `@modelcontextprotocol/server-github` consumes it directly.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/index.md

@@ -20,7 +20,7 @@ Per-skill reference for everything shipped in `@zibby/skills`. For the mental mo
 | [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). Workflows publish a `report` object to Notion blocks (`reportToNotionBlocks`), e.g. the `notify-notion` template | OAuth (dashboard) / `NOTION_API_KEY` (SDK) |
+| 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 |

package/docs/skills/jira.md

@@ -40,7 +40,7 @@ See the [Jira Integration page](../integrations/jira.md) for the user-facing set
 
 Under the hood the bin reads `ATLASSIAN_ACCESS_TOKEN` + `ATLASSIAN_CLOUD_ID` (and optional `ATLASSIAN_INSTANCE_URL`), which the backend supplies through `resolveIntegrationToken('jira')`.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/lark.md

@@ -30,7 +30,7 @@ Lark bots authenticate with App ID + App Secret. The bot needs `im:message` and
 
 For self-hosted Lark deployments, set `host` on the integration config; the default is the standard Feishu host.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/memory.md

@@ -30,7 +30,7 @@ Requires [Dolt](https://docs.dolthub.com/introduction/installation) and an initi
 ```bash
 # macOS
 brew install dolt
-# then, in your workflow workspace:
+# then, in your agent workspace:
 zibby init --mem
 ```
 
@@ -40,7 +40,7 @@ Override the bin location for development with `MCP_MEMORY_PATH`.
 
 See [Tests → Memory](../tests/memory.md) for the full memory lifecycle.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/sentry.md

@@ -29,7 +29,7 @@ Sentry uses OAuth 2.0 with PKCE (public client — no client secret).
 
 The backend (`/integrations/sentry/connect` and `/integrations/sentry/callback`) handles the PKCE exchange. Tokens auto-refresh on use; if refresh fails, click **Reconnect** in the same settings panel.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/docs/skills/slack.md

@@ -31,7 +31,7 @@ Slack uses a bot token + workspace team id.
 1. Create (or reuse) a Slack app at [api.slack.com/apps](https://api.slack.com/apps).
 2. Add Bot Token Scopes: `chat:write`, `channels:read`, `channels:history`, `groups:read`, `users:read`, `reactions:write` (minimum).
 3. Install the app to your workspace; copy the **Bot User OAuth Token** (`xoxb-…`) and **Team ID**.
-4. Set them on the workflow's env (locally) or via **Cloud → Env vars**:
+4. Set them on the agent's env (locally) or via **Cloud → Env vars**:
 
 ```bash
 SLACK_BOT_TOKEN=xoxb-...
@@ -40,7 +40,7 @@ SLACK_TEAM_ID=T01234567
 
 The skill declares `envKeys: ['SLACK_BOT_TOKEN', 'SLACK_TEAM_ID']` and the official `@modelcontextprotocol/server-slack` consumes them.
 
-## Use in a workflow
+## Use in an agent
 
 ```js
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zibby/skills",
-  "version": "0.1.33",
+  "version": "0.1.34",
   "description": "Built-in skill definitions for Zibby test automation framework",
   "type": "module",
   "main": "dist/index.js",
@@ -12,6 +12,8 @@
     "./browser": "./dist/browser.js",
     "./jira": "./dist/jira.js",
     "./github": "./dist/github.js",
+    "./gitlab": "./dist/gitlab.js",
+    "./linear": "./dist/linear.js",
     "./plane": "./dist/plane.js",
     "./slack": "./dist/slack.js",
     "./lark": "./dist/lark.js",