Skip to content
cccskills
FreePublished on GitHub

workspace-settings

Read and update Windmill workspace settings through the CLI or a synced settings.yaml file. The skill explains partial updates, dry runs, access limits, and how to preserve secrets while applying changes.

OriginalShow the original description

MUST use when reading or changing workspace settings, or the settings.yaml file `wmill sync` keeps.

windmill-labs/windmill18,281 stars(GitHub 18,281 + cccskills 0)
Works withSlackPostgreSQL

Run score Not tested

See how to install

Good for

  • Review the current workspace settings
  • Apply selected settings from a YAML or JSON file
  • Sync settings.yaml with a Windmill workspace

Files included (1)

  • SKILL.md7.1 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Workspace settings

Everything an admin sets on the Workspace settings page is one document: a mapping of top-level keys, the same layout as the settings.yaml file wmill sync keeps. Only a workspace admin can read or change it.

Applying a document

  • A partial document changes only the keys it states; every key it omits is left as it is.
  • Each key is replaced whole, so read its current value and send it back edited: a nested object given with one field replaces the stored object with that one field.
  • A key set to null clears that setting; an on/off switch cleared this way reads as false.
  • Each setting is written through the same path the settings page uses, with the same validation and audit log. The writes are not one transaction: when one fails the apply stops, and the error says what was already written.
  • A dry run reports the changes, as before / after per key, without writing anything.
  • name is never applied: rename a workspace on the settings page. color is applied only when set to a value, so null does not clear it.
  • A key the server does not know is ignored and named in the warnings: check them, since a typo otherwise reads as "nothing to change".
  • A setting this edition does not offer (Enterprise only) is refused, by the dry run too.

Secrets

slack_oauth_client_secret is the one secret. A read shows __SENSITIVE_AND_UNCHANGED__ in place of a set secret; sending that placeholder back keeps the stored value. A value starting with $encrypted: is decrypted with the workspace key, and one encrypted with another workspace's key is left unchanged with a warning; any other value is taken as plaintext. Never write a secret you were not given: keep the placeholder.

Keys

KeyValue
auto_invite{ enabled, mode: invite | add, operator, instance_groups?, instance_groups_roles? }. The instance groups are managed only when instance_groups is stated; clearing a group removes the members it added.
error_handler / success_handler{ path, extra_args?, muted_on_cancel?, muted_on_user_path? }, path being script/<path> or flow/<path>.
error_handler_fallback_to_instance_alertsReport failures to the instance critical alert channels when no error handler is set.
webhookURL POSTed a JSON event on every change to the workspace's items.
ai_configProviders, default and completion models, custom prompts, copilot_disabled.
large_file_storageWorkspace object storage: { type, s3_resource_path | azure_blob_resource_path | gcs_resource_path, public_resource?, secondary_storage?, advanced_permissions? }.
git_sync{ repositories: [...] }, each with git_repo_resource_path, script_path and settings (include/exclude paths and types). Server-owned fields (webhook secrets, sync state, credentials) are never read nor written.
datatable{ datatables: { <name>: { database: { resource_type, resource_path } } } }, both required: resource_type: postgresql with resource_path a Postgres resource's path, or instance, or external_instance (Enterprise only), with resource_path the name of a database a superadmin set up. A fork's entry can instead be { reference: { workspace_id, datatable } }, pointing at its parent's data table; keep it as is. main is the one scripts use by default. Role permissions are datatable_permissions.
datatable_permissions{ <data table>: { default_role, roles: { <role>: [tenants] } } }: who may connect to each data table as which role. Tenants are u/<user>, g/<group>, f/<folder> or *; admin is always a role, and default_role: null means no default. A data table the value omits is no longer under roles. Only a data table on a cluster Windmill manages can be.
protection_rules{ <rule name>: { rules: [...], bypass_groups: [...], bypass_users: [...] } }, rules among DisableDirectDeployment, DisableWorkspaceForking, RestrictDeployToDeployers, RestrictAnonymousAppDeployment, RestrictPublicRunSharing, RestrictGuestAppDeployment, RequireIsolatedForks. A rule the value omits is deleted. The dev workspace lock is not listed and cannot be set here.
ducklake{ ducklakes: { <name>: { catalog, storage, ... } } }.
dbt_warehousesdbt warehouse connections.
default_appPath of the app shown as the workspace home.
default_scripts{ order?, hidden?, default_script_content? } for the script language picker.
deploy_ui{ include_path?, include_type? }: what the deploy-to-workspace UI offers.
operator_settingsWhat operators see and do: page visibility flags (runs, schedules, resources, variables, assets, audit_logs, groups, folders, workers, triggers) and write rights (manage_schedules, manage_triggers, builder_flows, builder_apps). A write right the value omits keeps its stored value.
mute_critical_alertsMute the workspace's critical alerts.
slack_team_id, slack_nameRead only: set by connecting Slack on the settings page.
slack_command_script / teams_command_scriptScript or flow handling the Slack / Teams command.
slack_oauth_client_id / slack_oauth_client_secretThe workspace's own Slack OAuth app. Clearing either removes both.
public_app_execution_limit_per_minuteRate limit for public apps, null for none.
guest_access_enabled, guest_jwt_public_key, guest_jwt_jwks_urlGuest access to public apps and the key that signs guest JWTs.
add_admins_and_developers_to_forksAdd the workspace's admins and developers to each fork.
colorWorkspace color, #rrggbb.

