@zibby/skills 0.1.33 → 0.1.35

package/docs/get-started/deploy.md

@@ -5,34 +5,34 @@ pagination_prev: get-started/run-locally
 pagination_next: get-started/trigger-and-logs
 ---
 
-# Ship a workflow to Zibby Cloud
+# Ship an agent to Zibby Cloud
 
 ```bash
-zibby workflow deploy my-pipeline
+zibby agent deploy my-agent
 ```
 
 If you have multiple projects, the CLI prompts you to pick one. On success it prints a UUID:
 
 ```
-✔ Deployed my-pipeline (v1)
+✔ Deployed my-agent (v1)
 ✔ Bundle ready (78s) — runtime npm install eliminated
 
   UUID:        2b1ea07f-3ede-4bfd-a51d-431f0bab008e
 
   Next steps:
-    zibby workflow run my-pipeline         Run locally
-    zibby workflow trigger 2b1ea07f-...    Run in cloud
-    zibby workflow list                    View all workflows
+    zibby agent run my-agent         Run locally
+    zibby agent trigger 2b1ea07f-...    Run in cloud
+    zibby agent list                    View all agents
 ```
 
-The UUID is **canonical** — it never changes once issued. All cloud commands (`trigger`, `logs`, `download`, `delete`) take that UUID as their identifier. The CLI caches it in `.zibby/workflows/my-pipeline/.zibby-deploy.json` so you don't have to remember it. Commit that file to git; collaborators share the same canonical reference.
+The UUID is **canonical** — it never changes once issued. All cloud commands (`trigger`, `logs`, `download`, `delete`) take that UUID as their identifier. The CLI caches it in `.zibby/workflows/my-agent/.zibby-deploy.json` so you don't have to remember it. Commit that file to git; collaborators share the same canonical reference.
 
 ## What deploy actually does
 
 Two phases:
 
-1. **Source upload** — your workflow folder (sources only, no `node_modules`) is uploaded as a JSON payload to S3 via a presigned URL. The CLI also resolves your `.zibby.config.mjs` (if present at project root) and ships it inside the bundle as `zibby.config.json`, so the cloud sees the same config as your local runs.
-2. **Bundle build (Heroku-style)** — a CodeBuild job downloads the sources, runs `npm install --omit=dev`, packages the result as a tarball, and uploads it to S3. The tarball is what each cloud execution downloads at trigger time, so there's **no `npm install` at runtime** — workflows boot in seconds.
+1. **Source upload** — your agent folder (sources only, no `node_modules`) is uploaded as a JSON payload to S3 via a presigned URL. The CLI also resolves your `.zibby.config.mjs` (if present at project root) and ships it inside the bundle as `zibby.config.json`, so the cloud sees the same config as your local runs.
+2. **Bundle build (Heroku-style)** — a CodeBuild job downloads the sources, runs `npm install --omit=dev`, packages the result as a tarball, and uploads it to S3. The tarball is what each cloud execution downloads at trigger time, so there's **no `npm install` at runtime** — agents boot in seconds.
 
 You'll see a live spinner with the active build step:
 
@@ -44,7 +44,7 @@ Pass `--verbose` if you want to see raw CodeBuild logs.
 
 ## Re-deploys keep the same UUID
 
-Once a workflow has a UUID, every subsequent `deploy` increments the version but keeps the UUID stable:
+Once an agent has a UUID, every subsequent `deploy` increments the version but keeps the UUID stable:
 
 ```
 v1 → v2 → v3 → ...    (same UUID, same trigger URL)
@@ -56,20 +56,20 @@ So your `curl` calls and CI integrations don't break across deploys.
 
 A clean mental model:
 
-- **Workflow folder name** (`my-pipeline`) is *local* — used by `workflow new`, `start`, `deploy`. It's just a directory name.
+- **Agent folder name** (`my-agent`) is *local* — used by `agent new`, `start`, `deploy`. It's just a directory name.
 - **UUID** (`2b1ea07f-...`) is *canonical* — used by `trigger`, `logs`, `download`, `delete`. Stable across deploys.
 
-`workflow list` shows both:
+`agent list` shows both:
 
 ```
 ┌─────────────────────────────────────┬──────────────┬──────────┬─────┐
 │ UUID                                │ Name         │ Project  │ Ver │
 ├─────────────────────────────────────┼──────────────┼──────────┼─────┤
