@zibby/skills 0.2.22 → 0.2.24

package/docs/integrations/github.md

@@ -1,73 +0,0 @@
----
-sidebar_position: 1
-title: GitHub Integration
----
-
-# GitHub Integration
-
-Connect your GitHub repositories so Zibby can analyze your codebase and create pull requests from AI-generated code.
-
-## How It Works
-
-Zibby uses a **GitHub App** to access your repositories. The app requests read access to your code and write access to create pull requests.
-
-When you run an analysis, Zibby:
-
-1. Clones the repository into a secure container
-2. Analyzes the codebase alongside the Jira ticket
-3. Generates code changes as a diff
-4. Optionally creates a pull request with the suggested changes
-
-## Connect GitHub
-
-1. Go to your project's **Settings** page in the Zibby dashboard
-2. Under **Integrations**, click **Connect GitHub**
-3. You'll be redirected to GitHub to install the Zibby App
-4. Select the repositories you want to grant access to
-5. Click **Install & Authorize**
-6. You'll be redirected back to Zibby
-
-## Permissions
-
-The Zibby GitHub App requests:
-
-| Permission | Level | Purpose |
-|---|---|---|
-| Repository contents | Read | Clone and analyze your code |
-| Pull requests | Write | Create PRs from generated code |
-| Metadata | Read | List repositories |
-
-## Select Repositories
-
-After connecting, go to **Settings > Repositories** to select which repos are available for analysis. You can choose:
-
-- **Primary repository** — the main codebase for analysis
-- **Additional repositories** — supporting repos that provide context
-
-## Creating Pull Requests
-
-After an analysis generates code changes:
-
-1. Go to the **Analysis** page for the ticket
-2. Review the code diff in the **Code Changes** tab
-3. Click **Create Pull Request**
-4. Zibby creates a PR on your repository with the suggested changes
-5. Review and merge through your normal GitHub workflow
-
-## Token Management
-
-Zibby uses GitHub App installation tokens that automatically refresh. You don't need to manage tokens manually. If you need to reconnect:
-
-1. Go to **Settings > Integrations**
-2. Click **Disconnect** next to GitHub
-3. Click **Connect GitHub** to re-authorize
-
-## Troubleshooting
-
-**"Repository not found" during analysis**
-
-Make sure the repository is selected in your project settings and the GitHub App has access to it.
-
-**"Permission denied" when creating PR**
-
-Verify the GitHub App installation has write access to pull requests for the target repository.

package/docs/integrations/gitlab.md

@@ -1,43 +0,0 @@
----
-sidebar_position: 5
-title: GitLab Integration
----
-
-# GitLab Integration
-
-Connect a **self-hosted GitLab** instance (or GitLab SaaS) so your agents can read repos, merge requests, issues, and pipelines. GitLab uses a **Personal Access Token**.
-
-## How It Works
-
-You provide your GitLab instance URL and a Personal Access Token. The `gitlab` skill then exposes GitLab's API to any node that declares it. Outbound calls to a firewalled self-hosted instance can be pinned to a [dedicated egress IP](../cloud/dedicated-egress.md).
-
-## Connect GitLab
-
-1. In GitLab, go to **User Settings → Access Tokens** and create a Personal Access Token with the `read_api` and `read_repository` scopes (form `glpat-...`)
-2. In the Zibby dashboard, go to **Settings → Integrations** and click **Connect GitLab**
-3. Enter your **GitLab Instance URL** (e.g. `https://gitlab.company.com`)
-4. Paste the **Personal Access Token**
-5. Click **Connect** — Zibby validates both before saving
-
-| Field | Required | Notes |
-|---|---|---|
-| GitLab Instance URL | Yes | Your instance, e.g. `https://gitlab.company.com` (or `https://gitlab.com`) |
-| Personal Access Token | Yes | `glpat-...` with `read_api` + `read_repository` scopes |
-
-## What Agents Can Do
-
-Nodes that attach the [`gitlab` skill](../skills/index.md) get tools for repos, merge requests, issues, and pipelines, against either self-hosted GitLab or GitLab SaaS.
-
-## Reference keys (SDK / CLI)
-
-When running agents directly, the connector reads `GITLAB_TOKEN` (and a base URL for self-hosted instances) from the environment.
-
-## Firewalled instances
-
-If your GitLab is behind a firewall, add the [dedicated egress IP addon](../cloud/dedicated-egress.md) so all outbound traffic comes from one whitelistable IP.
-
-## Troubleshooting
-
-**"401 Unauthorized"** — regenerate the token with `read_api` + `read_repository` scopes; expired or under-scoped tokens fail here.
-
-**"Could not reach instance"** — confirm the instance URL is reachable from Zibby's egress IP and that it points at the GitLab base URL, not a project page.

