diff --git a/cli/src/guidance/core.ts b/cli/src/guidance/core.ts index 25890e1923..7dafc8e27e 100644 --- a/cli/src/guidance/core.ts +++ b/cli/src/guidance/core.ts @@ -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: diff --git a/cli/src/guidance/skills.gen.ts b/cli/src/guidance/skills.gen.ts index c1c882993e..3fd4f976ef 100644 --- a/cli/src/guidance/skills.gen.ts +++ b/cli/src/guidance/skills.gen.ts @@ -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 \` — **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 \` to run only one module in isolation (see "Single-step vs whole-flow preview" below). - \`wmill flow run \` — 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 -d ''\` 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. | diff --git a/system_prompts/auto-generated/skills/raw-app/SKILL.md b/system_prompts/auto-generated/skills/raw-app/SKILL.md index ad89af6159..73771a4de7 100644 --- a/system_prompts/auto-generated/skills/raw-app/SKILL.md +++ b/system_prompts/auto-generated/skills/raw-app/SKILL.md @@ -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. | diff --git a/system_prompts/auto-generated/skills/write-flow/SKILL.md b/system_prompts/auto-generated/skills/write-flow/SKILL.md index f71bdbf3fa..fd509bb471 100644 --- a/system_prompts/auto-generated/skills/write-flow/SKILL.md +++ b/system_prompts/auto-generated/skills/write-flow/SKILL.md @@ -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 ` — **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 ` to run only one module in isolation (see "Single-step vs whole-flow preview" below). - `wmill flow run ` — 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 -d ''` 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 diff --git a/system_prompts/base/flow-cli.md b/system_prompts/base/flow-cli.md index e2c553580f..836df52809 100644 --- a/system_prompts/base/flow-cli.md +++ b/system_prompts/base/flow-cli.md @@ -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 ` — **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 ` to run only one module in isolation (see "Single-step vs whole-flow preview" below). - `wmill flow run ` — 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 -d ''` 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 diff --git a/system_prompts/base/raw-app-cli.md b/system_prompts/base/raw-app-cli.md index 70e6d8135f..6d662dfc13 100644 --- a/system_prompts/base/raw-app-cli.md +++ b/system_prompts/base/raw-app-cli.md @@ -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. |