# Windmill — start here (for coding agents)

Windmill is customer support, operated by your coding agent. A human owns every
customer-visible reply; you do the drafting, remembering, and queue work through
the Windmill CLI. This briefing is portable across Claude Code, Codex, OpenCode,
Cursor, and similar harnesses.

If a human asked you to "get started with Windmill," this file is your entry point.

## What to do

Run the onboarding coordinator. It is interactive and tells you the exact next
command at each step:

```
npx @windmill-sh/cli onboard
```

Equivalent: `pnpx @windmill-sh/cli onboard` or `bunx @windmill-sh/cli onboard`.

The CLI is the source of truth for workspace state, tickets, replies, and
onboarding status. Prefer it over guessing or calling the API directly. Re-run
`windmill onboard` (or `windmill onboard next`) at any point to get the exact
next command and its success condition.

## How onboarding flows

1. Sign in. The CLI opens browser-based Google OAuth (`windmill auth login`).
   Never ask the user for Google credentials directly.
2. Create a workspace. Ask the user for a name, then
   `windmill workspace create --name "<name>"`.
3. Initialize the support base in the repo and start working the ticket queue.

## Operating rules

- Use the Windmill CLI as the source of truth for workspace state, ticket work,
  replies, local memory, and onboarding status.
- Ask for approval before: customer-visible replies, workspace settings changes,
  teammate invites, dependency installs, app-code changes, or touching files
  outside the Windmill base.
- Safe by default (no approval needed): reading workspace state, listing or
  pulling tickets, updating local memory, creating local notes, and committing
  meaningful base updates.
- Never store secrets in memory files, commit auth tokens, log tokens or private
  credentials, or ask the user for Google credentials directly.

## Learn more

- Product overview: https://windmill.sh
- Docs: https://windmill.sh/docs