docs: make the linked-variable resource the default, not the only option

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

cli/src/guidance/skills.gen.ts

@@ -95,7 +95,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -260,7 +260,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -385,7 +385,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -503,7 +503,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -1327,7 +1327,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -2163,7 +2163,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -2280,7 +2280,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -3106,7 +3106,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -3257,7 +3257,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -3391,7 +3391,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -3512,7 +3512,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -3626,7 +3626,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -3743,7 +3743,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -3861,7 +3861,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -3994,7 +3994,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -4110,7 +4110,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -4241,7 +4241,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -5251,7 +5251,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -5412,7 +5412,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -5563,7 +5563,7 @@ Use \`wmill resource-type list --schema\` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -7204,7 +7204,7 @@ The Windmill Hub publishes resource types for most services, and an instance get
 
 - If looking up resource types reports that the instance is missing the hub's types, mention that a superadmin can sync them: the hub most likely has one for the service. Create one of your own only if the user still wants it, since after a sync the workspace would hold both.
 - Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields (base URL, account or region identifiers, credentials), as in "Custom Resource Types" below, and ask the user before creating it: every resource of that type and every script taking one depends on its fields.
-- Use a plain variable instead of a resource only when the user prefers it.
+- A plain variable instead of a resource is fine when the user asks for it; without that, default to the resource, its secret in a variable it references.
 
 ## Custom Resource Types
 

system_prompts/auto-generated/prompts.ts

@@ -5,7 +5,7 @@ export const SCRIPT_BASE = `# Windmill Script Writing Guide
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it \`main\` (\`Main\` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no \`main\`: their language section shows how they take arguments
 - Where the language has a Windmill client (\`wmill\`), use it to interact with the platform
@@ -835,7 +835,7 @@ The Windmill Hub publishes resource types for most services, and an instance get
 - If looking up resource types reports that the instance is missing the hub's types, mention that a superadmin can sync them: the hub most likely has one for the service. Create one of your own only if the user still wants it, since after a sync the workspace would hold both.
 - Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields (base URL, account or region identifiers, credentials), as in "Custom Resource Types" below, and ask the user before creating it: every resource of that type and every script taking one depends on its fields.
 - You cannot create a resource type yourself: give the user the schema to add with **Add resource type** on the Resources page.
-- Use a plain variable instead of a resource only when the user prefers it.
+- A plain variable instead of a resource is fine when the user asks for it; without that, default to the resource, its secret in a variable it references.
 
 ## Custom Resource Types
 

system_prompts/auto-generated/script.md

@@ -3,7 +3,7 @@
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/resources/SKILL.md

@@ -220,7 +220,7 @@ The Windmill Hub publishes resource types for most services, and an instance get
 
 - If looking up resource types reports that the instance is missing the hub's types, mention that a superadmin can sync them: the hub most likely has one for the service. Create one of your own only if the user still wants it, since after a sync the workspace would hold both.
 - Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields (base URL, account or region identifiers, credentials), as in "Custom Resource Types" below, and ask the user before creating it: every resource of that type and every script taking one depends on its fields.
-- Use a plain variable instead of a resource only when the user prefers it.
+- A plain variable instead of a resource is fine when the user asks for it; without that, default to the resource, its secret in a variable it references.
 
 ## Custom Resource Types
 

system_prompts/auto-generated/skills/write-script-ansible/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-bash/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-bigquery/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-bun/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-bunnative/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-csharp/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-deno/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-duckdb/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-go/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-graphql/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-java/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-mssql/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-mysql/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-php/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-postgresql/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-powershell/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-python3/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-rlang/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-rust/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/auto-generated/skills/write-script-snowflake/SKILL.md

@@ -53,7 +53,7 @@ Use `wmill resource-type list --schema` to discover available resource types.
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform

system_prompts/base/resources.md

@@ -222,7 +222,7 @@ The Windmill Hub publishes resource types for most services, and an instance get
 <!-- chat-only -->
 - You cannot create a resource type yourself: give the user the schema to add with **Add resource type** on the Resources page.
 <!-- /chat-only -->
-- Use a plain variable instead of a resource only when the user prefers it.
+- A plain variable instead of a resource is fine when the user asks for it; without that, default to the resource, its secret in a variable it references.
 
 ## Custom Resource Types
 

system_prompts/base/script-base.md

@@ -3,7 +3,7 @@
 ## General Principles
 
 - A script's inputs are its parameters. Credentials and configuration come in as resource-typed parameters, never hard-coded or read from the environment; the language section below shows how that language declares parameters
-- When no resource type exists for a service, don't fall back to a plain string parameter or a variable read inside the code. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. Use a variable only if the user prefers one: a resource keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
+- When no resource type exists for a service, the default is still a resource, its secret in a variable it references. If looking up resource types reports that the instance is missing the Windmill Hub's types, mention that a superadmin can sync them, since the hub has types for most services. Otherwise, or when the user prefers it to syncing, propose a resource type holding the service's connection fields and ask before creating it. A plain string parameter or a variable read inside the code is fine when the user asks for it; the resource is the default because it keeps a connection's fields together, lets whoever runs the script pick an existing connection, and keeps the secret out of the arguments a run records
 - Libraries are installed automatically - do not show installation instructions
 - In a language with an entrypoint function (TypeScript, Python, Go, Rust, PHP, R, …), name it `main` (`Main` in C#) and do not call it; in TypeScript it must be async. SQL, GraphQL, Bash, PowerShell and Ansible scripts have no `main`: their language section shows how they take arguments
 - Where the language has a Windmill client (`wmill`), use it to interact with the platform