write-script-bun

Writes TypeScript scripts for Windmill using the Bun runtime and windmill-client SDK.

1|Updated Aug 3, 2026
One-click install
npx skills add https://github.com/vpzed-dev/smithy --skill write-script-bun-vpzed-dev
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: write-script-bun
Source: https://github.com/vpzed-dev/smithy/tree/main/windmill/local-dev/.agents/skills/write-script-bun
Command: npx skills add https://github.com/vpzed-dev/smithy --skill write-script-bun-vpzed-dev

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires windmill-client.

What problem does it solve? Writing TypeScript automation scripts for the Windmill platform requires knowing the correct script structure, runtime choice, CLI commands, and metadata synchronization steps, and getting any of these wrong produces stale locks, spurious diffs, or accidental deploys. ## Core Features & Use Cases - Bun-first TypeScript authoring: Enforces the standard Windmill script shape (a single exported async main function), resource typing via the RT namespace, and npm imports, with Bun as the default runtime unless Deno is specifically needed. - Correct CLI workflow: Distinguishes wmill script preview (local iteration) from wmill script run (deployed version) and wmill sync push (explicit deploy only), preventing untested changes from overwriting the workspace. - Metadata synchronization: Runs wmill generate-metadata after edits that change imports or main arguments so .lock files, .script.yaml input schemas, and wmill-lock.yaml hashes stay consistent. - Full windmill-client reference: Includes the complete TypeScript SDK surface (resources, variables, state, S3 operations, flows, approvals, workflow-as-code) so scripts use the client instead of hand-rolled fetch calls. - Use Case: A user asks for a script that reads a Slack resource and posts an approval request; the Skill produces a typed Bun script using wmill.requestInteractiveSlackApproval, previews it locally with sample args, and regenerates metadata before any deploy. ## Quick Start Write a Windmill TypeScript script in Bun that fetches data from an external API and stores the result with the windmill-client, then preview it locally.

Frequently Asked Questions about write-script-bun

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a TypeScript script for Windmill with Bun?▼

Export a single async function named main whose parameters become the script's input arguments, and import npm packages directly. Use the RT namespace for Windmill resource types and the windmill-client package for platform operations like reading resources or running flows.

What is the difference between wmill script preview and wmill script run?▼

wmill script preview executes the local script file without deploying, making it the default for iterating on edits. wmill script run executes the version already deployed in the workspace, so use it only when you explicitly want to test the deployed version.

When should I use Bun versus Deno for Windmill TypeScript scripts?▼

Bun is the default and preferred TypeScript runtime on Windmill, offering the full npm ecosystem and fast execution. Choose Deno only when a specific use case requires it, and consider a native //native script when the code only needs fetch and the JavaScript standard library.

Why does wmill-lock.yaml show diffs after editing a script?▼

Editing a script's content, especially adding imports or changing main's arguments, invalidates its recorded content hash and leaves the lock and input schema stale. Run wmill generate-metadata to regenerate the .lock, .script.yaml, and hash entries so they match the code.

Can I use the Windmill client instead of fetch for API calls?▼

Yes, and it is preferred for anything that talks to Windmill itself, such as reading resources, variables, state, or running scripts and flows, because it handles auth and workspace configuration. Reserve fetch for calling external HTTP APIs outside Windmill.