-│ 2b1ea07f-3ede-4bfd-a51d-431f0bab008e│ my-pipeline  │ Zibby UI │ 3   │
+│ 2b1ea07f-3ede-4bfd-a51d-431f0bab008e│ my-agent  │ Zibby UI │ 3   │
 │ -                                   │ scratchpad   │ -        │ -   │
 └─────────────────────────────────────┴──────────────┴──────────┴─────┘
 ```
 
-`-` in the UUID column means a local-only workflow that hasn't been deployed yet.
+`-` in the UUID column means a local-only agent that hasn't been deployed yet.
 
 → Next: [Trigger & tail logs](./trigger-and-logs)

package/docs/get-started/install.md

@@ -7,7 +7,7 @@ pagination_next: get-started/your-first-workflow
 
 # Install the CLI
 
-You build **Agents** with Zibby — deployed automations, each a workflow graph under the hood. The CLI command is `zibby agent` (`zibby workflow` still works as an alias, and is used throughout these walkthroughs).
+You build **Agents** with Zibby — deployed automations. The CLI command is `zibby agent`.
 
 ```bash
 npm install -g @zibby/cli
@@ -26,7 +26,7 @@ You should see something like `zibby v0.4.x`.
 Every example below works with `npx @zibby/cli` instead of `zibby`:
 
 ```bash
-npx @zibby/cli workflow new my-pipeline
+npx @zibby/cli agent new my-agent
 ```
 
 The first call downloads the package; subsequent calls use the cached copy.
@@ -45,7 +45,7 @@ For CI/CD, set `ZIBBY_API_KEY` in the environment instead — the CLI prefers th
 
 ## Pick an agent runtime
 
-Workflows hand off to external coding-agent CLIs at runtime. You'll need at least one of these installed (locally — the cloud runtime has them pre-installed):
+Agents hand off to external coding-agent CLIs at runtime. You'll need at least one of these installed (locally — the cloud runtime has them pre-installed):
 
 | Agent | How to install | Auth |
 |---|---|---|
@@ -57,4 +57,4 @@ Workflows hand off to external coding-agent CLIs at runtime. You'll need at leas
 
 You only need one. The cloud runtime supports all five out of the box.
 
-→ Next: [Your first workflow](./your-first-workflow)
+→ Next: [Your first agent](./your-first-workflow)

package/docs/get-started/run-locally.md

@@ -5,10 +5,10 @@ pagination_prev: get-started/your-first-workflow
 pagination_next: get-started/deploy
 ---
 
-# Run a workflow locally
+# Run an agent locally
 
 ```bash
-zibby workflow run my-pipeline
+zibby agent run my-agent
 ```
 
 One-shot: loads `graph.mjs`, instantiates your `WorkflowAgent` class, runs the graph against a real agent, prints results, exits. Output lands in `.zibby/output/sessions/<sessionId>/`:
@@ -18,11 +18,11 @@ One-shot: loads `graph.mjs`, instantiates your `WorkflowAgent` class, runs the g
 - `events.json` — JSONL execution log: which node ran when, what it received, what it returned, retries
 - `.session-info.json` — session metadata
 
-The flag surface mirrors `zibby workflow trigger` (cloud) on purpose: the call you make locally is the same call you make against the cloud, just with the verb flipped.
+The flag surface mirrors `zibby agent trigger` (cloud) on purpose: the call you make locally is the same call you make against the cloud, just with the verb flipped.
 
 ## Pass input
 
-Most workflows take input. Edit `graph.mjs` to define an input schema and reference `state.input`:
+Most agents take input. Edit `graph.mjs` to define an input schema and reference `state.input`:
 
 ```js
 graph.addNode('plan', {
@@ -35,14 +35,14 @@ graph.addNode('plan', {
 Then pass input via `--input`:
 
 ```bash
-zibby workflow run my-pipeline --input '{"ticket":"BUG-123"}'
+zibby agent run my-agent --input '{"ticket":"BUG-123"}'
 ```
 
 Or `--param key=value` (repeatable, dot-notation supported):
 
 ```bash
