cli-commands

Reference Windmill CLI commands for managing scripts, flows, apps, jobs, and workspace resources.

1|Updated Aug 3, 2026
One-click install
npx skills add https://github.com/vpzed-dev/smithy --skill cli-commands-vpzed-dev
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: cli-commands
Source: https://github.com/vpzed-dev/smithy/tree/main/windmill/local-dev/.agents/skills/cli-commands
Command: npx skills add https://github.com/vpzed-dev/smithy --skill cli-commands-vpzed-dev

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Working with the Windmill CLI requires knowing dozens of commands, subcommands, and flags across apps, flows, jobs, schedules, resources, and workspaces. This Skill provides the complete wmill command reference so an agent can correctly invoke the CLI, debug job failures, and inspect run history without guessing syntax. ## Core Features & Use Cases - Job debugging and inspection: Use wmill job list, job get, job logs, job result, job cancel, job rerun, and job restart to diagnose failures and inspect run history, including flow step trees and aggregated step logs. - Resource management: Push, pull, list, and run scripts, flows, apps, schedules, resources, resource types, folders, and groups against a workspace. - Local development workflows: Use wmill dev, flow preview, app dev, sync, generate-metadata, and lint to iterate locally before deploying. - Use Case: A scheduled flow failed overnight. Use wmill job list to find the failed run, wmill job logs <id> to read aggregated step logs, wmill job get <id> to inspect the step tree, then wmill job restart <id> --step <stepId> to resume from the failing step. ## Quick Start Ask the agent to list recent failed jobs and show the logs of the most recent failure using the wmill CLI.

Frequently Asked Questions about cli-commands

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug a failed Windmill job from the CLI?▼

Use `wmill job list` to find the failed job, then `wmill job logs <id>` to read its logs and `wmill job get <id>` to see details. For flows, `job get` shows the step tree with sub-job IDs, and `job logs` aggregates all step logs.

How do I rerun or restart a Windmill flow from the CLI?▼

Use `wmill job rerun <id>` to re-run a completed job with the same arguments, or `wmill job restart <id> --step <stepId>` to restart a completed flow from a specific top-level step. Both print the new job UUID on stdout.

How do I test a Windmill flow locally without deploying it?▼

Use `wmill flow preview <flow_path>` to run a local flow definition without deploying. It uses local PathScripts by default, supports `--step` to run one module in isolation, and `--remote` to use deployed workspace scripts instead.

Can I override which Windmill workspace a CLI command targets?▼

Yes, pass the global `--workspace <workspace>` flag to any command to override the default workspace. You can also use `--token` and `--base-url` together to target an instance without any stored local configuration.

What is the difference between wmill dev and wmill sync push?▼

`wmill dev` watches local files and live-reloads a preview page without deploying anything to the remote workspace. `wmill sync push` actually deploys local changes to the remote workspace, so use it only when changes are ready.