package/docs/integrations/jira.md

@@ -1,71 +0,0 @@
----
-sidebar_position: 2
-title: Jira Integration
----
-
-# Jira Integration
-
-Connect your Jira workspace to sync tickets into Zibby for analysis and test generation.
-
-## How It Works
-
-Zibby uses OAuth 2.0 to connect to your Atlassian/Jira account. Once connected, it syncs tickets from your selected Jira project and keeps them up to date.
-
-## Connect Jira
-
-1. Go to your project's **Settings** page in the Zibby dashboard
-2. Under **Integrations**, click **Connect Jira**
-3. You'll be redirected to Atlassian to authorize Zibby
-4. Grant access to your Jira workspace
-5. You'll be redirected back to Zibby
-
-## Select a Jira Space
-
-After connecting:
-
-1. Go to **Settings > Jira Configuration**
-2. Select the Jira project/space to sync (e.g., "SCRUM", "ENG")
-3. Zibby will import all tickets from that space
-
-## Synced Data
-
-For each ticket, Zibby imports:
-
-- **Summary** and **Description** (including Atlassian Document Format)
-- **Issue type** (Story, Bug, Task, etc.)
-- **Priority** (High, Medium, Low)
-- **Labels** and **Components**
-- **Acceptance criteria** (from description)
-
-## Ticket Management
-
-In the **Tickets** page:
-
-- Tickets sync automatically when you visit the page
-- Drag and drop to reorder tickets by priority
-- Click a ticket to view full details and run analysis
-- Ticket order is preserved across sessions
-
-## Reconnecting
-
-Jira tokens expire periodically. If you see a "Please reconnect Jira" message:
-
-1. Go to **Settings > Integrations**
-2. Click **Reconnect** next to Jira
-3. Re-authorize through the Atlassian OAuth flow
-
-Your existing tickets and their order are preserved after reconnecting.
-
-## Troubleshooting
-
-**"Token refresh failed" error**
-
-Your Jira refresh token has expired. Go to Settings and reconnect Jira. This won't affect your existing ticket data or analysis results.
-
-**Tickets not syncing**
-
-Make sure the correct Jira space is selected in Settings. Only tickets from the selected space are displayed.
-
-**Duplicate tickets after reconnecting**
-
-This shouldn't happen — Zibby matches tickets by their Jira key (e.g., SCRUM-123) and updates existing records rather than creating duplicates.

package/docs/integrations/lark.md

@@ -1,41 +0,0 @@
----
-sidebar_position: 8
-title: Lark Integration
----
-
-# Lark Integration
-
-Connect a Lark (Feishu) self-built app so your agents can send messages, reply, list chats, and read chat history. Lark uses an **App ID + App Secret**.
-
-## How It Works
-
-You create a self-built app in the Lark Developer Console and paste its App ID and App Secret into Zibby. Optionally add a Verification Token and Encrypt Key if you want inbound Lark events to trigger Zibby agents. The `lark` skill then exposes Lark's API to any node that declares it.
-
-## Connect Lark
-
-1. In the Lark Developer Console, open your self-built app and go to **Credentials & Basic Info**
-2. Copy the **App ID** (`cli_...`) and **App Secret**
-3. In the Zibby dashboard, go to **Settings → Integrations** and click **Connect Lark**
-4. Paste the App ID and App Secret
-5. (Optional) Add the **Verification Token** and **Encrypt Key** from **Event Subscriptions** if you want inbound events
-
-| Field | Required | Notes |
-|---|---|---|
-| App ID | Yes | `cli_...` from Credentials & Basic Info |
-| App Secret | Yes | From Credentials & Basic Info |
-| Verification Token | No | Required only for inbound events (Event Subscriptions) |
-| Encrypt Key | No | Only if Lark-side event encryption is enabled |
-
-## What Agents Can Do
-
-Nodes that attach the [`lark` skill](../skills/lark.md) get `lark_send_message`, `lark_reply`, `lark_list_chats`, and `lark_get_chat_history` — used by routing recipes like [Sentry triage](../recipes/sentry-triage.md) as a Slack alternative.
-
-## Inbound events
-
-Adding the Verification Token (and Encrypt Key, if enabled) lets Lark events fire your Zibby agents. Leave them blank for outbound-only (notifications).
-
-## Troubleshooting
-
-**"Invalid App Secret"** — regenerate the secret in the Developer Console and reconnect.
-
-**Bot can't post to a chat** — the app must be added to the target chat/group and have the messaging permission scopes granted in the console.

package/docs/integrations/linear.md

@@ -1,43 +0,0 @@
----
-sidebar_position: 3
-title: Linear Integration
----
-
-# Linear Integration
-
-Connect Linear so your agents can read and update issues, comments, and workflow states. Linear uses a **personal API key** — no OAuth round-trip.
-
-## How It Works
-
-You paste a single Linear personal API key. Zibby validates it (by querying the authenticated viewer) before storing it, then the `linear` skill exposes Linear's API to any node that declares it.
-
-## Connect Linear
-
-1. In Linear, go to **Settings → Security & access → Personal API keys**
-2. Create a new key — it has the form `lin_api_...`
-3. In the Zibby dashboard, go to **Settings → Integrations** and click **Connect Linear**
-4. Paste the key and click **Connect**
-
-That's it — one field. Zibby verifies the key against Linear's GraphQL API before saving.
-
-## What Agents Can Do
-
-Once connected, nodes that attach the [`linear` skill](../skills/index.md) get these tools:
-
-| Tool | What it does |
-|---|---|
-| `linear_list_issues` | List issues (filter by team, state, assignee, label) |
-| `linear_get_issue` | Fetch one issue with full detail |
-| `linear_add_comment` | Comment on an issue |
-| `linear_update_state` | Move an issue to a different workflow state |
-| `linear_list_teams` / `linear_list_states` / `linear_list_labels` | Resolve names → IDs for the calls above |
-
-## Reference key (SDK / CLI)
-
-When running agents directly (local or CI), the same connector reads from the `LINEAR_API_KEY` environment variable instead of the dashboard-stored credential.
-
-## Troubleshooting
-
-**"Invalid API key"** — regenerate the key in Linear (Settings → Security & access → Personal API keys) and reconnect. Keys are revoked when you remove them from Linear.
-
-**Agent can't find a team/state** — call `linear_list_teams` / `linear_list_states` first; Linear's API keys are scoped to whatever the issuing user can see.

package/docs/integrations/notion.md

