@zibby/skills 0.1.33 → 0.1.34

package/docs/cloud/triggering.md

@@ -5,18 +5,18 @@ title: Triggering programmatically
 
 # Triggering programmatically
 
-The CLI is the public surface for triggering workflows. CI runners, cron hosts, webhook handlers — all of them shell out to the same command:
+The CLI is the public surface for triggering agents. CI runners, cron hosts, webhook handlers — all of them shell out to the same command:
 
 ```bash
-zibby workflow trigger <uuid>
-zibby workflow trigger <uuid> -p ticket=BUG-123
-zibby workflow trigger <uuid> --input '{"ticket":"BUG-123","priority":"high"}'
-zibby workflow trigger <uuid> --input-file payload.json
+zibby agent trigger <uuid>
+zibby agent trigger <uuid> -p ticket=BUG-123
+zibby agent trigger <uuid> --input '{"ticket":"BUG-123","priority":"high"}'
+zibby agent trigger <uuid> --input-file payload.json
 ```
 
 Auth: set `ZIBBY_API_KEY` in the environment, or run `zibby login` once on a workstation. Either works; the CLI picks up whichever is available.
 
-The flag surface is identical to `zibby workflow run` (local) — same `-p / --input / --input-file`, plus `--idempotency-key` for the cloud-only dedup case below. Flip the verb and the same call shape goes from local to remote.
+The flag surface is identical to `zibby agent run` (local) — same `-p / --input / --input-file`, plus `--idempotency-key` for the cloud-only dedup case below. Flip the verb and the same call shape goes from local to remote.
 
 ### Input precedence
 
@@ -29,7 +29,7 @@ When more than one input source is provided, they merge with this **precedence (
 This means the common pattern of "load a base payload from disk, override a few keys for this run" works without manual merging:
 
 ```bash
-zibby workflow trigger <uuid> --input-file payload.json -p priority=urgent
+zibby agent trigger <uuid> --input-file payload.json -p priority=urgent
 ```
 
 ## CI / cron
@@ -39,10 +39,10 @@ Anywhere you can shell out, call the CLI. Don't hand-roll an HTTP client — you
 ### GitHub Actions
 
 ```yaml
-- name: Trigger Zibby workflow
+- name: Trigger Zibby agent
   run: |
     npm i -g @zibby/cli
-    zibby workflow trigger $WORKFLOW_UUID -p sha=$GITHUB_SHA -p pr=$PR_NUMBER
+    zibby agent trigger $WORKFLOW_UUID -p sha=$GITHUB_SHA -p pr=$PR_NUMBER
   env:
     WORKFLOW_UUID: 2b1ea07f-3ede-4bfd-a51d-431f0bab008e
     ZIBBY_API_KEY: ${{ secrets.ZIBBY_API_KEY }}
@@ -61,7 +61,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - run: npm i -g @zibby/cli
-      - run: zibby workflow trigger $UUID --input '{"weekly":true}'
+      - run: zibby agent trigger $UUID --input '{"weekly":true}'
         env:
           UUID: ${{ vars.WORKFLOW_UUID }}
           ZIBBY_API_KEY: ${{ secrets.ZIBBY_API_KEY }}
@@ -79,7 +79,7 @@ app.post('/webhook', (req, res) => {
 
   try {
     execFileSync('zibby', [
-      'workflow', 'trigger', process.env.WORKFLOW_UUID,
+      'agent', 'trigger', process.env.WORKFLOW_UUID,
       '--input', JSON.stringify(req.body),
       '--idempotency-key', req.headers['x-event-id'],
     ], { env: process.env, stdio: 'pipe' });
@@ -97,7 +97,7 @@ If your runtime can't spawn a Node CLI (constrained Lambda layers, edge runtimes
 Pass an idempotency key to deduplicate triggers within a 24-hour window:
 
 ```bash
-zibby workflow trigger <uuid> \
+zibby agent trigger <uuid> \
   -p ticket=BUG-123 \
   --idempotency-key webhook-2026-05-02-event-7
 ```
@@ -109,14 +109,14 @@ Same key + same input within 24h returns the original `jobId` instead of startin
 After triggering, the CLI prints the `jobId`. To watch the execution:
 
 ```bash
-zibby workflow logs <uuid> -t
+zibby agent logs <uuid> -t
 ```
 
-See [`workflow logs` in the CLI Reference](../cli-reference#workflow-logs).
+See [`agent logs` in the CLI Reference](../cli-reference#agent-logs).
 
-## Per-workflow env vars
+## Per-agent env vars
 
-If your workflow needs credentials or config that's specific to it (different `ANTHROPIC_API_KEY` per pipeline, a workflow-only `DATABASE_URL`, etc.), set them via the env-var API — see [Per-workflow env vars](./env-vars). They get injected into the Fargate task at trigger time and override anything set on the project record.
+If your agent needs credentials or config that's specific to it (different `ANTHROPIC_API_KEY` per agent, an agent-only `DATABASE_URL`, etc.), set them via the env-var API — see [Per-agent env vars](./env-vars). They get injected into the Fargate task at trigger time and override anything set on the project record.
 
 ## Quotas
 

package/docs/concepts/agents.md

@@ -92,7 +92,7 @@ Then a node can use it:
 graph.addNode('plan', { prompt, outputSchema: Plan, agent: 'mine' });
 ```
 
-The framework ships **zero** agent strategies bundled — `@zibby/agent-workflow` is BYO. The five built-ins above live in `@zibby/core`, which is what `zibby workflow new` scaffolds and what the cloud runtime preloads.
+The framework ships **zero** agent strategies bundled — `@zibby/agent-workflow` is BYO. The five built-ins above live in `@zibby/core`, which is what `zibby agent new` scaffolds and what the cloud runtime preloads.
 
 ## Authentication
 
@@ -106,7 +106,7 @@ The framework ships **zero** agent strategies bundled — `@zibby/agent-workflow
 
 In Zibby Cloud, you have two options:
 
-- **Project-wide credentials**: set once on the project record (dashboard → Project → Secrets) — every workflow in the project uses them.
-- **Per-workflow overrides**: set on a single workflow via [`PUT /workflows/<uuid>/env`](../cloud/env-vars) — useful when one pipeline needs a different `ANTHROPIC_API_KEY` from the rest of the project, or when one workflow needs to talk to multiple agent vendors with their own keys.
+- **Project-wide credentials**: set once on the project record (dashboard → Project → Secrets) — every agent in the project uses them.
+- **Per-agent overrides**: set on a single agent via [`PUT /workflows/<uuid>/env`](../cloud/env-vars) — useful when one agent needs a different `ANTHROPIC_API_KEY` from the rest of the project, or when one agent needs to talk to multiple agent vendors with their own keys.
 
-Workflow env wins over project secrets on conflict (last-write-wins inside the Fargate task).
+Agent env wins over project secrets on conflict (last-write-wins inside the Fargate task).

package/docs/concepts/sessions.md

@@ -5,7 +5,7 @@ title: Sessions & artifacts
 
 # Sessions & artifacts
 
-Every workflow run — local or cloud — produces a **session folder** under `.zibby/output/sessions/<sessionId>/`. The folder is the canonical record of what happened.
+Every agent run — local or cloud — produces a **session folder** under `.zibby/output/sessions/<sessionId>/`. The folder is the canonical record of what happened.
 
 ## What's inside
 
@@ -31,7 +31,7 @@ Format: `<unix_ms>_<random>`. Generated when the graph starts running.
 You can override via:
 
 ```bash
-zibby workflow run my-pipeline --session 1777678254943_ymcw
+zibby agent run my-agent --session 1777678254943_ymcw
 ```
 
 Useful for replay — re-run from a saved input/state without re-paying earlier nodes.
@@ -39,7 +39,7 @@ Useful for replay — re-run from a saved input/state without re-paying earlier
 ## Replay a session
 
 ```bash
-zibby workflow run my-pipeline \
+zibby agent run my-agent \
   --session 1777678254943_ymcw \
   --node verify   # only re-run the 'verify' node
 ```
@@ -48,19 +48,19 @@ The graph reads `state.plan` and `state.implement` from the saved session and on
 
 ## Cloud sessions
 
-Cloud runs land in the same `.zibby/output/sessions/` layout, just inside the ECS container's `/workspace/`. The session folder is uploaded to S3 at the end of each run; `zibby workflow logs <uuid> -t` streams CloudWatch logs in real time.
+Cloud runs land in the same `.zibby/output/sessions/` layout, just inside the ECS container's `/workspace/`. The session folder is uploaded to S3 at the end of each run; `zibby agent logs <uuid> -t` streams CloudWatch logs in real time.
 
 To download a finished cloud session locally:
 
 ```bash
-zibby workflow download <uuid>
+zibby agent download <uuid>
 ```
 
-This pulls the workflow source (so you can edit and redeploy) plus the most recent execution's session folder.
+This pulls the agent source (so you can edit and redeploy) plus the most recent execution's session folder.
 
 ## Studio integration
 
-[Zibby Studio](https://zibby.app) is a desktop UI that watches `.zibby/output/sessions/`. Anything that writes a session folder shows up in Studio automatically — pin a session, watch state evolve live, or stop a workflow from the Stop button.
+[Zibby Studio](https://zibby.app) is a desktop UI that watches `.zibby/output/sessions/`. Anything that writes a session folder shows up in Studio automatically — pin a session, watch state evolve live, or stop an agent from the Stop button.
 
 The protocol is documented and stable:
 

package/docs/concepts/state.md

@@ -5,7 +5,7 @@ title: State & schema
 
 # State & schema
 
-Every workflow run carries one **state** object that flows from node to node. State is the only handoff mechanism — there's no shared globals, no hidden context.
+Every agent run carries one **state** object that flows from node to node. State is the only handoff mechanism — there's no shared globals, no hidden context.
 
 ## Shape
 

package/docs/concepts/sub-graphs.md

@@ -5,13 +5,13 @@ title: Sub-graphs (parent → child)
 
 # Sub-graphs
 
-A **sub-graph node** runs another deployed workflow as a child of the current one. Use it when a step is large enough to deserve its own workflow definition — its own state schema, its own version, its own activity-tab history — but you want a parent to dispatch it as part of a larger flow.
+A **sub-graph node** runs another deployed agent as a child of the current one. Use it when a step is large enough to deserve its own workflow definition — its own state schema, its own version, its own activity-tab history — but you want a parent to dispatch it as part of a larger flow.
 
 The shape is one extra field on the existing node config:
 
 ```js
 g.addNode('audit', {
-  workflow: 'deep-audit',   // ← name of another workflow in this project
+  workflow: 'deep-audit',   // ← name of another agent in this project
 });
 ```
 
@@ -22,7 +22,7 @@ That's it. No new imports, no UUID, no separate class. The engine recognizes `wo
 | Scenario | Sub-graph? |
 |---|---|
 | Two parents need the same multi-node flow | ✅ Yes — define it once as a child, reference by name |
-| One step needs different state schema than the rest | ✅ Yes — each workflow has its own schema |
+| One step needs different state schema than the rest | ✅ Yes — each agent has its own schema |
 | You want per-step activity-tab history + replay | ✅ Yes — each child run gets its own row |
 | Step is a single LLM call | ❌ No — just add a regular node |
 | Step has its own retry policy | Either works, but a sub-graph gives independent control |
@@ -77,7 +77,7 @@ g.addNode('audit', {
 
 ## How state flows
 
-Each workflow has its own state schema — they're independent. The parent must transform its state into the child's input shape, and (optionally) extract whatever it needs back out.
+Each agent has its own state schema — they're independent. The parent must transform its state into the child's input shape, and (optionally) extract whatever it needs back out.
 
 ### A complete example — `parent-orchestrator` calls `child-doubler`
 
@@ -184,13 +184,13 @@ err.subgraphStatus     // 'failed' | 'canceled' | 'timeout'
 
 ## What's deployed vs what you write
 
-You only ever reference workflows by **name**. The cloud handles the UUID resolution.
+You only ever reference agents by **name**. The cloud handles the UUID resolution.
 
 | Stage | What you write | What the backend does |
 |---|---|---|
-| `zibby workflow deploy child-doubler` | nothing about UUIDs | mints UUID, stores `(projectId, workflowType='child-doubler', uuid='…')` |
+| `zibby agent deploy child-doubler` | nothing about UUIDs | mints UUID, stores `(projectId, workflowType='child-doubler', uuid='…')` |
 | `subgraph('child-doubler')` in parent code | just the name | stored as a string in the parent's graph definition |
-| `zibby workflow deploy parent-orchestrator` | nothing | looks up `'child-doubler'` → UUID, snapshots the dependency |
+| `zibby agent deploy parent-orchestrator` | nothing | looks up `'child-doubler'` → UUID, snapshots the dependency |
 | Parent runs in Fargate → hits sub-graph node | nothing | POSTs to `/workflows/<uuid>/trigger` with `parentExecutionId` |
 
 Names are unique per project (DDB primary key enforces this), so `subgraph('child-doubler')` resolves unambiguously within the parent's project.
@@ -208,14 +208,14 @@ Each child execution row carries `parentExecutionId` pointing at the parent. The
 
 Sub-graph dispatch needs the `PROGRESS_API_URL` env var (the public API base). That's set automatically on Fargate runs. For local dev, you have two options:
 
-1. **Deploy both workflows to cloud, then trigger the parent.** The cloud path always works.
+1. **Deploy both agents to cloud, then trigger the parent.** The cloud path always works.
 2. **Mock the trigger + status endpoints locally.** See [`workflows/parent-orchestrator/mock-server.mjs`](https://github.com/ZibbyHQ/agent-workflow/tree/main/examples) in the agent-workflow repo for a 90-line example that simulates the dispatch + poll loop.
 
 In-process sub-graph execution (running the child in the parent's Node process directly, no HTTP) is **not supported** — we picked consistency between local and cloud over the 10s spawn-time savings.
 
 ## Cross-project sub-graphs
 
-`workflow: 'name'` resolves within the parent's own project. To call another project's workflow, pass an explicit project ID:
+`workflow: 'name'` resolves within the parent's own project. To call another project's agent, pass an explicit project ID:
 
 ```js
 g.addNode('audit', {

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