* docs(cli): clarify workspace fork naming and parent-workspace context Expand `wmill workspace fork`'s help and interactive prompts so the two positional arguments are self-explanatory: - Command description now explains that the fork is created from the currently active (parent) workspace, that `workspace_name` is a friendly display name that may contain spaces (quote it), and that `workspace_id` is a bare slug auto-prefixed with `wm-fork-` which also determines the git branch name. - Interactive name/id prompts reworded to match. Regenerated system_prompts CLI guidance to reflect the new description. Fixes WIN-2148 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat(cli): default fork name to "<parent>'s fork", make it optional The fork's display name is no longer effectively required — it now defaults to "<parent workspace name>'s fork" (fetched via get_workspace_name, falling back to the local profile name / id) and stays fully overridable via the positional argument or interactive prompt. To produce this default, `setClient` and the parent-name lookup are moved ahead of the name/id resolution. The id default is decoupled from the possessive display name: when auto-naming, the id/branch slug is derived from "<parent>-fork" (e.g. wm-fork-acme-fork) rather than the awkward "<parent>-s-fork". Branch-rename forks keep their branch-derived id. Regenerated system_prompts CLI guidance. Fixes WIN-2148 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(cli): fix workspace fork help — parent is branch-resolved, not active profile Addresses the codex/pi review: the fork help said the parent is the "currently active" workspace and told users to `wmill workspace switch`, but createWorkspaceFork resolves the parent from the current git branch's wmill.yaml mapping (tryResolveBranchWorkspace) and ignores the active profile. Reword to describe the actual branch-based resolution. Regenerated system_prompts CLI guidance. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(cli): note branch-derived fork id default in rename workflows Addresses the codex review: the `[workspace_id]` help and the interactive prompt said the default id is derived from the name, but rename workflows (non-base branch / --from-branch) keep the branch-derived default (`branchDefaultId ?? branchToForkId(idBasis)`) to keep the id/branch aligned with the branch being converted. Document that special case rather than changing the intentional behavior. Regenerated system_prompts CLI guidance. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(cli): cap auto fork name at 50 chars for long parent names Addresses the codex review: the "<parent>'s fork" default appended "'s fork" to a parent name that can itself be up to 50 chars (varchar(50)), so a parent name over 43 chars produced a default exceeding the limit and tripped the effectiveName.length > 50 guard — failing `wmill workspace fork --yes` (or accepting the interactive default) for a valid parent. Truncate the parent portion so the generated default stays within 50. Verified end-to-end: a 48-char parent name now yields a 49-char default ("... Team's fork") and the fork is created successfully. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Windmill CLI
A simple CLI allowing interactions with windmill from the command line.

You can find more information in Windmill Docs
Installation
Install the wmill CLI tool using npm install -g windmill-cli.
Update to the latest version using wmill upgrade.
Workspaces
To get started run wmill workspace add or use the instructions from the
workspace settings.
Running Flows & Scripts
Run a script or flow using wmill flow/script run u/username/path/to/script and
pass any inputs using --data + Inputs specified as a JSON string or a file
using @ <filename> or stdin using @-.
Curl-style syntax using -d @- for stdin or -d @<filename> is also supported.
Flow Steps and Logs will be streamed during execution automatically.
Pushing Resources, Scripts & More
The CLI can push specifications to a windmill instance. See the examples/ folder for formats.
Switch to a different workspace
wmill workspace switch <workspace_name>
Sync a workspace
Pull
wmill sync pull
Push
wmill sync push
We recommend using the --yaml option to use yaml instead of json as the encoding format. Yaml will be made the default soon.
Pushing individual files
You can push individual resources using
wmill <type> push <file_name> \<remote_name\>. This does not require a special
folder layout or file name, as this is given at runtime.
Listing
All commands support listing by just not providing a subcommand, ie
wmill script will result in a list of scripts. Some allow additional options,
learn about this by specifying --help.
User Management
You can add & remove users via wmill user add/remove, and list them using
wmill user
Pulling
You can pull the entire workspace using wmill pull
Completion
The CLI comes with completions out of the box via wmill completions <shell>.
(Via cliffy)
Bash
To enable bash completions add the following line to your ~/.bashrc:
source <(wmill completions bash)
Fish
To enable fish completions add the following line to your
~/.config/fish/config.fish:
source (wmill completions fish | psub)
Zsh
To enable zsh completions add the following line to your ~/.zshrc:
source <(wmill completions zsh)
Development
AI Guidance Variants
wmill init can now materialize alternate AI guidance bundles without changing
the generated defaults in the repo, but this is exposed as internal env-var
overrides rather than public CLI flags.
Examples:
WMILL_INIT_AI_SKILLS_SOURCE=/path/to/custom/skills wmill init --use-default
WMILL_INIT_AI_SKILLS_SOURCE=/path/to/custom/skills WMILL_INIT_AI_AGENTS_SOURCE=/path/to/AGENTS.md wmill init --use-default
WMILL_INIT_AI_SKILLS_SOURCE=/path/to/custom/skills WMILL_INIT_AI_CLAUDE_SOURCE=/path/to/CLAUDE.md wmill init --use-default
This is the same guidance-writing path used by the benchmark CLI under
ai_evals/, so the benchmark harness and wmill init now generate the same
project guidance shape:
AGENTS.mdCLAUDE.md.agents/skills/*.claude/skills/*
Testing with a local windmill-yaml-validator
To test local changes to the validator before publishing, use npm link:
# In windmill-yaml-validator/
npm run build
npm link
# In cli/
npm link windmill-yaml-validator
Running Tests
Prerequisites:
- PostgreSQL running locally (default:
postgres://postgres:changeme@localhost:5432) - Rust toolchain installed
Run tests locally (full features):
bun test test/
Run tests in CI mode (minimal features, skips EE tests):
CI_MINIMAL_FEATURES=true bun test test/
| Variable | Description |
|---|---|
CI_MINIMAL_FEATURES |
Set to true to skip EE-dependent tests |
DATABASE_URL |
PostgreSQL connection string |
EE_LICENSE_KEY |
Enterprise license key for EE features |