@@ -1,33 +0,0 @@
----
-sidebar_position: 9
-title: Notion Integration
----
-
-# Notion Integration
-
-Connect a Notion workspace so your agents can read and write pages and databases — for example, publishing a rich digest as Notion blocks. Notion uses **OAuth** (workspace install).
-
-## How It Works
-
-You authorize Zibby against a Notion workspace via OAuth. Notion returns a long-lived bearer token (no refresh, no expiry) scoped to the pages and databases you grant. Zibby stores it encrypted with the workspace metadata. The report renderer then publishes structured digests as native Notion blocks.
-
-## Connect Notion
-
-1. In the Zibby dashboard, go to **Settings → Integrations** and click **Connect** next to Notion
-2. You're redirected to Notion to authorize Zibby
-3. Select which pages/databases Zibby may access
-4. You're redirected back to Zibby — the card shows the connected workspace
-
-## What Agents Can Do
-
-Agents can render a `report` object straight to Notion blocks (`reportToNotionBlocks`) and publish it to a connected page or database — the same digest you can route to Slack or Lark. The `notify-notion` template is the shipped example.
-
-## Reference key (SDK / CLI)
-
-When running agents directly, the connector reads `NOTION_API_KEY` from the environment (a Notion internal-integration token works for the SDK path).
-
-## Troubleshooting
-
-**Agent can't see a page** — Notion access is page-scoped. Re-run the OAuth flow and grant the specific page/database, or share it with the integration from Notion's UI.
-
-**Write fails** — confirm the granted pages include write access; read-only grants can't create blocks.

package/docs/integrations/plane.md

@@ -1,46 +0,0 @@
----
-sidebar_position: 4
-title: Plane Integration
----
-
-# Plane Integration
-
-Connect [Plane](https://plane.so) — the open-source project-management tool — so your agents can read and write projects, work items, cycles, modules, and comments. Plane uses an **API key**, not OAuth.
-
-## How It Works
-
-You provide three values: an API key, a workspace slug, and (optionally) a base URL. Zibby validates them (by listing the workspace's projects) before storing, then the `plane` skill talks to Plane's official MCP server.
-
-## Connect Plane
-
-1. In Plane, go to **Workspace Settings → API tokens** and create a personal API token (form `plane_api_...`)
-2. Note your **workspace slug** — it's the segment in your Plane URL (`app.plane.so/<workspace-slug>/...`)
-3. In the Zibby dashboard, go to **Settings → Integrations** and click **Connect Plane**
-4. Paste the API key and workspace slug
-5. **Base URL** — leave blank for Plane Cloud (`https://api.plane.so`). For self-hosted or Zibby-hosted Plane, set it to your instance's API base.
-
-Zibby lists your workspace's projects to confirm the credentials work before saving.
-
-| Field | Required | Notes |
-|---|---|---|
-| API key | Yes | From Workspace Settings → API tokens |
-| Workspace slug | Yes | The `<slug>` in your Plane URL |
-| Base URL | No | Defaults to `https://api.plane.so` (Plane Cloud). Set for self-hosted. |
-
-## What Agents Can Do
-
-Nodes that attach the [`plane` skill](../skills/index.md) get tools for projects, work items, cycles, modules, epics, and comments, backed by Plane's official MCP server.
-
-## Reference keys (SDK / CLI)
-
-When running agents directly, the connector reads `PLANE_API_KEY`, `PLANE_WORKSPACE_SLUG`, and `PLANE_BASE_URL` from the environment.
-
-## Pairs well with hosted Plane
-
-Plane is also in the [Managed Apps catalog](../apps/index.md) — you can host a Plane instance on Zibby and point this connector at it via the **Base URL** field.
-
-## Troubleshooting
-
-**"Workspace not found"** — double-check the workspace slug matches the segment in your Plane URL exactly.
-
-**Self-hosted instance rejects the token** — confirm the **Base URL** points at the API base of your instance, not the web UI URL.

package/docs/integrations/sentry.md

@@ -1,42 +0,0 @@
----
-sidebar_position: 6
-title: Sentry Integration
----
-
-# Sentry Integration
-
-Connect a Sentry organization so your agents can list projects, list issues, and fetch issue detail — read-only. Sentry uses **OAuth 2.0 with PKCE**.
-
-## How It Works
-
-You authorize Zibby against your Sentry organization via OAuth (PKCE — no client secret). Once connected, the `sentry` skill exposes read-only Sentry tools to any node that declares it. This powers the [Sentry triage](../recipes/sentry-triage.md) agent.
-
-## Connect Sentry
-
-1. In the Zibby dashboard, go to **Settings → Integrations** and click **Connect Sentry**
-2. You're redirected to Sentry to authorize Zibby
-3. Pick the organization to grant access to
-4. You're redirected back to Zibby
-
-## What Agents Can Do
-
-Nodes that attach the [`sentry` skill](../skills/sentry.md) get read-only tools:
-
-| Tool | What it does |
-|---|---|
-| `sentry_list_projects` | List projects in the connected organization |
-| `sentry_list_issues` | List issues (supports Sentry search syntax, sort, limit) |
-| `sentry_get_issue` | Detailed info for one issue by ID |
-
-Access is read-only by design — the triage agent reads issues and routes them via Slack/Lark rather than mutating Sentry.
-
-## See also
-
-- [Sentry skill reference](../skills/sentry.md) — full tool surface
-- [Sentry triage recipe](../recipes/sentry-triage.md) — the agent that consumes this connector
-
-## Troubleshooting
-
-**"Reconnect Sentry"** — the OAuth grant was revoked or expired. Go to Settings → Integrations and reconnect.
-
-**No issues returned** — check the project filter and that the org you authorized actually owns the project.

package/docs/integrations/slack.md

@@ -1,33 +0,0 @@
----
-sidebar_position: 7
-title: Slack Integration
----
-
-# Slack Integration
-
-Connect a Slack workspace so your agents can post messages, reply in threads, react, read history, and resolve users. Slack uses **OAuth (V2)** — one click, no token pasting.
-
-## How It Works
-
-You authorize the Zibby Slack app against your workspace. Slack returns a bot token (`xoxb-...`) that Zibby stores encrypted, along with the team ID/name. The `slack` skill then exposes Slack's API to any node that declares it.
-
-## Connect Slack
-
-1. In the Zibby dashboard, open a project → **Project Settings**, expand the **Chat integrations** card, and click **Connect** on the **Slack** row
-2. You're redirected to Slack to authorize the Zibby app and pick a workspace
-3. Approve the requested scopes
-4. You're redirected back to Project Settings — the row shows the connected team name
-
-## What Agents Can Do
-
-Nodes that attach the [`slack` skill](../skills/slack.md) get tools to list channels, post and reply, react, read channel/thread history, and look up users (by email, search, usergroups). This powers routing in recipes like [Sentry triage](../recipes/sentry-triage.md), where the agent resolves an author email to a Slack user and DMs them.
-
-## Reference (SDK / CLI)
-
-When running agents directly, the connector reads the bot token and team ID from the environment.
-
-## Troubleshooting
-
-**Message not delivered** — the bot must be invited to private channels before it can post there.
-
-**User lookup returns nothing** — `slack_get_users` excludes bots and deactivated accounts; confirm the user is active in the workspace.

package/docs/intro.md

@@ -1,86 +0,0 @@
----
-slug: /
-sidebar_position: 1
-title: Introduction
-pagination_next: get-started/install
----
-
-# Zibby
-
-**The cloud platform for AI agents — built on Claude Code, Cursor, Codex, and Gemini.** Compose real coding-agent CLIs into structured agents with Zod-validated handoff between nodes, then deploy them to the cloud. Vendor-neutral. JavaScript-first.
-
-> An **Agent** is a deployed automation — a graph of coding-agent CLI calls with Zod-typed handoff between nodes. Build and ship one with the `zibby agent` CLI.
-
-```
-            ┌──────────┐    ┌──────────┐    ┌──────────┐
-trigger →   │  plan    │ →  │ implement│ →  │  verify  │ → result
-            │ (claude) │    │ (cursor) │    │ (codex)  │
-            └──────────┘    └──────────┘    └──────────┘
-                 │               │               │
-              Zod out         Zod out         Zod out
-```
-
-```js
-graph
-  .addNode('plan',      { prompt, outputSchema: Plan,   agent: 'claude' })
-  .addNode('implement', { prompt, outputSchema: Diff,   agent: 'cursor' })
-  .addNode('verify',    { prompt, outputSchema: Result, agent: 'codex'  });
-```
-
-## Try it now
-
-Get started in seconds:
-
-```bash
-npm install -g @zibby/cli
-zibby init                       # bare init (config + creds; no template)
-zibby agent new my-agent         # scaffold a custom agent
-zibby agent run my-agent         # run locally (one-shot)
-
-zibby login
-zibby agent deploy my-agent      # ship to cloud
-zibby agent trigger <uuid>       # fire it
-zibby agent logs <uuid> -t       # tail logs
-```
-
-Want a ready-made agent instead of a blank slate? Browse the [Agent Marketplace](./recipes/) and use `-t`:
-
-```bash
-zibby init -t browser-test-automation     # scaffold a marketplace template at init time
-zibby template list                        # see what's available
-zibby template add <name>                  # add a template later (overwrites = doubles as update)
-```
-
-→ Next: [Install](./get-started/install)
-
-## What you get
-
-- **Multi-vendor** — mix Claude Code + Codex + Cursor + Gemini in one agent. Anthropic will never help you orchestrate Codex; multi-vendor neutrality is structural.
-- **Schema-enforced handoff** — Zod validates every node's output before the next runs. No prompt-stuffing.
-- **Run anywhere** — local with hot reload, or cloud with Heroku-style bundles (~3s cold start).
-- **Session replay** — every run lands as on-disk JSONL + artifacts. Re-run any node via `--session <id> --node <name>`.
-- **Cloud-native** — SSE log streaming, dedicated egress IPs for firewalled GitLab / GitHub Enterprise / Salesforce.
-- **Hosted apps too** — [Managed Apps](./apps/) host open-source tools (Grafana, Open WebUI, Docmost, Uptime Kuma, Authentik, …) from a curated catalog, OR deploy anything else via natural-language [goal-mode](./apps/goal-mode). Every instance ships with an autonomous agent-ops sidecar that handles health checks, self-healing, and upgrades.
-- **Drive it from your AI agent** — [`@zibby/mcp-cli`](./packages/mcp-cli) exposes deploy / trigger / logs / debug as MCP tools. Add one snippet to Claude Code, Cursor, Codex, or Gemini and they call Zibby directly from chat. See [Use from your AI agent](./get-started/use-from-agents).
-
-## Two product surfaces
-
-| | **Agents** | **Apps** |
-|---|---|---|
-| Lifetime | Per trigger (seconds-minutes) | Long-lived |
-| Surface | Graph of agent CLI calls | A whole open-source application |
-| Billing | Per execution | Per minute, while running |
-| Best for | "When ticket lands, classify it" | "Host Grafana for the team" |
-
-An **Agent** is a deployed automation. An **App** is a hosted open-source application. Pick by how long the thing needs to run — see [Apps overview](./apps/) for the decision tree.
-
-## How it compares
-
-| | Zibby | Claude Code Agent Teams | Devin | Mastra / LangGraph / CrewAI |
-|---|---|---|---|---|
-| Wraps real coding-agent CLIs | ✅ Claude + Codex + Cursor + Gemini | ❌ Claude only | ❌ proprietary agent | ❌ wraps LLM APIs |
-| Multi-vendor | ✅ | ❌ | ❌ | N/A |
-| Cloud-hosted | ✅ | ❌ local IDE | ✅ | varies |
-| Schema-enforced handoff | ✅ Zod | ❌ free-form | proprietary | ✅ |
-| Session replay | ✅ on-disk JSONL | ❌ | partial | partial |
-| Static egress IP | ✅ addon | ❌ | ❌ | ❌ |

package/docs/legacy/test-automation.md

@@ -1,111 +0,0 @@
----
-sidebar_position: 1
-title: Test automation (legacy)
----
-
-# Test automation (legacy)
-
-> **Deprecated landing page.** The `zibby test` flow predates the workflow engine. The current canonical pages are [`zibby test` recipe](/recipes/test), [Test memory](/tests/memory), and [CLI Reference → test](/cli-reference#test). This page is kept for users following old links; everything below still works, but **new users should start with [Get Started](/get-started/install)**.
-
-> Notably, `zibby init --mem` referenced below is now `zibby init` (memory is set up by default) plus optionally `-t browser-test-automation` to scaffold the test recipe. The current commands are documented in the [CLI Reference](/cli-reference#init).
-
-Drive a real browser from a plain-text spec, get a Playwright script back.
-
-## Prerequisites
-
-- Node.js 18 or later
-- [Cursor](https://cursor.com) IDE installed (for `--agent cursor`), **or** an Anthropic API key (for `--agent claude`), **or** OpenAI API key + Codex CLI (for `--agent codex`)
-
-## Option A: Zero Setup (npx)
-
-No install needed — run directly:
-
-```bash
-echo "Go to example.com and verify the page title says Example Domain" > test.txt
-npx @zibby/cli run test.txt --agent cursor
-```
-
-## Option B: Global Install
-
-```bash
-npm install -g @zibby/cli
-```
-
-### 1. Create a test spec
-
-Create a plain-text file with your test instructions:
-
-```text title="test-specs/login.txt"
-1. Navigate to https://myapp.com/login
-2. Enter email: test@example.com
-3. Enter password: TestPass123
-4. Click the Sign In button
-5. Verify the dashboard page loads
-6. Verify the user's name appears in the header
-```
-
-### 2. Run it
-
-```bash
-zibby test test-specs/login.txt --agent cursor
-```
-
-You'll see:
-- A browser window open
-- The AI agent navigate and interact with your app
-- A generated Playwright script saved to `tests/`
-
-### 3. Run the generated test
-
-```bash
-npx playwright test tests/login.spec.js
-```
-
-## Customizing Your Setup (Optional)
-
-If you want to customize the agent, config, or nodes:
-
-```bash
-zibby init --agent cursor
-```
-
-This scaffolds:
-
-```
-.zibby.config.js          # Project configuration (ESM)
-.zibby/
-├── graph.js               # Workflow definition (customizable)
-├── nodes/                 # Node implementations
-│   ├── execute-live.js
-│   ├── generate-script.js
-│   └── preflight.js
-└── result-handler.js      # Post-execution hooks
-```
-
-Without `zibby init`, the CLI uses the built-in default agent automatically.
-
-## Environment Variables
-
-| Variable | When needed |
-|---|---|
-| `CURSOR_API_KEY` | CI/CD with `--agent cursor` (locally uses Cursor IDE credentials) |
-| `ANTHROPIC_API_KEY` | Using `--agent claude` |
-| `OPENAI_API_KEY` | Using `--agent codex` |
-| `ZIBBY_API_KEY` | Cloud sync (`--sync` flag) |
-
-For local development, add these to a `.env` file in your project root.
-
-## Cloud Sync (Optional)
-
-To upload results to the [Zibby dashboard](https://zibby.app):
-
-1. Create an account at [zibby.app](https://zibby.app)
-2. Get your API key from **Project Settings**
-3. Add to `.env`: `ZIBBY_API_KEY=zby_your_key_here`
-4. Login: `zibby login`
-5. Run with sync: `zibby test test-specs/login.txt --sync`
-
-## Next Steps
-
-- [Install](/get-started/install) — detailed setup and configuration
-- [CLI Reference](/cli-reference) — every command and flag