home / skills / windmill-labs / windmill / write-script-snowflake

write-script-snowflake skill

safe

/system_prompts/auto-generated/skills/write-script-snowflake

This skill guides you to write Snowflake queries with parameter placeholders and clear comments for naming, improving reliability and readability.

npx playbooks add skill windmill-labs/windmill --skill write-script-snowflake

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

561 B

---
name: write-script-snowflake
description: MUST use when writing Snowflake queries.
---

## CLI Commands

Place scripts in a folder. After writing, run:
- `wmill script generate-metadata` - Generate .script.yaml and .lock files
- `wmill sync push` - Deploy to Windmill

Use `wmill resource-type list --schema` to discover available resource types.

# Snowflake

Arguments use `?` placeholders.

Name the parameters by adding comments before the statement:

```sql
-- ? name1 (text)
-- ? name2 (number) = 0
SELECT * FROM users WHERE name = ? AND age > ?;
```

Overview

This skill helps you write Snowflake queries that integrate reliably with the platform's script workflow. It enforces parameterized statements using ? placeholders and documents parameter names and types with inline comments. It also guides the developer flow for packaging and deploying scripts using the provided CLI commands.

How this skill works

You write SQL files with ? placeholders for runtime arguments and add a short comment line before the statement to name each parameter and declare its type and optional default. Place scripts in a folder, generate script metadata with the CLI, and push the package to the platform for execution. The skill checks for the correct comment format and common mistakes so queries are deployable as scripts, webhooks, or tasks.

When to use it

When creating Snowflake-backed scripts that will be deployed as platform scripts or webhooks.
When you need safe, parameterized queries to avoid SQL injection and ensure predictable bindings.
When you plan to generate metadata and lock files for reproducible script deployments.
When converting ad-hoc queries into self-hostable automation or UI-driven endpoints.
When you need to discover available resources and schema types before writing queries.

Best practices

Always use ? placeholders for runtime values rather than interpolating strings.
Place parameter comment lines immediately before the SQL statement, for example: -- ? user_id (number) = 0
Declare types and sensible defaults in comments to produce accurate .script.yaml metadata.
Keep each script focused and idempotent so it can be safely retried or run in workflows.
Run wmill resource-type list --schema to inspect available resource types before coding.

Example use cases

A script that queries users by name and age with: -- ? name (text) and -- ? age (number) before the SELECT using ? placeholders.
Automating a daily report that runs a parameterized Snowflake query and posts results to a webhook.
Converting an analytics query into a reusable endpoint that UI components can call with typed inputs.
Packaging business logic into scripts, generating .script.yaml and .lock files with wmill script generate-metadata, then deploying with wmill sync push.

FAQ

How do I name parameters in a query?

Add a comment line immediately before the SQL with the format: -- ? name (type) = default. The parser uses these comments to map placeholders to names and types.

What placeholder syntax should I use for arguments?

Use ? placeholders in the SQL statement. Each ? will be bound in order to the parameters declared in the comment lines.

What CLI commands are required to deploy a script?

Place scripts in a folder, run wmill script generate-metadata to create metadata and lock files, then deploy with wmill sync push.