@zibby/cli 0.6.1 → 0.7.1

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

@@ -1,53 +1,53 @@
 <!-- zibby-template-version: 4 -->
-# /zibby-tail — stream live logs from a Zibby workflow
+# /zibby-tail — stream live logs from a Zibby agent
 
-You are helping the user tail logs from a workflow execution.
+You are helping the user tail logs from an agent execution.
 
-`zibby workflow logs <jobId> -t` is the live-streaming variant (like `heroku logs --tail` or `docker compose logs -f`). Without `-t`, you get a one-shot fetch.
+`zibby agent logs <jobId> -t` is the live-streaming variant (like `heroku logs --tail` or `docker compose logs -f`). Without `-t`, you get a one-shot fetch.
 
 Canonical docs: **https://docs.zibby.app/workflows/logs**
 
 ## What `<jobId>` accepts
 
-- A **workflow UUID** (`2b1ea07f-...`) → tails ALL currently-active executions of that workflow, plus any new ones triggered while the tail is open. Lines are interleaved by arrival time, prefixed with `(taskId)` so concurrent runs are distinguishable.
+- A **agent UUID** (`2b1ea07f-...`) → tails ALL currently-active executions of that agent, plus any new ones triggered while the tail is open. Lines are interleaved by arrival time, prefixed with `(taskId)` so concurrent runs are distinguishable.
 - An **execution ID** (`abc-...`) → tails just that single execution. Closes when the execution drains.
 
 ## Example flow
 
 ```
-$ zibby workflow trigger 2b1ea07f-3ede-4bfd-a51d-431f0bab008e
+$ zibby agent trigger 2b1ea07f-3ede-4bfd-a51d-431f0bab008e
 Job ID: 569ef1ee-15c8-4ee7-af30-933c8bec7ea7
 
-$ zibby workflow logs 2b1ea07f-3ede-4bfd-a51d-431f0bab008e -t
-  Streaming logs for workflow 2b1ea07f-...
+$ zibby agent logs 2b1ea07f-3ede-4bfd-a51d-431f0bab008e -t
+  Streaming logs for agent 2b1ea07f-...
   Press Ctrl+C to stop.
 
   ┌─ Execution: 569ef1ee...7ea7 (task: 9e61c690)
   └─ Streaming logs...
 
 2026-05-04 06:16:27.621  (9e61c690) zibby v0.1.91
-2026-05-04 06:16:27.997  (9e61c690)  Workflow:  hello-world
+2026-05-04 06:16:27.997  (9e61c690)  Agent:  hello-world
 2026-05-04 06:16:33.055  (9e61c690) │ Prompt sent to LLM:
 ...
-2026-05-04 06:16:56.389  (9e61c690) ✓ Workflow completed
+2026-05-04 06:16:56.389  (9e61c690) ✓ Agent completed
 ```
 
 ## Tail behavior worth knowing
 
 - **Auto-switch:** when the current execution drains and a new trigger lands, the tail seamlessly picks it up — no need to re-run the command.
-- **Multi-attach:** if you trigger two workflows in parallel, the tail attaches to both. Lines from each are interleaved by timestamp.
+- **Multi-attach:** if you trigger two agents in parallel, the tail attaches to both. Lines from each are interleaved by timestamp.
 - **Reconnect:** transient network blips reconnect silently. Long quiet windows (3+ min) are kept alive via 5s keepalives.
 
 ## Steps for this command
 
-1. Identify the jobId. If user gives a workflow name (not UUID), look it up via `zibby workflow list` and use the UUID.
+1. Identify the jobId. If user gives an agent name (not UUID), look it up via `zibby agent list` and use the UUID.
 2. **Run in the background** — `-t` is a long-running stream. If you call `Bash` without `run_in_background: true` it'll block the chat for minutes:
    ```
-   Bash({ command: "zibby workflow logs <jobId> -t", run_in_background: true })
+   Bash({ command: "zibby agent logs <jobId> -t", run_in_background: true })
    ```
    Then use `BashOutput` (or whatever your background-output tool is) to read new lines as they arrive.
 3. If the user wants a **one-shot snapshot** (no follow), drop the `-t` flag and call Bash normally:
    ```
-   Bash({ command: "zibby workflow logs <jobId>" })
+   Bash({ command: "zibby agent logs <jobId>" })
    ```
 4. To stop the live tail: kill the background bash task. The CLI exits cleanly with `Stopped streaming.`

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