From the command line

wmill workspace get-settings prints the document (--encrypted for secrets encrypted with the workspace key, --json for JSON). wmill workspace apply-settings <file> applies a partial document from a YAML or JSON file: it shows the changes and asks before writing (--dry-run to only show them, -y to skip the question, --replace to clear what the file omits).

In a synced repository

With includeSettings: true in wmill.yaml, wmill sync pull writes the document to settings.yaml, secrets encrypted with the workspace key (plaintext only with plainSecrets), and wmill sync push applies it. Unlike a partial apply, a push treats the file as the whole document: a setting the file omits is cleared, except operator_settings, color, the auto-invite instance groups, and the keys ducklake, dbt_warehouses, deploy_ui, teams_command_script, public_app_execution_limit_per_minute, guest_access_enabled, guest_jwt_public_key, guest_jwt_jwks_url, error_handler_fallback_to_instance_alerts and add_admins_and_developers_to_forks, which are managed only when the file states them. datatable_permissions is pushed only with includeDatatablePermissions: true (or --include-datatable-permissions). A push ignores protection_rules: protection-rules.yaml and wmill protection-rules push sync them.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

adding-a-trigger

FreeSummary

Plan the code changes needed to add a TriggerCrud-based trigger to Windmill. The checklist covers backend, database, API, CLI, frontend, capture, and validation work so the new trigger can be managed across the product.

  • Add a Kafka, GCP, or Azure style trigger to Windmill
  • Find all product areas affected by a new trigger kind
  • Review implementation and validation steps before a trigger PR
windmill-labs/windmill18.3KUpdated Oct 26, 2026

ai-chat

FreeSummary

Improve Windmill’s AI chat by reviewing its tools, prompts, result shapes, and context usage. The guidance helps place shared instructions where chat and CLI can use them, reduce repeated token costs, and compare behavior before and after changes with A/B evaluations.

  • Edit Windmill chat tools or system prompts
  • Reduce chat context window usage
  • Benchmark a chat behavior change
windmill-labs/windmill18.3KUpdated Oct 26, 2026

ai-evals

FreeSummary

Create and run black-box benchmarks for Windmill AI generation modes such as flows, apps, scripts, CLI, and global requests. Each case exercises the production path, checks hard requirements, and uses an LLM judge to assess user-facing behavior before and after changes.

  • Adding a benchmark case for an AI mode
  • Comparing AI chat behavior before and after a change
  • Checking copilot changes with realistic requests
windmill-labs/windmill18.3KUpdated Oct 26, 2026

cli-commands

FreeSummary

Use this reference to work with Windmill resources from the command line, including scripts, flows, datatables, and workspace settings. It also covers listing jobs, inspecting details and logs, retrieving results, and rerunning or restarting executions when investigating failures.

  • Inspecting a failed job and its logs
  • Reviewing recent runs and retrieving job results
  • Managing scripts and flows from the command line
windmill-labs/windmill18.3KUpdated Oct 26, 2026

codebase-design

FreeSummary

Use this skill to shape modules with small interfaces and substantial behavior behind them. It helps you decide where a seam belongs, reduce complexity exposed to callers, and make code easier to test and maintain.

  • Designing a module interface
  • Finding places to simplify a module
  • Choosing where behavior should vary
windmill-labs/windmill18.3KUpdated Oct 26, 2026

commit

FreeSummary

Use this skill to review pending changes, select only the relevant files for staging, and create a focused Git commit. It formats the single-line message with a Conventional Commits type such as feat, fix, or docs, and checks the resulting status.

  • Committing a new feature
  • Recording a bug fix
  • Committing documentation changes
windmill-labs/windmill18.3KUpdated Oct 26, 2026

See all skills by windmill-labs

Report a problem with this skill