starred/windmill
1
0
Fork 0
mirror of https://github.com/windmill-labs/windmill.git synced 2026-08-18 16:02:10 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(skills): agent runs all CLI commands, gated on intent not on user typing them

Browse Source 
Extends #9467's safe-vs-destructive model: the agent runs consequential commands (sync push, generate-metadata) itself too, gated on explicit user intent rather than handed to the user to type. The explicit-intent rule is the safeguard; an approval prompt is treated as a possible backstop, not assumed (auto-approve/headless runs have none).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
hugocasa
2026-06-11 15:04:55 +02:00
parent 10d0b950c2
commit 9225e1759b
6 changed files with 42 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files
cli/src/guidance/core.ts
+9
View File
@@ -107,6 +107,15 @@ You MUST use the \`preview\` skill any time the user wants to see/open/visualize
You MUST use the \`cli-commands\` skill to use the CLI.
## You run the commands, not the user
Run \`wmill\` commands yourself — don't hand a command to the user to type. The gate in this guidance is **intent** (what the user asked for), not **who runs it**:
- Read-only / local commands (previews, \`list\`, \`get\`, \`sync pull --dry-run\`) — just run them.
- Consequential commands (deploys via \`wmill sync push\`, lock/metadata regeneration) — you run these too, but only when the user's intent calls for it: an explicit deploy/publish/push request for \`sync push\`, not a "run"/"try"/"test". **That explicit-intent rule is the safeguard** — don't off-load the command to the user to type. (Your harness may *also* gate command execution behind an approval prompt, but don't rely on one being there: in auto-approve / headless runs there isn't, so the intent rule is what protects against an unwanted deploy.)
The exception is a long-running server like \`wmill app dev\`: launch it via the \`preview\` skill rather than blocking on it.
## Running and previewing local changes
Local previews exist for every entity type and don't deploy:
cli/src/guidance/skills.gen.ts
+11 -13
View File
@@ -4504,7 +4504,7 @@ Once the flow has real content, **offer** to open the visual preview as a one-se
## CLI Commands — running, previewing, deploying
After writing, act on the user's intent instead of just listing commands. Run the safe, non-deploying command yourself when it fits (\`wmill flow preview\` — see "After writing — offer to run, don't wait passively" below); only *name* the commands that deploy or rewrite files (\`wmill sync push\`, \`wmill generate-metadata\`) so the user can approve them. The options:
After writing, act on the user's intent instead of just listing commands. Run the safe, non-deploying command yourself when it fits (\`wmill flow preview\` — see "After writing — offer to run, don't wait passively" below). You run the deploy/file-rewriting commands (\`wmill sync push\`, \`wmill generate-metadata\`) yourself too — but only when the user's intent calls for it (an explicit deploy request for \`sync push\`). That explicit-intent rule is the safeguard; don't hand the command to the user to type. The options:
- \`wmill flow preview <flow_path>\` — **default when iterating on a local flow.** Runs the local \`flow.yaml\` against local inline scripts without deploying. Add \`--remote\` to use deployed workspace scripts for PathScript steps instead of local files. Add \`--step <step_id>\` to run only one module in isolation (see "Single-step vs whole-flow preview" below).
- \`wmill flow run <path>\` — runs the flow **already deployed** in the workspace. Use only when the user explicitly wants to test the deployed version, not local edits.
@@ -4537,7 +4537,7 @@ If the user hasn't already told you to run/test the flow, offer it as a one-sent
If the user already asked to test/run/try the flow in their original request, skip the offer and just execute \`wmill flow preview <path> -d '<args>'\` directly — pick plausible args from the flow's input schema.
\`wmill flow preview\` is safe to run yourself (it does not deploy). \`wmill sync push\` and \`wmill generate-metadata\` modify workspace state or local files — only run these when the user explicitly asks; otherwise tell them which to run.
\`wmill flow preview\` is safe to run yourself (it does not deploy). You run \`wmill sync push\` and \`wmill generate-metadata\` yourself too — they modify workspace state or local files, so run them only when the user's intent calls for it (an explicit deploy request for \`sync push\`). That explicit-intent rule is the safeguard; don't hand these to the user to run.
### Visual preview
@@ -5061,18 +5061,16 @@ data:
## CLI Commands
Two commands you run yourself, not the user:
- \`wmill app new\` — run it with flags, per the "Creating a Raw App" section above.
- \`wmill generate-metadata\` — generates local lock files; offer it and run it on consent, per "After creating a runnable" above (it writes local lock files, not a deploy).
You run these yourself — don't hand them to the user to type. What differs is the gate: run the consequential ones (\`sync push\`, \`sync pull\`) only when the user's intent calls for it — that explicit-intent rule is the safeguard, not an assumed approval prompt.
For the rest, tell the user which command fits their intent and let them run it — these deploy to the workspace, overwrite local files, or launch a long-running server, so the user should consent each time:
| Command | Description |
|---------|-------------|
| \`wmill app dev\` | Start dev server with live reload (see the \`preview\` skill for the full open-the-app-in-the-IDE-pane procedure). |
| \`wmill app generate-agents\` | Refresh AGENTS.md and DATATABLES.md |
| \`wmill sync push\` | Deploy app to Windmill |
| \`wmill sync pull\` | Pull latest from Windmill |
| Command | When you run it |
|---------|-----------------|
| \`wmill app new\` | Yourself, with flags, per "Creating a Raw App" above. |
| \`wmill generate-metadata\` | Offer it and run it on consent, per "After creating a runnable" above (local lock files, not a deploy). |
| \`wmill app generate-agents\` | When the app's AGENTS.md / DATATABLES.md need refreshing. |
| \`wmill sync pull\` | Pulls from Windmill; overwrites local files, so confirm intent first (\`--dry-run\` to preview). |
| \`wmill sync push\` | Deploys to Windmill; run it only when the user explicitly asks to deploy/publish/push. |
| \`wmill app dev\` | Long-running dev server — launch it via the \`preview\` skill rather than blocking on it. |
system_prompts/auto-generated/skills/raw-app/SKILL.md
+9 -11
View File
@@ -217,18 +217,16 @@ data:
## CLI Commands
Two commands you run yourself, not the user:
- `wmill app new` — run it with flags, per the "Creating a Raw App" section above.
- `wmill generate-metadata` — generates local lock files; offer it and run it on consent, per "After creating a runnable" above (it writes local lock files, not a deploy).
You run these yourself — don't hand them to the user to type. What differs is the gate: run the consequential ones (`sync push`, `sync pull`) only when the user's intent calls for it — that explicit-intent rule is the safeguard, not an assumed approval prompt.
For the rest, tell the user which command fits their intent and let them run it — these deploy to the workspace, overwrite local files, or launch a long-running server, so the user should consent each time:
| Command | Description |
|---------|-------------|
| `wmill app dev` | Start dev server with live reload (see the `preview` skill for the full open-the-app-in-the-IDE-pane procedure). |
| `wmill app generate-agents` | Refresh AGENTS.md and DATATABLES.md |
| `wmill sync push` | Deploy app to Windmill |
| `wmill sync pull` | Pull latest from Windmill |
| Command | When you run it |
|---------|-----------------|
| `wmill app new` | Yourself, with flags, per "Creating a Raw App" above. |
| `wmill generate-metadata` | Offer it and run it on consent, per "After creating a runnable" above (local lock files, not a deploy). |
| `wmill app generate-agents` | When the app's AGENTS.md / DATATABLES.md need refreshing. |
| `wmill sync pull` | Pulls from Windmill; overwrites local files, so confirm intent first (`--dry-run` to preview). |
| `wmill sync push` | Deploys to Windmill; run it only when the user explicitly asks to deploy/publish/push. |
| `wmill app dev` | Long-running dev server — launch it via the `preview` skill rather than blocking on it. |
system_prompts/auto-generated/skills/write-flow/SKILL.md
+2 -2
View File
@@ -44,7 +44,7 @@ Once the flow has real content, **offer** to open the visual preview as a one-se
## CLI Commands — running, previewing, deploying
After writing, act on the user's intent instead of just listing commands. Run the safe, non-deploying command yourself when it fits (`wmill flow preview` — see "After writing — offer to run, don't wait passively" below); only *name* the commands that deploy or rewrite files (`wmill sync push`, `wmill generate-metadata`) so the user can approve them. The options:
After writing, act on the user's intent instead of just listing commands. Run the safe, non-deploying command yourself when it fits (`wmill flow preview` — see "After writing — offer to run, don't wait passively" below). You run the deploy/file-rewriting commands (`wmill sync push`, `wmill generate-metadata`) yourself too — but only when the user's intent calls for it (an explicit deploy request for `sync push`). That explicit-intent rule is the safeguard; don't hand the command to the user to type. The options:
- `wmill flow preview <flow_path>` — **default when iterating on a local flow.** Runs the local `flow.yaml` against local inline scripts without deploying. Add `--remote` to use deployed workspace scripts for PathScript steps instead of local files. Add `--step <step_id>` to run only one module in isolation (see "Single-step vs whole-flow preview" below).
- `wmill flow run <path>` — runs the flow **already deployed** in the workspace. Use only when the user explicitly wants to test the deployed version, not local edits.
@@ -77,7 +77,7 @@ If the user hasn't already told you to run/test the flow, offer it as a one-sent
If the user already asked to test/run/try the flow in their original request, skip the offer and just execute `wmill flow preview <path> -d '<args>'` directly — pick plausible args from the flow's input schema.
`wmill flow preview` is safe to run yourself (it does not deploy). `wmill sync push` and `wmill generate-metadata` modify workspace state or local files — only run these when the user explicitly asks; otherwise tell them which to run.
`wmill flow preview` is safe to run yourself (it does not deploy). You run `wmill sync push` and `wmill generate-metadata` yourself too — they modify workspace state or local files, so run them only when the user's intent calls for it (an explicit deploy request for `sync push`). That explicit-intent rule is the safeguard; don't hand these to the user to run.
### Visual preview
system_prompts/base/flow-cli.md
+2 -2
View File
@@ -39,7 +39,7 @@ Once the flow has real content, **offer** to open the visual preview as a one-se
## CLI Commands — running, previewing, deploying
After writing, act on the user's intent instead of just listing commands. Run the safe, non-deploying command yourself when it fits (`wmill flow preview` — see "After writing — offer to run, don't wait passively" below); only *name* the commands that deploy or rewrite files (`wmill sync push`, `wmill generate-metadata`) so the user can approve them. The options:
After writing, act on the user's intent instead of just listing commands. Run the safe, non-deploying command yourself when it fits (`wmill flow preview` — see "After writing — offer to run, don't wait passively" below). You run the deploy/file-rewriting commands (`wmill sync push`, `wmill generate-metadata`) yourself too — but only when the user's intent calls for it (an explicit deploy request for `sync push`). That explicit-intent rule is the safeguard; don't hand the command to the user to type. The options:
- `wmill flow preview <flow_path>` — **default when iterating on a local flow.** Runs the local `flow.yaml` against local inline scripts without deploying. Add `--remote` to use deployed workspace scripts for PathScript steps instead of local files. Add `--step <step_id>` to run only one module in isolation (see "Single-step vs whole-flow preview" below).
- `wmill flow run <path>` — runs the flow **already deployed** in the workspace. Use only when the user explicitly wants to test the deployed version, not local edits.
@@ -72,7 +72,7 @@ If the user hasn't already told you to run/test the flow, offer it as a one-sent
If the user already asked to test/run/try the flow in their original request, skip the offer and just execute `wmill flow preview <path> -d '<args>'` directly — pick plausible args from the flow's input schema.
`wmill flow preview` is safe to run yourself (it does not deploy). `wmill sync push` and `wmill generate-metadata` modify workspace state or local files — only run these when the user explicitly asks; otherwise tell them which to run.
`wmill flow preview` is safe to run yourself (it does not deploy). You run `wmill sync push` and `wmill generate-metadata` yourself too — they modify workspace state or local files, so run them only when the user's intent calls for it (an explicit deploy request for `sync push`). That explicit-intent rule is the safeguard; don't hand these to the user to run.
### Visual preview
system_prompts/base/raw-app-cli.md
+9 -11
View File
@@ -212,16 +212,14 @@ data:
## CLI Commands
Two commands you run yourself, not the user:
- `wmill app new` — run it with flags, per the "Creating a Raw App" section above.
- `wmill generate-metadata` — generates local lock files; offer it and run it on consent, per "After creating a runnable" above (it writes local lock files, not a deploy).
You run these yourself — don't hand them to the user to type. What differs is the gate: run the consequential ones (`sync push`, `sync pull`) only when the user's intent calls for it — that explicit-intent rule is the safeguard, not an assumed approval prompt.
For the rest, tell the user which command fits their intent and let them run it — these deploy to the workspace, overwrite local files, or launch a long-running server, so the user should consent each time:
| Command | Description |
|---------|-------------|
| `wmill app dev` | Start dev server with live reload (see the `preview` skill for the full open-the-app-in-the-IDE-pane procedure). |
| `wmill app generate-agents` | Refresh AGENTS.md and DATATABLES.md |
| `wmill sync push` | Deploy app to Windmill |
| `wmill sync pull` | Pull latest from Windmill |
| Command | When you run it |
|---------|-----------------|
| `wmill app new` | Yourself, with flags, per "Creating a Raw App" above. |
| `wmill generate-metadata` | Offer it and run it on consent, per "After creating a runnable" above (local lock files, not a deploy). |
| `wmill app generate-agents` | When the app's AGENTS.md / DATATABLES.md need refreshing. |
| `wmill sync pull` | Pulls from Windmill; overwrites local files, so confirm intent first (`--dry-run` to preview). |
| `wmill sync push` | Deploys to Windmill; run it only when the user explicitly asks to deploy/publish/push. |
| `wmill app dev` | Long-running dev server — launch it via the `preview` skill rather than blocking on it. |