-zibby workflow run my-pipeline -p ticket=BUG-123 -p priority=high
-zibby workflow run my-pipeline -p user.name=Alice -p user.role=admin
+zibby agent run my-agent -p ticket=BUG-123 -p priority=high
+zibby agent run my-agent -p user.name=Alice -p user.role=admin
 ```
 
 Or `--input-file payload.json` for larger payloads.
@@ -56,15 +56,15 @@ Each run is a fresh process — re-edit `graph.mjs` or any node file and re-run.
 If you want auto-rerun on file change, run it under `nodemon`:
 
 ```bash
-npx nodemon --ext mjs,js --exec "zibby workflow run my-pipeline -p ticket=BUG-123"
+npx nodemon --ext mjs,js --exec "zibby agent run my-agent -p ticket=BUG-123"
 ```
 
-Or add it to your workflow's `package.json`:
+Or add it to your agent's `package.json`:
 
 ```json
 {
   "scripts": {
-    "dev": "nodemon --ext mjs,js --exec \"zibby workflow run my-pipeline\""
+    "dev": "nodemon --ext mjs,js --exec \"zibby agent run my-agent\""
   }
 }
 ```
@@ -85,10 +85,10 @@ cat .zibby/output/sessions/<sessionId>/result.json | jq
 Studio is a desktop UI for browsing live + past runs. It connects to a local HTTP server, so when you use Studio you start that instead:
 
 ```bash
-zibby workflow start my-pipeline   # long-lived server on :3848 (Studio talks to this)
+zibby agent start my-agent   # long-lived server on :3848 (Studio talks to this)
 zibby studio                       # launch the desktop app
 ```
 
-For CLI-only iteration, stick with `zibby workflow run`.
+For CLI-only iteration, stick with `zibby agent run`.
 
 → Next: [Deploy to cloud](./deploy)

package/docs/get-started/trigger-and-logs.md

@@ -4,12 +4,12 @@ title: 5. Trigger & tail logs
 pagination_prev: get-started/deploy
 ---
 
-# Run a deployed workflow and watch logs
+# Run a deployed agent and watch logs
 
 ## Trigger
 
 ```bash
-zibby workflow trigger 2b1ea07f-3ede-4bfd-a51d-431f0bab008e
+zibby agent trigger 2b1ea07f-3ede-4bfd-a51d-431f0bab008e
 ```
 
 The CLI returns immediately with a job ID:
@@ -24,24 +24,24 @@ The CLI returns immediately with a job ID:
     Triggered: 02/05/2026, 10:23:13
 
   Monitor execution:
-    zibby workflow logs 2b1ea07f-... 
-    zibby workflow logs 2b1ea07f-... -t
+    zibby agent logs 2b1ea07f-... 
+    zibby agent logs 2b1ea07f-... -t
 ```
 
 Pass input the same way as locally:
 
 ```bash
-zibby workflow trigger <uuid> -p ticket=BUG-123
-zibby workflow trigger <uuid> --input '{"ticket":"BUG-123"}'
-zibby workflow trigger <uuid> --input-file ./input.json
+zibby agent trigger <uuid> -p ticket=BUG-123
+zibby agent trigger <uuid> --input '{"ticket":"BUG-123"}'
+zibby agent trigger <uuid> --input-file ./input.json
 ```
 
-If you omit the UUID, the CLI shows an interactive picker over your deployed workflows.
+If you omit the UUID, the CLI shows an interactive picker over your deployed agents.
 
 ## Tail logs (Heroku-style)
 
 ```bash
-zibby workflow logs 2b1ea07f-3ede-4bfd-a51d-431f0bab008e -t
+zibby agent logs 2b1ea07f-3ede-4bfd-a51d-431f0bab008e -t
 ```
 
 `-t` follows live. Without `-t` it dumps the last execution and exits.
@@ -52,7 +52,7 @@ zibby workflow logs 2b1ea07f-3ede-4bfd-a51d-431f0bab008e -t
 
 2026-05-02 23:30:51.345  zibby v0.4.x
 ────────────────────────────────────────────────────────────
- Workflow:  my-pipeline
+ Workflow:  my-agent
  Job:       ee333411-...
  Project:   6b60049d-...
  Agent:     cursor (model: auto)
@@ -65,24 +65,24 @@ zibby workflow logs 2b1ea07f-3ede-4bfd-a51d-431f0bab008e -t
 │ ◆ Model: auto | key: ***bc97
 │ ...
 └ done 19.4s