@@ -1,17 +1,17 @@
 <!-- zibby-template-version: 4 -->
-# /zibby-trigger — run a deployed Zibby workflow
+# /zibby-trigger — run a deployed Zibby agent
 
-You are helping the user trigger a deployed workflow execution.
+You are helping the user trigger a deployed agent execution.
 
-A trigger creates a new ECS Fargate task that loads the workflow's bundle, runs the graph, and writes status + logs as it goes.
+A trigger creates a new ECS Fargate task that loads the agent's bundle, runs the graph, and writes status + logs as it goes.
 
 Canonical docs: **https://docs.zibby.app/cloud/triggering**
 
 ## Steps
 
-1. **Get the workflow UUID.** The user should provide it; if not, run `zibby workflow list` to discover it. UUIDs are stable across deploys (the same workflow always has the same UUID; only the bundle version changes).
+1. **Get the agent UUID.** The user should provide it; if not, run `zibby agent list` to discover it. UUIDs are stable across deploys (the same agent always has the same UUID; only the bundle version changes).
 
-2. **Construct the input.** Workflows take a JSON input that nodes can read via `ctx.input`. Ask the user what input the workflow expects (or read `workflow.json`'s `inputSchema` if present).
+2. **Construct the input.** Agents take a JSON input that nodes can read via `ctx.input`. Ask the user what input the agent expects (or read `workflow.json`'s `inputSchema` if present).
 
 3. **Run the trigger.** Three ways to pass input — they merge with this **precedence (highest → lowest)**:
    1. `-p key=value` (repeatable) — wins over everything; great for shell-friendly tweaks on top of a base payload
@@ -19,21 +19,21 @@ Canonical docs: **https://docs.zibby.app/cloud/triggering**
    3. `--input-file path.json` — full JSON/YAML payload from a file (lowest precedence; `-p` and `--input` override individual keys)
 
    ```
-   zibby workflow trigger <uuid> --input '{"key":"value"}'
-   zibby workflow trigger <uuid> -p ticket=ENG-1234 -p priority=high
-   zibby workflow trigger <uuid> --input-file payload.json -p priority=urgent   # mix
+   zibby agent trigger <uuid> --input '{"key":"value"}'
+   zibby agent trigger <uuid> -p ticket=ENG-1234 -p priority=high
+   zibby agent trigger <uuid> --input-file payload.json -p priority=urgent   # mix
    ```
 
-   Same flag surface as `zibby workflow run` (local) — flip the verb and the same call shape goes from local to remote.
+   Same flag surface as `zibby agent run` (local) — flip the verb and the same call shape goes from local to remote.
 
 4. **Tail the logs immediately:**
    ```
-   zibby workflow logs <uuid> -t
+   zibby agent logs <uuid> -t
    ```
-   This streams live output. The tail auto-attaches to all currently-running executions of the workflow (docker-compose-style), so back-to-back triggers interleave naturally.
+   This streams live output. The tail auto-attaches to all currently-running executions of the agent (docker-compose-style), so back-to-back triggers interleave naturally.
 
-5. **Watch for completion.** Workflow runs typically end with one of:
-   - `✓ Workflow completed` — success, status `completed`
+5. **Watch for completion.** Agent runs typically end with one of:
+   - `✓ Agent completed` — success, status `completed`
    - `Error: Node 'X' failed` — a node threw; status `failed`
    - silent timeout — task killed by ECS; status stays `running` then becomes a zombie. Trigger again.
 
@@ -41,7 +41,7 @@ Canonical docs: **https://docs.zibby.app/cloud/triggering**
 
 Use `--idempotency-key <key>` to prevent duplicate runs from a retry-prone caller:
 ```
-zibby workflow trigger <uuid> --input '{}' --idempotency-key job-2026-05-04-001
+zibby agent trigger <uuid> --input '{}' --idempotency-key job-2026-05-04-001
 ```
 Same key + same input within ~24h = same execution returned (no new run).
 
@@ -50,7 +50,7 @@ Same key + same input within ~24h = same execution returned (no new run).
 There's no built-in batch trigger — script it from your shell:
 ```
 for ticket in ENG-1 ENG-2 ENG-3; do
-  zibby workflow trigger <uuid> -p ticket=$ticket
+  zibby agent trigger <uuid> -p ticket=$ticket
 done
-zibby workflow logs <uuid> -t   # tail will show all 3 interleaved
+zibby agent logs <uuid> -t   # tail will show all 3 interleaved
 ```

package/dist/templates/zibby-workflow-claude/cursor/rules/zibby-workflows.mdc

@@ -1,6 +1,6 @@
 <!-- zibby-template-version: 4 -->
 ---
-description: Help the user build, test, and deploy Zibby agent workflows + browser tests
+description: Help the user build, test, and deploy Zibby agents + browser tests
 globs:
   - "**/.zibby/workflows/**"
   - ".zibby.config.mjs"
@@ -11,11 +11,11 @@ globs:
 alwaysApply: false
 ---
 
-# Zibby — workflows + tests
+# Zibby — agents + tests
 
 This project uses **Zibby**. Two surfaces share `.zibby.config.mjs` at the project root.
 
-## Workflows
+## Agents
 
 A graph of AI-agent-driven steps that runs inside an ECS Fargate sandbox.
 
@@ -32,14 +32,14 @@ Each node exports `{ id, description, async run(ctx) }`. `ctx` provides `input`,
 ### Common dev loop
 
 ```
-zibby workflow new <name>          # scaffold
-zibby workflow run <name>          # one-shot local run (preferred for the dev loop)
-zibby workflow deploy <name>       # build + push to cloud
-zibby workflow trigger <uuid>      # invoke the cloud workflow
-zibby workflow logs <uuid> -t      # tail live logs (docker-compose-style for concurrent runs)
-zibby workflow list                # local + cloud
-zibby workflow download <uuid>     # pull cloud 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 deploy <name>       # build + push to cloud
+zibby agent trigger <uuid>      # invoke the cloud agent
+zibby agent logs <uuid> -t      # tail live logs (docker-compose-style for concurrent runs)
+zibby agent list                # local + cloud
+zibby agent download <uuid>     # pull cloud source back to .zibby/workflows/
+zibby agent delete <uuid>       # remove a deployed agent
 ```
 
 `run` (one-shot) vs `start` (long-lived dev server, port 3848 — Studio integration). For plain CLI iteration always use `run`.
@@ -51,20 +51,20 @@ zibby workflow delete <uuid>       # remove a deployed workflow
 1. Create `<workflow>/nodes/<name>.mjs` (mirror existing `example.mjs` pattern)
 2. Register in `<workflow>/nodes/index.mjs`
 3. Wire into `<workflow>/graph.mjs` (add to `nodes` array and connect via edges)
-4. `zibby workflow run <name>` to test locally; `zibby workflow deploy` to push
+4. `zibby agent run <name>` to test locally; `zibby agent deploy` to push
 
-### 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
-zibby workflow env unset <uuid> OLD_KEY                   # remove one
-zibby workflow env push  <uuid> --file .env [--file .env.prod]   # bulk replace
+zibby agent env list  <uuid>                          # show key names (values never returned)
+zibby agent env set   <uuid> ANTHROPIC_API_KEY=sk-…    # add or rotate one
+zibby agent env unset <uuid> OLD_KEY                   # remove one
+zibby agent env push  <uuid> --file .env [--file .env.prod]   # bulk replace
 ```
 
-Fast path on first deploy: `zibby workflow deploy my-pipeline --env .env` deploys, then auto-pushes the .env into the new UUID.
+Fast path on first deploy: `zibby agent deploy my-pipeline --env .env` deploys, then auto-pushes the .env into the new UUID.
 
 ## Tests (`zibby test`)
 

package/dist/templates/zibby-workflow-claude/manifest.json

@@ -1,6 +1,6 @@
 {
   "templateVersion": 4,
-  "description": "Canonical agent helpers for Zibby workflows. Each shipped file carries '<!-- zibby-template-version: N -->' for idempotent upgrades. Bumped on breaking content changes.",
+  "description": "Canonical agent helpers for Zibby agents. Each shipped file carries '<!-- zibby-template-version: N -->' for idempotent upgrades. Bumped on breaking content changes.",
   "agents": {
     "claude": {
       "files": [

package/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/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/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/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/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/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: