Workbench CLI

Use the workbench CLI instead of hand-creating .workbench, editing .gitignore manually, copying bundled skill assets by hand, or guessing at runtime API calls.

Treat this file as the thin agent-facing wrapper. The synced references and examples are the source of truth for exact behavior and syntax.

If you are reading the authored repo copy under skills/workbench-cli, the generated references/ and examples/ folders may not exist yet. In that case, use the canonical repo files under docs/cli.md, docs/workflow-authoring.md, and docs/examples/workflows/. After workbench skill install, those same materials exist inside the installed skill tree.

Working Rules

• Prefer the repo-local flow. Run the CLI from the target git repo unless the user intentionally wants --server or WB_SERVER_URL.
• For bootstrap, prefer workbench init . --template <starter> over manually creating .workbench or copying starter YAML.
• After workflow edits, run workbench validate. Use --schema-only only when the user explicitly wants structural validation without local readiness checks.
• For read-only inspection, prefer the CLI surfaces that already exist: workbench workflow list, workbench execution list, workbench execution show, workbench execution history, workbench execution trace, workbench execution transcript, and workbench execution changes.
• For execution run, execution resume, execution action run, and execution watch, ensure a persistent runtime exists with workbench start or workbench open unless the user intentionally passed an explicit server target.
• Let execution run, execution resume, and execution action run surface missing-input requirements instead of inventing separate input-discovery commands.
• Native chat is outside the CLI surface. Use the web /chat route or the runtime /api/v1/chat/* API for native chat threads.
• Do not use deleted commands such as workflow template ..., workflow inputs, execution continue, or execution action inputs.