-[done] my-pipeline completed in 19.4s
+[done] my-agent completed in 19.4s
 ```
 
 The stream covers the full execution end-to-end — agent reasoning, tool calls, schema validation, completion summary.
 
 ## Multiple executions
 
-Workflow UUIDs follow the workflow, not a single run. After one execution finishes, `logs -t` waits for the next trigger of the same workflow and auto-switches to streaming it. Like `heroku logs --tail`.
+Agent UUIDs follow the agent, not a single run. After one execution finishes, `logs -t` waits for the next trigger of the same agent and auto-switches to streaming it. Like `heroku logs --tail`.
 
 To exit after the current run, just Ctrl+C — there's no "exit on completion" mode (yet).
 
 ## Triggering from anywhere
 
-The CLI is the easiest way, but workflows expose an HTTP API for programmatic triggering — see [Cloud → Triggering programmatically](../cloud/triggering).
+The CLI is the easiest way, but agents expose an HTTP API for programmatic triggering — see [Cloud → Triggering programmatically](../cloud/triggering).
 
 ## You're done
 
-You've now scaffolded, run locally, deployed, triggered, and tailed a workflow. The rest of the docs go deeper:
+You've now scaffolded, run locally, deployed, triggered, and tailed an agent. The rest of the docs go deeper:
 
 - [Concepts](../concepts/graph) — how the graph engine works
 - [CLI Reference](../cli-reference) — every command

package/docs/get-started/use-from-agents.md

@@ -6,13 +6,13 @@ pagination_prev: get-started/trigger-and-logs
 
 # Use Zibby from Claude Code, Cursor, Codex, or Gemini
 
-Zibby ships an MCP (Model Context Protocol) server — [`@zibby/mcp-cli`](../packages/mcp-cli). Add it once to your agent's config and Zibby becomes a first-class tool the agent can call directly from chat. Deploy workflows, trigger runs, tail logs — all without leaving your editor.
+Zibby ships an MCP (Model Context Protocol) server — [`@zibby/mcp-cli`](../packages/mcp-cli). Add it once to your agent's config and Zibby becomes a first-class tool the agent can call directly from chat. Deploy agents, trigger runs, tail logs — all without leaving your editor.
 
 ```
 You:    Deploy the browser-test template to my Playhouse project, then run it.
-Agent:  → zibby_scaffold_workflow
-        → zibby_deploy_workflow
-        → zibby_trigger_workflow
+Agent:  → zibby_scaffold_agent
+        → zibby_deploy_agent
+        → zibby_trigger_agent
         → "Done. Job a23e… completed in 47s, 0 failures."
 ```
 
@@ -109,14 +109,14 @@ Login state lives in `~/.zibby/config.json` (mode `0600`) — the same file the
 
 | Read-only | Write |
 |---|---|
-| List projects | Scaffold a workflow from an official template |
-| List official templates | Deploy a workflow to a project |
-| List workflows (local + remote) | Trigger a deployed workflow |
-| Show login status | Run a workflow locally (debug) |
-| Fetch logs from a run | Download a deployed workflow (with explicit user confirmation) |
-| Static-validate a workflow | |
+| List projects | Scaffold an agent from an official template |
+| List official templates | Deploy an agent to a project |
+| List agents (local + remote) | Trigger a deployed agent |
+| Show login status | Run an agent locally (debug) |
+| Fetch logs from a run | Download a deployed agent (with explicit user confirmation) |
+| Static-validate an agent | |
 
-**Destructive operations stay out of the agent's hands** — workflow delete, env-var changes, schedule mutation, and credential management require you to run `zibby` in a terminal. Two-stage authorization for anything that could surprise you.
+**Destructive operations stay out of the agent's hands** — agent delete, env-var changes, schedule mutation, and credential management require you to run `zibby` in a terminal. Two-stage authorization for anything that could surprise you.
 
 See the [`@zibby/mcp-cli` package reference](../packages/mcp-cli) for the full tool list and security model.
 
@@ -131,22 +131,22 @@ Agent:  → zibby_list_templates
          - code-analysis: Jira ticket → analyze → generate code → emit tests
          - generate-test-cases: code diff → prioritized AI-runnable test specs"
 
-You:    Scaffold generate-test-cases into a new workflow called "release-tests" in my Playhouse project.
+You:    Scaffold generate-test-cases into a new agent called "release-tests" in my Playhouse project.
 
 Agent:  → zibby_list_projects                       (resolves "Playhouse" → projectId)
-        → zibby_scaffold_workflow name=release-tests template=generate-test-cases
-        → zibby_validate_workflow name=release-tests
+        → zibby_scaffold_agent name=release-tests template=generate-test-cases
+        → zibby_validate_agent name=release-tests
         "Scaffolded and validated. Ready to deploy."
 
 You:    Deploy it.
 
-Agent:  → zibby_deploy_workflow name=release-tests projectId=…
+Agent:  → zibby_deploy_agent name=release-tests projectId=…
         "Deployed v1 — UUID 33039db5-2f32-4094-9841-317bc56a88c9."
 
 You:    Run it against this PR diff: ‹pastes diff›
 
-Agent:  → zibby_trigger_workflow uuid=33039db5… input={diff: "...", changedFiles: [...]}
-        → zibby_workflow_logs jobId=c62e97a4… lines=100
+Agent:  → zibby_trigger_agent uuid=33039db5… input={diff: "...", changedFiles: [...]}
+        → zibby_agent_logs jobId=c62e97a4… lines=100
         "Run completed in 1m 23s. Generated 7 test specs (4 Critical, 2 High, 1 Medium)."
 ```
 

