v0.x-to-env-config

Migrates forge projects from KCL env-var groups to forge.yaml per-environment config.

4|1|Updated Apr 12, 2026
One-click install
npx skills add https://github.com/reliant-labs/forge --skill v0-x-to-env-config
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: v0.x-to-env-config
Source: https://github.com/reliant-labs/forge/tree/main/internal/templates/project/skills/forge/migration/v0.x-to-env-config
Command: npx skills add https://github.com/reliant-labs/forge --skill v0-x-to-env-config

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill helps you replace hand-curated KCL env-var groups with forge.yaml per-environment config so your dev/staging/prod values stop drifting and sensitive values are projected safely.

Core Features & Use Cases

  • Detect the old vs new shape: Identify legacy <NAME>_ENV constants/lambdas in deploy/kcl/base.k and confirm the presence of per-env generated config_gen.k.
  • Move config ownership to forge.yaml: Transfer per-env values into environments[<name>].config (inline) or config.<env>.yaml (sibling wins) to match your rollout needs.
  • Add proto annotations for correct projection: Mark sensitive fields in proto/config/v1/config.proto so forge generates secret_ref EnvVars automatically and groups fields into <CATEGORY>_ENV.

Quick Start

Ask the assistant: "Given my current deploy/kcl/base.k, forge.yaml, and proto/config/v1/config.proto, produce a step-by-step migration plan to upgrade from my pre-1.6 env-var soup to per-env environments[].config, including what to annotate and what to delete after regenerating KCL."

Frequently Asked Questions about v0.x-to-env-config

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

FAQPage Schema
How do I migrate KCL env-var groups to forge.yaml per-environment config?

You migrate KCL env-var groups by transferring legacy `<NAME>_ENV` constants from `deploy/kcl/base.k` into the `environments[].config` section of `forge.yaml` or sibling config files to prevent dev/staging/prod values from drifting.

When do I need to move config ownership to forge.yaml environments?

You need to move config ownership to forge.yaml environments when upgrading across the forge version that introduced `environments[].config` and generated `deploy/kcl/<env>/config_gen.k` outputs, typically during a 1.5.x to 1.6.x upgrade.

How do I project sensitive fields automatically using forge proto annotations?

To project sensitive fields automatically, you mark fields in `proto/config/v1/config.proto` with `(forge.v1.config)` annotations so forge generates `secret_ref` EnvVars automatically and groups fields into `<CATEGORY>_ENV` groups during KCL generation.

Does forge.yaml config take precedence over sibling config files per environment?

Sibling config files like `config.<env>.yaml` take precedence over inline `environments[].config` values defined in `forge.yaml`, allowing you to match specific rollout needs by overriding base environment configurations.

What are the limitations when migrating env-var soup to per-env config in forge?

A key constraint when migrating env-var soup is handling env-var concatenation changes in `main.k`; you must verify rendered `config_gen.k` outputs after regenerating KCL and before deleting old hand-curated constants to avoid breaking deployments.