Render Env

Add a Render env variable to Terraform

This skill declares a new Terraform Cloud variable so a value can be set via the TFC UI and consumed by the Render backend services. It only does the plumbing — it does not wire the variable into a Render env group. Wiring requires picking the right *_config / *_secrets object in terraform/modules/render_service/, which is task-specific and the user should drive.

Inputs

The skill takes two positional args from the invocation: /render-env <name> <description>.

• ${name} — the Terraform variable name in snake_case. Used verbatim as the TFC variable key, the tfe_variable resource suffix, and the variable block name. Example: stripe_climate_api_key.
• ${description} — a short human-readable description. Used in the description attribute and (with the env appended) in the per-env tfe_variable description. Example: Stripe Climate API key.

If either arg is missing, ask the user before doing anything. Also ask:

• Sensitive? Default to true (almost everything in these files is sensitive). Only set false for non-secret config strings (cf. slo_report_slack_channel, customer_portal_url_overrides).
• Which environments? Default to all three (production, sandbox, test). The user may want to skip one — test in particular often omits variables that aren't exercised there.

Do not ask about lifecycle { ignore_changes = [value] }. New variables here have no value baked into the Terraform code, so there's nothing for Terraform to overwrite — TFC just holds whatever's typed into the UI, and ignore_changes would be a no-op. The handful of existing blocks that include it (e.g. polar_organization_id, customer_portal_url_overrides) seed a default value in code and want UI overrides to stick; that's a different shape from a fresh secret and the user will tell you up-front if they want it.

Naming convention

Follow the modern bare-key pattern that recent additions use (e.g. polar_access_token, tinybird_api_token, customer_portal_url_overrides):

• The TFC key is the bare name: key = "${name}" — no _production / _sandbox / _test suffix on the key. Each variable set is per-workspace so the key doesn't need to be globally unique.
• The tfe_variable resource label does get the env suffix: resource "tfe_variable" "${name}_${env}".
• The matching variable block in terraform/${env}/variables.tf uses the bare name: variable "${name}". This lets render.tf reference it uniformly as var.${name} across all envs.

A handful of older variables (e.g. google_client_id_production, backend_secret_production) use a _production/_sandbox-suffixed key and matching variable. Don't replicate that pattern for new additions — it's legacy.

Step 1: Add the tfe_variable to each global/{env}.tf

For each selected ${env} in production, sandbox, test, append a block to terraform/global/${env}.tf (after the existing tfe_variable resources, before the file ends):

resource "tfe_variable" "${name}_${env}" {
  key             = "${name}"
  category        = "terraform"
  description     = "${description} for ${env}"
  sensitive       = ${sensitive}
  variable_set_id = tfe_variable_set.${env}.id
}

Only add a lifecycle { ignore_changes = [value] } block or a value = "..." line if the user explicitly asks for one (rare — usually let TFC hold the value).

Use Edit with enough surrounding context that the insertion lands at the correct spot. Prefer appending after the last existing tfe_variable resource in the file rather than rewriting the file.

Step 2: Add the variable {} block to each {env}/variables.tf

For each selected ${env}, append a block to terraform/${env}/variables.tf:

variable "${name}" {
  description = "${description}"
  type        = string
  sensitive   = ${sensitive}
}

Drop the sensitive = true line when ${sensitive} is false. Drop nothing else.

Step 3: Format

Run:

terraform fmt -recursive terraform

from the repo root. If terraform isn't on PATH, note it and skip — the formatting is a nicety, not required.