package/docs/get-started/your-first-workflow.md

@@ -1,33 +1,33 @@
 ---
 sidebar_position: 2
-title: 2. Your first workflow
+title: 2. Your first agent
 pagination_prev: get-started/install
 pagination_next: get-started/run-locally
 ---
 
 # Scaffold your first agent
 
-An **Agent** is a deployed automation — a workflow graph of agent-CLI calls. Scaffold one with the CLI (the command is `zibby agent`; `zibby workflow` is a still-working alias):
+An **Agent** is a deployed automation. Scaffold one with the CLI with the `zibby agent` CLI:
 
 ```bash
-zibby agent new my-pipeline
-# zibby workflow new my-pipeline   # alias — identical
+zibby agent new my-agent
+# zibby agent new my-agent   # alias — identical
 ```
 
 This creates:
 
 ```
-.zibby/workflows/my-pipeline/
+.zibby/workflows/my-agent/
 ├── graph.mjs         # the workflow definition (entry point)
 ├── nodes/
 │   └── example.mjs   # a sample node
-├── package.json      # workflow's own deps (each workflow is a self-contained npm project)
+├── package.json      # agent's own deps (each agent is a self-contained npm project)
 └── workflow.json     # manifest (workflow name, entry class)
 ```
 
 If `.zibby/workflows/` doesn't exist yet, the scaffold creates it. If you have a `.zibby.config.mjs` with a custom `paths.workflows`, the scaffold respects it.
 
-The first time you run this in a fresh directory, you'll be asked where to keep workflows (default: `.zibby/workflows`). The CLI also runs `npm install` inside the new workflow folder so deps are ready.
+The first time you run this in a fresh directory, you'll be asked where to keep agents (default: `.zibby/workflows`). The CLI also runs `npm install` inside the new agent folder so deps are ready.
 
 ## What's in graph.mjs
 
@@ -64,6 +64,6 @@ The shape is:
 
 ## Picking the agent
 
-Each node can specify its own agent via `agent: 'cursor' | 'claude' | 'codex' | 'gemini' | 'assistant'`. If you omit it, the workflow falls back to the project default (set in `.zibby.config.mjs` or `AGENT_TYPE` env var).
+Each node can specify its own agent via `agent: 'cursor' | 'claude' | 'codex' | 'gemini' | 'assistant'`. If you omit it, the agent falls back to the project default (set in `.zibby.config.mjs` or `AGENT_TYPE` env var).
 
 → Next: [Run it locally](./run-locally)

package/docs/integrations/gitlab.md

@@ -30,7 +30,7 @@ Nodes that attach the [`gitlab` skill](../skills/index.md) get tools for repos,
 
 ## Reference keys (SDK / CLI)
 
-When running workflows directly, the connector reads `GITLAB_TOKEN` (and a base URL for self-hosted instances) from the environment.
+When running agents directly, the connector reads `GITLAB_TOKEN` (and a base URL for self-hosted instances) from the environment.
 
 ## Firewalled instances
 

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) |