Menu
Creates and updates Coder Registry workspace templates with agent setup, infrastructure provisioning, and module consumption
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Deploy a new application to this Flux GitOps cluster. Use when asked to add an app, scaffold base and overlay manifests, choose a Helm chart, wire ingress, or prepare deployment validation.
Generate or update GitOps documentation for this repository. Use when asked to write application READMEs, runbooks, architecture notes, troubleshooting guides, or other docs tied to apps, infrastructure, monitoring, or cluster operations.
Create implementation plans for new applications, infrastructure changes, refactors, or rollout work in this GitOps repository. Use when the user asks for a plan, architecture impact, sequencing, dependencies, validation, or rollback steps before implementation.
Search historical GitHub issues and local troubleshooting docs for reusable fixes. Use when asked whether an incident happened before, when looking for similar failures, or when ranking likely known fixes before deeper diagnostics.
Create, rotate, and wire Bitnami Sealed Secrets for this GitOps repository. Use when asked to add a secret, rotate credentials, seal secret values, or connect secret data to Flux and application manifests.
Review Kubernetes manifests, HelmRelease values, Flux resources, and Kustomize overlays in this repository. Use when asked to review GitOps config, inspect YAML changes, audit manifests, or check Flux and security best practices.
| name | coder-templates |
| description | Creates and updates Coder Registry workspace templates with agent setup, infrastructure provisioning, and module consumption |
Coder workspace templates are complete workspace definitions that live under registry/<namespace>/templates/<name>/ and provision the infrastructure that workspaces run on.
Before writing or modifying any code:
registry/ in this repo for similar templates and modules first; if you are not in the repo or cannot find a match, browse https://registry.coder.com. Read main.tf to understand patterns for that platform, especially how they handle agent setup, persistent storage, and module consumption. Prefer platform-specific helper modules (e.g. region selectors) that provide ready-made coder_parameter blocks over hard-coding option lists.coder_parameter options to expose, which registry modules to consume, and whether additional files like cloud-init configs are needed. When the user describes requirements in terms of their development needs rather than specific Terraform changes (e.g. "I need Node 20 + Postgres 16" or "make this template work for data science"), summarize what you plan to add or change before proceeding. Keep it brief: list the parameters, modules, and infrastructure changes. Skip this for straightforward requests where the action is clear (e.g. "add the code-server module" or "change the default region to us-west-2").When updating an existing template, read and understand all of its current resources, parameters, and module consumption before making changes. If you observe patterns that deviate from the coder template standards (e.g. missing metadata blocks, hardcoded values that should be parameters, inline implementations that existing modules could replace, missing error handling in scripts), note these to the user as improvement opportunities in your response.
Always prefer the proper implementation over a simpler shortcut. Templates are infrastructure that users depend on. Doing less work is not the same as reducing complexity if it leaves the template incomplete or fragile.
Features marked as "Premium" in this skill require a Coder Premium license. When your implementation uses a Premium feature, note this in your response to the user so they can verify their deployment supports it.
https://coder.com/docs/@v{MAJOR}.{MINOR}.{PATCH} (e.g. https://coder.com/docs/@v2.31.5)latest with a version number (e.g. https://registry.terraform.io/providers/coder/coder/2.13.1/docs)Resources:
Data sources:
All provider docs follow https://registry.terraform.io/providers/ORG/NAME/latest/docs:
| Provider | Source |
|---|---|
| Docker | kreuzwerker/docker |
| AWS | hashicorp/aws |
| Azure | hashicorp/azurerm |
| GCP | hashicorp/google |
| Kubernetes | hashicorp/kubernetes |
| Cloud-Init | hashicorp/cloudinit |
Browse all providers: https://registry.terraform.io/browse/providers
Only use this when creating a brand new template that does not yet exist. When updating an existing template, edit its files directly.
From repo root:
./scripts/new_template.sh namespace/template-name
Names must be lowercase alphanumeric with hyphens (e.g. my-org/aws-ec2). Underscores are not allowed.
Creates registry/<namespace>/templates/<template-name>/ with:
main.tf: full workspace Terraform config with common patterns — read this as the primary reference for template structureREADME.md: frontmatter and documentationIf the namespace is new, the script also creates registry/<namespace>/ with a README. New namespaces additionally need:
registry/<namespace>/.images/avatar.svg (or .png): square image, 400x400px minimumavatar field pointing to ./.images/avatar.svgThe scaffolding script does not create the .images/ directory or avatar file. When a new namespace is created, create registry/<namespace>/.images/ and add a placeholder avatar.svg so the directory structure is ready for the user to replace with their real avatar.
The generated namespace README contains placeholder fields (display_name, bio, status, github, avatar, etc.) that the user must fill out. The status field is required and must be official, partner, or community (typically community for new contributors).
coder provider version when the template uses a resource, attribute, or behavior introduced in that version. The same applies to infrastructure providers (Docker, AWS, etc.); check provider changelogs to confirm.data.coder_workspace.me and data.coder_workspace_owner.me for workspace and owner metadata. Include data.coder_provisioner.me only when you need the provisioner's arch or os for coder_agent (typical for Docker, Kubernetes, Incus); omit when the workspace OS/arch is fixed (e.g. cloud VMs with a known image).locals {} for computed values: username, environment variables, startup scripts, URL assemblydata.coder_workspace.me.start_count as count on ephemeral resourcescoder_agent.main.init_script and CODER_AGENT_TOKENmetadata blocks for workspace dashboard stats (coder stat cpu, coder stat mem, etc.)coder_metadata on the primary compute resource to surface key details (region, instance type, image, disk size) in the workspace dashboarddisplay_apps block to hide specific built-in apps (defaults show all)registry/*/modules/ in this repo; if you cannot find one or are not in the repo, search https://registry.coder.com. If a module already exists for what you need, consume it rather than reimplementing it. When multiple modules serve similar purposes, prefer the actively maintained one and check that you are not using a deprecated or superseded module.main.tf and README.md to understand the full interface: accepted variables, outputs, prerequisites, and runtime requirements. Prefer paths under registry/<namespace>/modules/<name>/ in this workspace; otherwise use https://registry.coder.com/modules/<namespace>/<module-name>. Never pass arguments without confirming they exist.terraform validate; they only surface when the workspace starts.registry.coder.com/<namespace>/<module>/coder. Older templates may use registry.coder.com/modules/...; prefer the shorter form when writing new modules or templates.coder.owner and coder.workspace_id for tracking orphanslifecycle { ignore_changes = all } on persistent volumes to prevent data lossTemplates can include files beyond main.tf + README.md:
cloud-init/*.tftpl: cloud-init configs for VM provisioning (AWS, Azure, GCP), loaded via templatefile(). Prefer this subdirectory over placing cloud-init files at the template root.build/Dockerfile: custom container images built by the template.tftpl files: any Terraform template files for scripts, configs, or cloud-init dataUse data "coder_parameter" for user-facing workspace options. Typical parameters: region/instance type/CPU/memory/disk for cloud VMs; container image or runtime version for Docker (pass as build_arg when using a local Dockerfile). Use same-platform templates in registry/ as a starting reference, not a rigid pattern. Expose stated preferences as the parameter default with additional sensible option values unless the user explicitly restricts it.
dynamic "option" blocks with for_each from a locals map over static option blocks. See the region selector modules (e.g. coder/aws-region) for the pattern.form_type for richer UI controls: dropdown (searchable), multi-select (for list(string)), slider (numeric), radio, checkbox, textarea.count to show/hide a parameter based on another parameter's value.mutable = false for infrastructure that can't change after creation (region, disk); mutable = true for runtime config.ephemeral = true for one-shot build options that don't persist between starts.validation {} with min/max/monotonic for numbers, regex/error for strings.>= 2.4.0.Workspace presets bundle commonly-used parameter combinations into selectable options. When a user creates a workspace, they can pick a preset to auto-fill multiple parameters at once. Define presets with data "coder_workspace_preset":
data "coder_workspace_preset" "default" {
name = "Standard Dev Environment"
default = true
parameters = {
"region" = "us-east-1"
"cpu" = "4"
"memory" = "8"
"container_image" = "codercom/enterprise-base:ubuntu"
}
}
parameters must match the name attribute of coder_parameter data sources in the same template.default = true on at most one preset to pre-select it in the UI.description (context text in UI) and icon (e.g. /emojis/1f680.png).Prebuilds maintain an automatically-managed pool of pre-provisioned workspaces for a preset, reducing workspace creation time. This is a Premium feature. Prebuilds are configured as a nested block inside a preset:
data "coder_workspace_preset" "goland" {
name = "GoLand: Large"
parameters = {
"jetbrains_ide" = "GO"
"cpu" = "8"
"memory" = "16"
}
prebuilds {
instances = 3
expiration_policy {
ttl = 86400
}
scheduling {
timezone = "UTC"
schedule {
cron = "* 8-18 * * 1-5"
instances = 5
}
}
}
}
instances: number of prebuilt workspaces to keep in the pool (base count when no schedule matches).expiration_policy.ttl: seconds before unclaimed prebuilds are cleaned up.scheduling: scale the pool up or down on a time-based cron schedule. The cron minute field must always be *.lifecycle { ignore_changes = [...] } on resources that reference owner-specific values to prevent unnecessary recreation.A template becomes task-capable by adding a coder_ai_task resource, which enables the Coder Tasks UI for AI agent workflows. Task templates require three additions on top of a regular template:
resource "coder_ai_task" "task" {
count = data.coder_workspace.me.start_count
app_id = module.claude-code[count.index].task_app_id
}
data "coder_task" "me" {}
module "claude-code" {
count = data.coder_workspace.me.start_count
source = "registry.coder.com/coder/claude-code/coder"
version = "~> 4.0"
agent_id = coder_agent.main.id
workdir = "/home/coder/projects"
ai_prompt = data.coder_task.me.prompt
system_prompt = data.coder_parameter.system_prompt.value
model = "sonnet"
permission_mode = "plan"
enable_boundary = true
}
coder_ai_task: declares the template as task-capable. Its app_id must point to the agent module's task_app_id output.data "coder_task": reads the user's task prompt. Pass it to the agent module via ai_prompt.claude-code, codex, etc.) with task-specific variables. Key variables include ai_prompt, system_prompt, permission_mode, and enable_boundary.enable_boundary = true on the agent module to enable network-level filtering for the AI agent. See https://coder.com/docs/ai-coder/agent-boundaries for allowlist configuration.coder_app with slug = "preview" gets special treatment in the Tasks UI navbar.registry/coder-labs/templates/tasks-docker as a reference implementation.Docs: https://coder.com/docs/ai-coder/tasks
Required YAML frontmatter:
---
display_name: Docker Containers
description: Provision Docker containers with persistent home volumes as Coder workspaces
icon: ../../../../.icons/docker.svg
verified: false
tags: [docker, container]
---
Content rules:
display_name, directly below frontmatterdescription field should follow the same principle.tf (NOT hcl)../../../../.icons/)> [!NOTE], > [!TIP], > [!IMPORTANT], > [!WARNING], > [!CAUTION]Templates reference icons in the README frontmatter icon: field using a relative path to the repo's .icons/ directory (e.g. ../../../../.icons/aws.svg). This icon is displayed on the registry website.
Workflow:
.icons/ directory at the repo root for available SVGs..icons/ in this repo.Templates do NOT require .tftest.hcl or main.test.ts. Testing is done by pushing the template to a Coder deployment.
| Task | Command | Scope |
|---|---|---|
| Format all | bun run fmt | Repo |
| Validate | ./scripts/terraform_validate.sh | Repo |
| ShellCheck | bun run shellcheck | Repo |
Before considering the work complete, verify:
terraform init && terraform validate passes in the template directorybun run fmt has been runbun run shellcheck passes if the template includes shell scripts|| echo "Warning..." for non-fatal failures). If a script sources external files ($HOME/.bashrc, /etc/bashrc, /etc/os-release), the source must come before set -u; CI enforces this ordering.../../../../.icons/), not absolute. External hyperlinks to docs or other websites are fine.In your response, include:
-d to point at the template directory (so it works from the repo root), -m for a short description, and -y to skip interactive prompts:coder templates push \
registry/ \
-m "Initial version: <brief description>" \
-y < template-name > -d < namespace > /templates/ < template-name > /
display_name, bio, status, github, etc.) and replace the placeholder avatar. Note that this is only needed if they plan to contribute to the registry..icons/ directory and the coder/coder repo at site/static/icon/.