playbooks

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

write-script-mssql skill

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

This skill helps you craft secure MSSQL queries by guiding parameter naming, documenting @P1 style placeholders, and ensuring correct syntax for reliable data

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

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

Files (1)
SKILL.md
589 B
---
name: write-script-mssql
description: MUST use when writing MS SQL Server 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.

# Microsoft SQL Server (MSSQL)

Arguments use `@P1`, `@P2`, etc.

Name the parameters by adding comments before the statement:

```sql
-- @P1 name1 (varchar)
-- @P2 name2 (int) = 0
SELECT * FROM users WHERE name = @P1 AND age > @P2;
```

Overview

This skill enforces Microsoft SQL Server syntax and conventions when writing queries. It guides parameter usage, parameter naming comments, and required CLI steps to prepare and deploy scripts to the platform. The goal is predictable, deployable MSSQL scripts that integrate with Windmill workflows and resources.

How this skill works

It inspects SQL text for MSSQL-specific patterns: parameter placeholders like @P1, @P2, and the required comment-based parameter declarations. It checks for proper parameter ordering, default values, and common MSSQL syntax issues. It also reminds you to generate metadata and push changes using the Windmill CLI so scripts become deployable resources.

When to use it

  • Authoring parameterized queries for Microsoft SQL Server
  • Preparing scripts to run as Windmill scripts/webhooks/workflows
  • Ensuring queries include typed parameter comments for automatic metadata
  • Validating MSSQL-specific syntax before deployment
  • Converting ad-hoc SQL into repeatable, self-hosted automation

Best practices

  • Always declare parameters with comments immediately before the SQL statement, e.g. -- @P1 name (varchar) or -- @P2 count (int) = 0
  • Use @P1, @P2 style placeholders and keep ordering consistent between comments and usage
  • Specify types and defaults where possible to generate accurate metadata and avoid runtime type errors
  • Place scripts in a dedicated folder and run wmill script generate-metadata before pushing
  • Run wmill resource-type list --schema to discover available resources and match types to MSSQL connections

Example use cases

  • Querying users with parameterized filters: add parameter comments, reference @P1 and @P2, then generate metadata and deploy
  • Batch jobs that expect typed inputs and defaults—declare defaults in comments to allow safe runs
  • Expose a query as a webhook: declare parameters, generate metadata, then wmill sync push to deploy
  • Use in a workflow that calls MSSQL scripts with inputs mapped from prior steps

FAQ

How do I name parameters for readability?

Add a commented declaration immediately above the SQL statement, e.g. -- @P1 username (varchar). The mapper will use that name for generated metadata and UIs.

What CLI steps are required before deploying?

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