@zibby/cli 0.7.0 → 0.7.2

package/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/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/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`.

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