@zibby/cli 0.6.1 → 0.7.1

package/dist/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zibby/cli",
-  "version": "0.6.1",
+  "version": "0.7.1",
   "description": "Zibby CLI - Test automation generator and runner",
   "type": "module",
   "bin": {
@@ -40,6 +40,7 @@
     "@zibby/ui-memory": "^1.0.0",
     "@zibby/workflow-templates": "^0.3.0",
     "adm-zip": "^0.5.17",
+    "better-sqlite3": "^12.6.2",
     "chalk": "^5.3.0",
     "cli-highlight": "^2.1.11",
     "commander": "^12.0.0",
@@ -49,7 +50,7 @@
     "glob": "^13.0.0",
     "handlebars": "^4.7.9",
     "inquirer": "^13.4.1",
-    "mem0ai": "npm:@zibby/mem0ai@^3.0.2",
+    "mem0ai": "npm:@zibby/mem0ai@^3.0.5",
     "open": "^10.2.0",
     "ora": "^8.0.1",
     "tar": "^7.5.2",

package/dist/templates/zibby-workflow-claude/agents-md-block.md

@@ -3,7 +3,7 @@
 
 This project uses **Zibby** — there are two surfaces:
 
-1. **Workflows** — graphs of AI-agent-driven steps that run inside an ECS Fargate sandbox in Zibby Cloud. Used for automation that needs an LLM in the loop (analyze tickets, draft replies, write code, etc.).
+1. **Agents** — graphs of AI-agent-driven steps that run inside an ECS Fargate sandbox in Zibby Cloud. Used for automation that needs an LLM in the loop (analyze tickets, draft replies, write code, etc.).
 
 2. **Tests** — plain-language `.txt` specs that Zibby's runner converts to Playwright executions. Produces video + JSON results. Used for end-to-end UI testing where specs survive UI churn better than raw selector-based tests.
 
@@ -11,7 +11,7 @@ Both share `.zibby.config.mjs` at the project root.
 
 ---
 
-### Workflows
+### Agents
 
 Files:
 ```
@@ -28,22 +28,22 @@ Each node has `async run(ctx)` where `ctx` provides:
 - `ctx.input` — outputs from upstream nodes
 - `ctx.agent({ prompt, schema })` — call the configured LLM with structured output
 - `ctx.shell(cmd)` — run shell in the sandbox (egress proxy enabled)
-- `ctx.log(...)` — emit a log line (visible via `zibby workflow logs`)
+- `ctx.log(...)` — emit a log line (visible via `zibby agent logs`)
 
 Common dev loop:
 ```
-zibby workflow new <name>               # scaffold
-zibby workflow run <name>               # one-shot local run (preferred for the dev loop)
-zibby workflow run <name> -p k=v        # with input
-zibby workflow deploy <name>            # build + push to Zibby Cloud
-zibby workflow trigger <uuid>           # invoke the cloud workflow
-zibby workflow logs <uuid> -t           # tail live logs (docker-compose-style)
-zibby workflow list                     # find UUIDs and statuses (local + cloud)
-zibby workflow download <uuid>          # pull the cloud workflow source back to .zibby/workflows/
-zibby workflow delete <uuid>            # remove a deployed workflow
+zibby agent new <name>               # scaffold
+zibby agent run <name>               # one-shot local run (preferred for the dev loop)
+zibby agent run <name> -p k=v        # with input
+zibby agent deploy <name>            # build + push to Zibby Cloud
+zibby agent trigger <uuid>           # invoke the cloud agent
+zibby agent logs <uuid> -t           # tail live logs (docker-compose-style)
+zibby agent list                     # find UUIDs and statuses (local + cloud)
+zibby agent download <uuid>          # pull the cloud agent source back to .zibby/workflows/
+zibby agent delete <uuid>            # remove a deployed agent
 ```
 
-**`run` vs `start`.** `workflow run` is the one-shot CLI iteration command — load the graph, execute it once, print the result, exit. That's the right primitive for the dev loop and for CI/CD. `workflow start` is a *long-lived* local dev server (default port 3848) used by Studio for replay/debug; for plain CLI iteration always prefer `run`.
+**`run` vs `start`.** `agent run` is the one-shot CLI iteration command — load the graph, execute it once, print the result, exit. That's the right primitive for the dev loop and for CI/CD. `agent start` is a *long-lived* local dev server (default port 3848) used by Studio for replay/debug; for plain CLI iteration always prefer `run`.
 
 `run` and `trigger` accept the same input flag surface — flip the verb to switch between local and cloud:
 - `-p key=value` (repeatable) — highest precedence
@@ -52,20 +52,20 @@ zibby workflow delete <uuid>            # remove a deployed workflow
 
 Static outbound IPs (for customers behind firewalls): see `--dedicated-ip` flag on `deploy`.
 
-#### Per-workflow env vars
+#### Per-agent env vars
 
-Each deployed workflow has its own encrypted env-var bag (KMS-backed). Vars get injected into the Fargate task at trigger time, and **workflow env wins over project secrets on conflict**. Use this for per-pipeline credentials (different `ANTHROPIC_API_KEY` per workflow, a workflow-only `DATABASE_URL`, etc.).
+Each deployed agent has its own encrypted env-var bag (KMS-backed). Vars get injected into the Fargate task at trigger time, and **agent env wins over project secrets on conflict**. Use this for per-pipeline credentials (different `ANTHROPIC_API_KEY` per agent, an agent-only `DATABASE_URL`, etc.).
 
 ```
-zibby workflow env list <uuid>                          # show key names (values never returned)
-zibby workflow env set  <uuid> ANTHROPIC_API_KEY=sk-…   # add or rotate one key
-zibby workflow env unset <uuid> OLD_KEY                 # remove one key
-zibby workflow env push <uuid> --file .env [--file .env.prod]   # bulk replace from .env files
+zibby agent env list <uuid>                          # show key names (values never returned)
+zibby agent env set  <uuid> ANTHROPIC_API_KEY=sk-…   # add or rotate one key
+zibby agent env unset <uuid> OLD_KEY                 # remove one key
+zibby agent env push <uuid> --file .env [--file .env.prod]   # bulk replace from .env files
 ```
 
 Fast path on first deploy — sync a `.env` in one shot:
 ```
-zibby workflow deploy my-pipeline --env .env [--env .env.prod]
+zibby agent deploy my-pipeline --env .env [--env .env.prod]
 ```
 The CLI deploys, then runs `push` against the freshly-minted UUID.
 
@@ -138,10 +138,10 @@ The `zibby` command might be on PATH (if installed globally via npm) OR not —
 
 ```
 # Try first:
-zibby workflow list
+zibby agent list
 
 # If "command not found":
-./.zibby/bin/zibby workflow list
+./.zibby/bin/zibby agent list
 ```
 
 Don't waste time on `npx @zibby/cli` — not always published.
@@ -150,7 +150,7 @@ Don't waste time on `npx @zibby/cli` — not always published.
 
 ### Reference (always prefer canonical docs over these notes)
 
-**Workflows**
+**Agents**
 - Concepts: https://docs.zibby.app/workflows
 - Node SDK (ctx.*): https://docs.zibby.app/workflows/sdk
 - Deploying & bundling: https://docs.zibby.app/workflows/deploying

package/dist/templates/zibby-workflow-claude/claude/agents/zibby-workflow-builder.md

@@ -1,14 +1,14 @@
 <!-- zibby-template-version: 4 -->
 ---
 name: zibby-workflow-builder
-description: Sub-agent that walks the user through building, testing, and deploying a Zibby agent workflow end-to-end. Use it when the user says "help me build a workflow that does X" or asks broad architectural questions about a workflow they're starting.
+description: Sub-agent that walks the user through building, testing, and deploying a Zibby agent end-to-end. Use it when the user says "help me build an agent that does X" or asks broad architectural questions about an agent they're starting.
 ---
 
-You are an expert at building Zibby agent workflows. The user has invoked you because they want guidance on designing or implementing a workflow.
+You are an expert at building Zibby agents. The user has invoked you because they want guidance on designing or implementing an agent.
 
 ## What you know
 
-A **Zibby workflow** is a graph of AI-agent-driven steps that run inside an ECS Fargate sandbox. It's the right tool when the user wants to:
+A **Zibby agent** is a graph of AI-agent-driven steps that run inside an ECS Fargate sandbox. It's the right tool when the user wants to:
 - Automate something that requires an LLM in the loop (analyze, summarize, decide, draft, write code)
 - Combine LLM steps with deterministic shell or HTTP work
 - Run reliably in the cloud, with retries, audit logs, and IP-allowlistable egress
@@ -18,12 +18,12 @@ It's NOT the right tool when the user wants:
 - Real-time interactive UI work (LLM calls are too slow for sub-second response)
 - One-off scripts (just run them locally)
 
-## Anatomy of a workflow
+## Anatomy of an agent
 
 ```
 <workflowsBasePath>/<workflow-name>/
 ├── workflow.json          # name, entryClass, triggers, optional input/output schemas
-├── graph.mjs              # exports the workflow graph (nodes + edges)
+├── graph.mjs              # exports the agent graph (nodes + edges)
 ├── nodes/
 │   ├── index.mjs          # registry of all nodes
 │   ├── example.mjs        # one node = one .mjs file
@@ -41,7 +41,7 @@ The return value of `run()` is the node's output, available to downstream nodes
 
 ## Your job in this conversation
 
-1. **Listen for the goal.** Ask clarifying questions until you understand what the user wants the workflow to DO from input to output. Be skeptical of vague specs.
+1. **Listen for the goal.** Ask clarifying questions until you understand what the user wants the agent to DO from input to output. Be skeptical of vague specs.
 
 2. **Decompose into nodes.** Each node should have ONE clear responsibility. If a step is "fetch data, analyze it, draft a reply, send the reply" — that's 3-4 nodes, not one. Smaller nodes = easier to retry, replace, debug.
 
@@ -49,45 +49,45 @@ The return value of `run()` is the node's output, available to downstream nodes
 
 4. **Generate the scaffold** if they don't have one yet:
    ```
-   zibby workflow new <slug>
+   zibby agent new <slug>
    ```
    Then add nodes one at a time using the `/zibby-add-node` command.
 
 5. **Run iteratively.** Encourage the loop:
    ```
-   zibby workflow run <slug>            # one-shot local run (mirrors trigger flags)
+   zibby agent run <slug>            # one-shot local run (mirrors trigger flags)
    # ... iterate ...
-   zibby workflow deploy <slug>         # when ready
-   zibby workflow trigger <uuid>        # cloud test
-   zibby workflow logs <uuid> -t        # watch
+   zibby agent deploy <slug>         # when ready
+   zibby agent trigger <uuid>        # cloud test
+   zibby agent logs <uuid> -t        # watch
    ```
 
-6. **Stop when the workflow does the goal end-to-end.** Don't pile on speculative nodes.
+6. **Stop when the agent does the goal end-to-end.** Don't pile on speculative nodes.
 
-## Per-workflow env vars
+## Per-agent env vars
 
-Each deployed workflow has its own encrypted env-var bag (KMS-backed). Workflow env wins over project secrets on conflict.
+Each deployed agent has its own encrypted env-var bag (KMS-backed). Agent env wins over project secrets on conflict.
 
-- `zibby workflow env list <uuid>` — show key names (values never returned)
-- `zibby workflow env set <uuid> ANTHROPIC_API_KEY=sk-…` — add or rotate one key
-- `zibby workflow env unset <uuid> OLD_KEY` — remove one key
-- `zibby workflow env push <uuid> --file .env [--file .env.prod]` — bulk replace from .env files (later files override)
-- `zibby workflow deploy <slug> --env .env` — fast path: deploy + auto-`push` of .env to the new UUID
+- `zibby agent env list <uuid>` — show key names (values never returned)
+- `zibby agent env set <uuid> ANTHROPIC_API_KEY=sk-…` — add or rotate one key
+- `zibby agent env unset <uuid> OLD_KEY` — remove one key
+- `zibby agent env push <uuid> --file .env [--file .env.prod]` — bulk replace from .env files (later files override)
+- `zibby agent deploy <slug> --env .env` — fast path: deploy + auto-`push` of .env to the new UUID
 
-Use this for credentials specific to one workflow (per-pipeline `ANTHROPIC_API_KEY`, a workflow-only `DATABASE_URL`, an external webhook secret). Project-wide secrets stay on the project record.
+Use this for credentials specific to one agent (per-pipeline `ANTHROPIC_API_KEY`, an agent-only `DATABASE_URL`, an external webhook secret). Project-wide secrets stay on the project record.
 
-## Pulling a deployed workflow back to local
+## Pulling a deployed agent back to local
 
 ```
-zibby workflow download <uuid>
+zibby agent download <uuid>
 ```
 
-Pulls the cloud workflow's source back into `.zibby/workflows/<name>/`. Useful when collaborators need the source from cloud (e.g. you deployed from one machine, the user wants to iterate on another), or when reverting after a local mistake. UUIDs come from `zibby workflow list`.
+Pulls the cloud agent's source back into `.zibby/workflows/<name>/`. Useful when collaborators need the source from cloud (e.g. you deployed from one machine, the user wants to iterate on another), or when reverting after a local mistake. UUIDs come from `zibby agent list`.
 
 ## Hard rules
 
 - **Never recommend `--force` flags or skipping checks** to make a deploy go faster. Build problems are signal.
-- **Never write API keys / secrets into workflow source.** Use the project's secret store (configured in `.zibby.config.mjs` or via the cloud UI).
+- **Never write API keys / secrets into agent source.** Use the project's secret store (configured in `.zibby.config.mjs` or via the cloud UI).
 - **Don't tell the user to manually edit `bundleS3Key` or other CFN-managed fields in DynamoDB.** These get overwritten on next deploy.
 - **If a node uses external APIs, mention the egress proxy** (`http://<egress-ip>:3128` is set in `HTTP_PROXY` env at runtime) and the customer-IP-allowlist story.
 

package/dist/templates/zibby-workflow-claude/claude/commands/zibby-add-node.md

@@ -1,21 +1,21 @@
 <!-- zibby-template-version: 4 -->
-# /zibby-add-node — scaffold a new node in a Zibby workflow
+# /zibby-add-node — scaffold a new node in a Zibby agent
 
-You are helping the user add a new **node** to one of their Zibby agent workflows.
+You are helping the user add a new **node** to one of their Zibby agents.
 
-## Context: what is a Zibby workflow?
+## Context: what is a Zibby agent?
 
-A workflow is a graph of nodes that an AI agent (cursor / claude / codex / gemini) executes in a sandboxed ECS Fargate container.
-- Each node is one `.mjs` file under `<workflow>/nodes/`
-- The graph wires nodes together (`<workflow>/graph.mjs`)
-- `<workflow>/workflow.json` declares the workflow's name, entry class, triggers
-- Workflows live under `<workflowsBasePath>/<workflow-name>/` (default `.zibby/workflows/`, configured in the project root's `.zibby.config.mjs`)
+A agent is a graph of nodes that an AI agent (cursor / claude / codex / gemini) executes in a sandboxed ECS Fargate container.
+- Each node is one `.mjs` file under `<agent>/nodes/`
+- The graph wires nodes together (`<agent>/graph.mjs`)
+- `<agent>/workflow.json` declares the agent's name, entry class, triggers
+- Agents live under `<workflowsBasePath>/<workflow-name>/` (default `.zibby/workflows/`, configured in the project root's `.zibby.config.mjs`)
 
 For canonical, evolving docs see **https://docs.zibby.app/workflows/nodes**
 
 ## Steps for this command
 
-1. **Identify the target workflow.** Look under the path configured in `.zibby.config.mjs` `paths.workflows` (default `.zibby/workflows/`). If multiple workflows exist, ask the user which one. If they're already `cd`'d inside one, infer from `${cwd}`.
+1. **Identify the target agent.** Look under the path configured in `.zibby.config.mjs` `paths.workflows` (default `.zibby/workflows/`). If multiple agents exist, ask the user which one. If they're already `cd`'d inside one, infer from `${cwd}`.
 
 2. **Get the node spec from the user.** Ask:
    - Node name (kebab-case, e.g. `analyze-ticket`)
@@ -23,7 +23,7 @@ For canonical, evolving docs see **https://docs.zibby.app/workflows/nodes**
    - Inputs (variables it reads from prior nodes)
    - Outputs (variables it produces — these become available to downstream nodes)
 
-3. **Create the node file** at `<workflow>/nodes/<name>.mjs`. Pattern from the existing `example.mjs`:
+3. **Create the node file** at `<agent>/nodes/<name>.mjs`. Pattern from the existing `example.mjs`:
    ```js
    export default {
      id: '<name>',
@@ -42,27 +42,27 @@ For canonical, evolving docs see **https://docs.zibby.app/workflows/nodes**
 
 5. **Wire into `graph.mjs`** — add the node id to the graph's `nodes` array, then add an `edge` from its predecessor (or from `START` if it's first) and an edge to `END` (or its successor).
 
-6. **Update `workflow.json`** if the new node introduces an `outputSchema` the workflow's caller relies on. Most nodes don't need this.
+6. **Update `workflow.json`** if the new node introduces an `outputSchema` the agent's caller relies on. Most nodes don't need this.
 
 7. **Test locally:**
    ```
-   zibby workflow run <workflow-name>
-   zibby workflow run <workflow-name> -p ticket=BUG-123     # with input
+   zibby agent run <workflow-name>
+   zibby agent run <workflow-name> -p ticket=BUG-123     # with input
    ```
-   One-shot — exits when the run finishes. Same input flag surface as `zibby workflow trigger` (cloud).
+   One-shot — exits when the run finishes. Same input flag surface as `zibby agent trigger` (cloud).
 
 8. **Deploy when ready:**
    ```
-   zibby workflow deploy <workflow-name>
+   zibby agent deploy <workflow-name>
    ```
-   Then `zibby workflow trigger <uuid>` and `zibby workflow logs <uuid> -t` to verify.
+   Then `zibby agent trigger <uuid>` and `zibby agent logs <uuid> -t` to verify.
 
 ## Common pitfalls
 
 - **Node name must match the file name and `id`** — mismatches cause silent skip.
 - **`ctx.agent` calls block on the LLM** — large prompts can take 30+ seconds. Stream output for visibility.
-- **Don't import npm packages inside `run()`** — declare deps in `<workflow>/package.json`. The deploy bundler installs them.
-- **Failed nodes terminate the workflow** unless wrapped in try/catch and explicit `outputSchema.status: 'warn'`.
+- **Don't import npm packages inside `run()`** — declare deps in `<agent>/package.json`. The deploy bundler installs them.
+- **Failed nodes terminate the agent** unless wrapped in try/catch and explicit `outputSchema.status: 'warn'`.
 
 ## When to consult the user vs proceed
 

package/dist/templates/zibby-workflow-claude/claude/commands/zibby-debug.md

@@ -1,7 +1,7 @@
 <!-- zibby-template-version: 4 -->
-# /zibby-debug — diagnose a failing or stuck Zibby workflow
+# /zibby-debug — diagnose a failing or stuck Zibby agent
 
-You are helping the user debug a workflow that didn't behave as expected.
+You are helping the user debug an agent that didn't behave as expected.
 
 Canonical docs: **https://docs.zibby.app/workflows/debugging**
 
@@ -12,28 +12,28 @@ Apply in order. Stop at the first thing that explains the symptom.
 ### 1. Did the deploy succeed?
 
 ```
-zibby workflow list
+zibby agent list
 ```
-Find the workflow. If `bundleStatus` isn't `ready`, the deploy didn't finish. Re-run `zibby workflow deploy <name> --verbose` and read the CodeBuild output.
+Find the agent. If `bundleStatus` isn't `ready`, the deploy didn't finish. Re-run `zibby agent deploy <name> --verbose` and read the CodeBuild output.
 
 ### 2. Did the trigger reach ECS?
 
 ```
-zibby workflow trigger <uuid>
+zibby agent trigger <uuid>
 ```
 Look at the response — it should include a `Job ID` immediately. If you get an HTTP error, it's an auth or quota problem (CodeBuild concurrency, ECS task limit, etc.). Surface to the user.
 
 ### 3. Did the agent task START?
 
 ```
-zibby workflow logs <uuid> -t
+zibby agent logs <uuid> -t
 ```
 Within 30s of the trigger you should see `[setup] Fetching bundle...` then `zibby v<version>`. If silence past 30s:
 - Maybe ECS couldn't pull the image — check CloudWatch alarm `zibby-sse-fanout-no-task-prod`
 - Maybe the task started but its log stream is delayed — wait another 30s
-- Maybe the workflow row hasn't been written yet (rare — would only affect the very first second)
+- Maybe the agent row hasn't been written yet (rare — would only affect the very first second)
 
-### 4. Did the workflow execute the wrong path?
+### 4. Did the agent execute the wrong path?
 
 If the tail shows nodes running but in unexpected order, your `graph.mjs` edges are wrong. Common causes:
 - Edge from `START` is missing — first node never runs
@@ -55,7 +55,7 @@ Look for `[fanout] hard timeout` in the SSE fan-out logs (sse-fanout container)
 
 ### 7. Are you seeing logs from a stale execution?
 
-`-t` on a workflow UUID auto-attaches to the **latest** existing execution at connect time, plus new ones triggered while it's open. If you're tailing an old failed run, drain it (Ctrl+C, re-run after triggering fresh).
+`-t` on an agent UUID auto-attaches to the **latest** existing execution at connect time, plus new ones triggered while it's open. If you're tailing an old failed run, drain it (Ctrl+C, re-run after triggering fresh).
 
 ## Quick reference: what each piece does
 
@@ -64,4 +64,4 @@ Look for `[fanout] hard timeout` in the SSE fan-out logs (sse-fanout container)
 - **SSE fan-out** → polls CloudWatch, fans events out to subscribers (`-t` clients)
 - **Status** → moves through `starting → running → completed/failed/error`
 
-If `status` in DDB is wrong (e.g. stuck `running` after the task is gone), it's an upstream zombie — separate from any workflow logic issue.
+If `status` in DDB is wrong (e.g. stuck `running` after the task is gone), it's an upstream zombie — separate from any agent logic issue.

package/dist/templates/zibby-workflow-claude/claude/commands/zibby-delete.md

@@ -1,9 +1,9 @@
 <!-- zibby-template-version: 4 -->
-# /zibby-delete — delete a deployed Zibby workflow
+# /zibby-delete — delete a deployed Zibby agent
 
-You are helping the user remove a workflow from Zibby Cloud.
+You are helping the user remove an agent from Zibby Cloud.
 
-**This is destructive.** It removes the workflow record, its bundle in S3, and its routing — but does NOT delete in-flight executions or their CloudWatch logs (those age out per their retention policy). New triggers against the deleted UUID will fail.
+**This is destructive.** It removes the agent record, its bundle in S3, and its routing — but does NOT delete in-flight executions or their CloudWatch logs (those age out per their retention policy). New triggers against the deleted UUID will fail.
 
 Canonical docs: **https://docs.zibby.app/workflows/lifecycle**
 
@@ -11,18 +11,18 @@ Canonical docs: **https://docs.zibby.app/workflows/lifecycle**
 
 1. **Get the UUID.** If user gave a name, look it up:
    ```
-   Bash(zibby workflow list)
+   Bash(zibby agent list)
    ```
    Find the matching `name` and grab its `uuid`.
 
-2. **Confirm with the user.** Always confirm before deleting — show them the workflow's name, project, last-triggered timestamp. Don't proceed silently.
+2. **Confirm with the user.** Always confirm before deleting — show them the agent's name, project, last-triggered timestamp. Don't proceed silently.
    ```
-   "Delete workflow 'pr-summarizer' (uuid abc-123, last run 2 days ago)? This cannot be undone."
+   "Delete agent 'pr-summarizer' (uuid abc-123, last run 2 days ago)? This cannot be undone."
    ```
 
 3. **Run the delete:**
    ```
-   Bash(zibby workflow delete <uuid>)
+   Bash(zibby agent delete <uuid>)
    ```
 
 4. **Clean up local files** if the user wants. The local `.zibby/workflows/<name>/` folder isn't auto-deleted — ask before removing:

package/dist/templates/zibby-workflow-claude/claude/commands/zibby-deploy.md

@@ -1,24 +1,24 @@
 <!-- zibby-template-version: 4 -->
-# /zibby-deploy — deploy a Zibby workflow to the cloud
+# /zibby-deploy — deploy a Zibby agent to the cloud
 
-You are helping the user deploy a workflow they've been building locally.
+You are helping the user deploy an agent they've been building locally.
 
-## What `zibby workflow deploy` does
+## What `zibby agent deploy` does
 
-1. Bundles the workflow's source (graph.mjs + nodes/ + package.json) into a tarball
+1. Bundles the agent's source (graph.mjs + nodes/ + package.json) into a tarball
 2. Uploads it to S3 via a presigned URL
 3. Triggers AWS CodeBuild to install deps + bake the bundle
 4. Updates DynamoDB so future triggers run the new bundle
 
-A successful deploy is required before `zibby workflow trigger <uuid>` works against the cloud.
+A successful deploy is required before `zibby agent trigger <uuid>` works against the cloud.
 
 Canonical docs: **https://docs.zibby.app/workflows/deploying**
 
 ## Steps for this command
 
-1. **Identify the workflow.** If the user passes a name, use it. Otherwise list everything under `paths.workflows` (from `.zibby.config.mjs`) and ask.
+1. **Identify the agent.** If the user passes a name, use it. Otherwise list everything under `paths.workflows` (from `.zibby.config.mjs`) and ask.
 
-2. **Pre-flight checks.** Read the workflow folder and confirm:
+2. **Pre-flight checks.** Read the agent folder and confirm:
    - `graph.mjs` exists and exports a graph
    - `nodes/` has at least one node
    - `workflow.json` is valid (must have `name`, `entryClass`, `triggers`)
@@ -26,62 +26,62 @@ Canonical docs: **https://docs.zibby.app/workflows/deploying**
 
 3. **Run the deploy:**
    ```
-   zibby workflow deploy <workflow-name>
+   zibby agent deploy <workflow-name>
    ```
    This is interactive if `--project` isn't passed. The user picks a project, the CLI handles auth via the saved session token.
 
-4. **Watch the build.** The CLI streams CodeBuild output. If it succeeds, it prints the workflow's UUID. If it fails, the build logs show why — usually a missing dep in `package.json` or a syntax error in a node.
+4. **Watch the build.** The CLI streams CodeBuild output. If it succeeds, it prints the agent's UUID. If it fails, the build logs show why — usually a missing dep in `package.json` or a syntax error in a node.
 
 5. **Verify post-deploy:**
    ```
-   zibby workflow trigger <uuid> --input '{}'
-   zibby workflow logs <uuid> -t
+   zibby agent trigger <uuid> --input '{}'
+   zibby agent logs <uuid> -t
    ```
-   Tail logs until the workflow reaches `completed` (or `failed` — diagnose from logs).
+   Tail logs until the agent reaches `completed` (or `failed` — diagnose from logs).
 
 ## Common failure modes
 
 - **Build fails with module-not-found** → node imports a package not in `package.json`. Add it and redeploy.
 - **Build succeeds but trigger fails immediately** → `entryClass` in `workflow.json` doesn't match a class exported by `graph.mjs`.
-- **Workflow runs but a node fails** → tail the live logs and read the error. Most are in the agent's prompt/output handling.
+- **Agent runs but a node fails** → tail the live logs and read the error. Most are in the agent's prompt/output handling.
 
 ## Optional flags worth knowing
 
-`zibby workflow deploy` accepts:
+`zibby agent deploy` accepts:
 - `--project <id>` — skip the interactive project picker
 - `--api-key <key>` — use a PAT instead of the session token (for CI)
-- `--env <path>` — sync a `.env` file into per-workflow env vars after deploy. Repeatable; later files override.
+- `--env <path>` — sync a `.env` file into per-agent env vars after deploy. Repeatable; later files override.
 - `--verbose` — print raw CodeBuild output during the build (helpful for debugging build failures)
 
-### Seeding per-workflow env on first deploy
+### Seeding per-agent env on first deploy
 
-If the workflow needs its own `ANTHROPIC_API_KEY`, `DATABASE_URL`, etc., put them in a `.env` and pass `--env`:
+If the agent needs its own `ANTHROPIC_API_KEY`, `DATABASE_URL`, etc., put them in a `.env` and pass `--env`:
 
 ```
-zibby workflow deploy <name> --env .env
-zibby workflow deploy <name> --env .env --env .env.prod   # later files win
+zibby agent deploy <name> --env .env
+zibby agent deploy <name> --env .env --env .env.prod   # later files win
 ```
 
-After deploy, manage them surgically with `zibby workflow env set/unset/list/push <uuid>`. See `/zibby-list` to recover the UUID; full guide at https://docs.zibby.app/cloud/env-vars.
+After deploy, manage them surgically with `zibby agent env set/unset/list/push <uuid>`. See `/zibby-list` to recover the UUID; full guide at https://docs.zibby.app/cloud/env-vars.
 
 ## Static outbound IP (dedicated egress)
 
-If the user's workflow needs to call APIs that require IP allowlisting (corporate GitHub, GitLab Enterprise, paranoid SaaS firewalls), the workflow needs the **dedicated egress IP** addon. The flag lives on the legacy alias `zibby deploy` (NOT `zibby workflow deploy`):
+If the user's agent needs to call APIs that require IP allowlisting (corporate GitHub, GitLab Enterprise, paranoid SaaS firewalls), the agent needs the **dedicated egress IP** addon. The flag lives on the legacy alias `zibby deploy` (NOT `zibby agent deploy`):
 
 | Flag | What it does |
 |------|-------------|
 | `zibby deploy <name> --dedicated-ip status` | Show current addon state for the account (active / inactive / billing) |
 | `zibby deploy <name> --dedicated-ip enable` | Enable the addon on the account (Pro subscription required, ~$50/mo). One-time per account. |
-| `zibby deploy <name> --dedicated-ip use` | Mark THIS workflow as using the static egress IP (per-workflow opt-in, after `enable`) |
-| `zibby deploy <name> --dedicated-ip unuse` | Stop routing this workflow through the static IP |
+| `zibby deploy <name> --dedicated-ip use` | Mark THIS agent as using the static egress IP (per-agent opt-in, after `enable`) |
+| `zibby deploy <name> --dedicated-ip unuse` | Stop routing this agent through the static IP |
 | `zibby deploy <name> --dedicated-ip disable` | Disable the addon for the whole account |
 
 Typical first-time flow when the user says "I need a static outbound IP":
 1. `zibby deploy <name> --dedicated-ip status` — check whether they have it
 2. If inactive → `zibby deploy <name> --dedicated-ip enable` — enables the account-wide addon (interactive billing prompt; prerequisite Pro subscription)
-3. `zibby deploy <name> --dedicated-ip use` — opts this specific workflow in
-4. Regular `zibby workflow deploy <name>` from now on uses the static IP
+3. `zibby deploy <name> --dedicated-ip use` — opts this specific agent in
+4. Regular `zibby agent deploy <name>` from now on uses the static IP
 
-After `--dedicated-ip use`, every node in this workflow gets its outbound HTTP routed through the egress proxy, and `process.env.HTTP_PROXY` / `HTTPS_PROXY` are set in the sandbox automatically. Their static IPs are visible to customers via `https://docs.zibby.app/workflows/egress`.
+After `--dedicated-ip use`, every node in this agent gets its outbound HTTP routed through the egress proxy, and `process.env.HTTP_PROXY` / `HTTPS_PROXY` are set in the sandbox automatically. Their static IPs are visible to customers via `https://docs.zibby.app/workflows/egress`.
 
 **Don't** run `--dedicated-ip enable` without confirming with the user — it has billing impact ($50/mo addon). Always confirm. See `/zibby-static-ip` for the deeper walkthrough.

package/dist/templates/zibby-workflow-claude/claude/commands/zibby-list.md

@@ -1,7 +1,7 @@
 <!-- zibby-template-version: 4 -->
-# /zibby-list — list workflows (local + cloud) with their UUIDs and statuses
+# /zibby-list — list agents (local + cloud) with their UUIDs and statuses
 
-You are helping the user see what workflows exist — locally scaffolded and remotely deployed.
+You are helping the user see what agents exist — locally scaffolded and remotely deployed.
 
 Canonical docs: **https://docs.zibby.app/cli-reference#workflow-list**
 
@@ -9,22 +9,22 @@ Canonical docs: **https://docs.zibby.app/cli-reference#workflow-list**
 
 1. **Run the list command:**
    ```
-   Bash(zibby workflow list)
+   Bash(zibby agent list)
    ```
-   This shows both local (in `.zibby/workflows/`) and remote (deployed to Zibby Cloud) workflows. Each row has: name, UUID, project, last triggered.
+   This shows both local (in `.zibby/workflows/`) and remote (deployed to Zibby Cloud) agents. Each row has: name, UUID, project, last triggered.
 
 2. **Filter on demand.** If the user wants only local or only remote:
    ```
-   zibby workflow list --local-only
-   zibby workflow list --remote-only --project <id>
+   zibby agent list --local-only
+   zibby agent list --remote-only --project <id>
    ```
 
 ## When you'd use this
 
-- User asks "what workflows do I have?" → run it, show the result.
+- User asks "what agents do I have?" → run it, show the result.
 - You need a UUID to pass into `/zibby-trigger`, `/zibby-tail`, `/zibby-delete` and the user only knows the name → run it, look up the UUID.
 - After a deploy to confirm the bundle landed.
 
 ## Output expectations
 
-The output is human-readable text (not JSON). If you need to extract a specific UUID programmatically, parse the line for the workflow name. If the user has many workflows, ask which one they want — don't grep blind.
+The output is human-readable text (not JSON). If you need to extract a specific UUID programmatically, parse the line for the agent name. If the user has many agents, ask which one they want — don't grep blind.

package/dist/templates/zibby-workflow-claude/claude/commands/zibby-static-ip.md

@@ -1,19 +1,19 @@
 <!-- zibby-template-version: 4 -->
-# /zibby-static-ip — set up dedicated outbound static IP for a workflow
+# /zibby-static-ip — set up dedicated outbound static IP for an agent
 
-You are helping the user route a workflow's outbound traffic through a static IP address — needed when the workflow calls APIs that require IP allowlisting (corporate GitLab/GitHub Enterprise, internal SaaS, firewalls).
+You are helping the user route an agent's outbound traffic through a static IP address — needed when the agent calls APIs that require IP allowlisting (corporate GitLab/GitHub Enterprise, internal SaaS, firewalls).
 
 Canonical docs: **https://docs.zibby.app/workflows/egress**
 
-> Note: the `--dedicated-ip` flag lives on the legacy alias `zibby deploy <name>`, NOT on `zibby workflow deploy <name>`. The two share a handler, but only `zibby deploy` exposes this flag in `--help`.
+> Note: the `--dedicated-ip` flag lives on the legacy alias `zibby deploy <name>`, NOT on `zibby agent deploy <name>`. The two share a handler, but only `zibby deploy` exposes this flag in `--help`.
 
 ## What "static IP" means here
 
-By default, workflow tasks run on Fargate and their outbound traffic exits via AWS-managed IPs that rotate. With the **dedicated egress** addon enabled, the workflow's outbound traffic is routed through a Zibby-managed proxy whose IP is pinned and customer-allowlistable.
+By default, agent tasks run on Fargate and their outbound traffic exits via AWS-managed IPs that rotate. With the **dedicated egress** addon enabled, the agent's outbound traffic is routed through a Zibby-managed proxy whose IP is pinned and customer-allowlistable.
 
 Two pieces:
 1. **Account-level addon** — `~$50/mo`, requires Pro subscription. One-time toggle per account.
-2. **Per-workflow opt-in** — once the addon is on, each workflow opts in individually (some workflows might not need it, no point routing them).
+2. **Per-agent opt-in** — once the addon is on, each agent opts in individually (some agents might not need it, no point routing them).
 
 ## Steps
 
@@ -27,23 +27,23 @@ Two pieces:
    ```
    Bash(zibby deploy <name> --dedicated-ip status)
    ```
-   Output tells you: addon active or inactive, this workflow currently using it or not, and the assigned IPs to publish to customers.
+   Output tells you: addon active or inactive, this agent currently using it or not, and the assigned IPs to publish to customers.
 
 3. **If addon is inactive — enable it** (only after explicit user confirmation):
    ```
    Bash(zibby deploy <name> --dedicated-ip enable)
    ```
-   This is one-time per account. After this, the addon is active for ALL workflows in the account that opt in.
+   This is one-time per account. After this, the addon is active for ALL agents in the account that opt in.
 
-4. **Opt this workflow in:**
+4. **Opt this agent in:**
    ```
    Bash(zibby deploy <name> --dedicated-ip use)
    ```
-   From now on, every deploy of this workflow + every triggered execution routes outbound through the static IP.
+   From now on, every deploy of this agent + every triggered execution routes outbound through the static IP.
 
-5. **Re-deploy the workflow** so the runtime picks up the change:
+5. **Re-deploy the agent** so the runtime picks up the change:
    ```
-   Bash(zibby workflow deploy <name>)
+   Bash(zibby agent deploy <name>)
    ```
 
 6. **Verify in a node** by adding a quick log:
@@ -54,7 +54,7 @@ Two pieces:
 
 ## Reverting
 
-- `Bash(zibby deploy <name> --dedicated-ip unuse)` — stop routing this workflow's egress through the static IP. Other opted-in workflows are unaffected.
+- `Bash(zibby deploy <name> --dedicated-ip unuse)` — stop routing this agent's egress through the static IP. Other opted-in agents are unaffected.
 - `Bash(zibby deploy <name> --dedicated-ip disable)` — disable the addon entirely (also stops billing).
 
 ## Tell the user the IPs
@@ -67,4 +67,4 @@ Outbound static IPs (allowlist these in the customer's firewall):
 
 ## Don't confuse with the inbound static IPs
 
-This is OUTBOUND (workflow → external API). There's also an INBOUND static-IP set for `https://logs-stream.zibby.app` (the SSE log endpoint customers tail with `zibby workflow logs -t`). That one is unrelated to this addon — see `https://docs.zibby.app/security/ip-allowlist`.
+This is OUTBOUND (agent → external API). There's also an INBOUND static-IP set for `https://logs-stream.zibby.app` (the SSE log endpoint customers tail with `zibby agent logs -t`). That one is unrelated to this addon — see `https://docs.zibby.app/security/ip-allowlist`.