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

write-script-mysql skill

safe

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

This skill helps you write safe MySQL queries by guiding parameter placeholders, comments, and syntax for clean, maintainable database access.

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

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

Files (1)

SKILL.md

546 B

---
name: write-script-mysql
description: MUST use when writing MySQL 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.

# MySQL

Arguments use `?` placeholders.

Name the parameters by adding comments before the statement:

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

Overview

This skill provides a concise, practical guide for writing MySQL queries when building scripts for the platform. It emphasizes parameterized statements using ? placeholders and shows how to name parameters with inline comments. It also includes the essential CLI commands to generate script metadata and deploy scripts to the platform.

How this skill works

When composing MySQL statements, use ? placeholders for every argument to ensure parameterization and avoid injection. Name each parameter by adding a comment line immediately before the SQL statement using the format: -- ? paramName (type) = default. After scripts are written to a folder, run the provided CLI commands to generate metadata and push deployments.

When to use it

When writing scripts that execute MySQL queries inside the platform.
When you need safe, parameterized SQL to prevent injection and support typed parameters.
When preparing scripts for automated deployment with the platform’s CLI.
When you want consistent metadata files (.script.yaml and .lock) generated for each script.

Best practices

Always use ? placeholders for query arguments rather than interpolating values directly.
Name parameters with comment lines before the SQL and include types and optional defaults. Example: -- ? id (int) = 0
Keep queries simple and focused per script to make metadata generation predictable.
Run wmll script generate-metadata after changes so .script.yaml and .lock stay current.
Use wmll sync push to deploy only after metadata is generated and tested locally.

Example use cases

Select users with dynamic filters: name and minimum age using ? placeholders and named parameters.
Insert records where parameter types and defaults ensure valid payloads from workflows or webhooks.
Update statements driven by UI forms that bind inputs to named parameters declared in comments.
Batch scripts that run on a schedule and are deployed via wmll sync push with accompanying metadata.

FAQ

How do I declare a parameter type and default?

Add a comment line before the SQL using the format: -- ? paramName (type) = default. Type is a human-readable hint like text or int.

What CLI commands are required to deploy a script?

Run wmll script generate-metadata to create .script.yaml and .lock, then run wmll sync push to deploy the script to the platform.