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.