How do I install the Env Change Verification skill?

Run npx skillmds@latest add randommonicle/env-change-verification in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Env Change Verification safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Env Change Verification?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Env Change Verification free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Env Change Verification?

randommonicle (@randommonicle) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Env Change Verification by randommonicle

Name: Env Change Verification
Author: randommonicle

Env Change Verification

An environment variable change is not live until the artifact that reads it is rebuilt, redeployed, or re-reads it — and a wrong-but-present value fails silently. Know for each variable whether it is baked at build time or read at request time. Triggers when adding or editing any env var, CI secret, or hosted config value, and when a CI or cloud build consumes build-time env. Does not fire on database schema changes (db-migration-verification) or on code-only changes with no config surface.

randommonicle Updated Sep 21, 2026

File contents

Env-change verification

Cross-repo: an entire iOS build track silently talked to the wrong Supabase backend because the cloud build could not see .env.local and nobody diffed the CI variables; a Railway value stored as KEY=value served a malformed URL; Netlify functions read old values until the next deploy.

The rule

Setting a variable and the running artifact using it are two separate steps, and presence is not correctness. After any env change: know the variable's read time, complete the step that makes it live, and verify from the live surface.

How to apply

Know the read time per variable. Build-time-baked (VITE_*, import.meta.env, anything bundled) needs a rebuild; deploy-baked (serverless env) needs a redeploy; request-time-read needs nothing — the proposal's own flag conventions depend on knowing which is which.
CI and cloud builds never see .env.local. Whenever a build consumes build-time vars, diff the CI variable set against the canonical local env — name by name AND value by value.
Validate the value, not its presence: the right project ref (not the sibling project's), no KEY= prefix pasted into a value field, a URL that parses. A wrong-but-present value fails silently; a missing one at least crashes.
Verify from the live surface — hit the endpoint, open the built app — never from the dashboard that shows what you just typed.
Adding a secret can activate a previously-skipped CI job that needs more than that one secret; watch the next run.
Module-load env reads make pure code un-importable (a CI red at import, before any test body, is the signature) and crash the process on a missing var — prefer lazy initialisation of external clients.

What this skill does not do

It does not cover schema changes (db-migration-verification) or feature-flag semantics beyond their read-time. It does not replace one-real-ride — a ride after an env change is still the final gate.

Why

Config is the only layer where a change can be "successfully saved" and have no effect at all, indefinitely, with no error anywhere. Evidence: ASH LESSONS_LEARNED 2026-05-27 (evening), 2026-06-04 (night), and the CLAUDE.md Railway section; ICC L-018 and its CLAUDE.md review-requests note.

---name: env-change-verificationdescription: An environment variable change is not live until the artifact that reads it is rebuilt, redeployed, or re-reads it — and a wrong-but-present value fails silently. Know for each variable whether it is baked at build time or read at request time. Triggers when adding or editing any env var, CI secret, or hosted config value, and when a CI or cloud build consumes build-time env. Does not fire on database schema changes (db-migration-verification) or on code-only changes with no config surface.---# Env-change verificationCross-repo: an entire iOS build track silently talked to the wrong Supabase backend becausethe cloud build could not see `.env.local` and nobody diffed the CI variables; a Railwayvalue stored as `KEY=value` served a malformed URL; Netlify functions read old values untilthe next deploy.## The ruleSetting a variable and the running artifact using it are two separate steps, and presence isnot correctness. After any env change: know the variable's read time, complete the step thatmakes it live, and verify from the live surface.## How to apply- **Know the read time per variable.** Build-time-baked (`VITE_*`, `import.meta.env`, anything bundled) needs a rebuild; deploy-baked (serverless env) needs a redeploy; request-time-read needs nothing — the proposal's own flag conventions depend on knowing which is which.- **CI and cloud builds never see `.env.local`.** Whenever a build consumes build-time vars, diff the CI variable set against the canonical local env — name by name AND value by value.- **Validate the value, not its presence**: the right project ref (not the sibling project's), no `KEY=` prefix pasted into a value field, a URL that parses. A wrong-but-present value fails silently; a missing one at least crashes.- **Verify from the live surface** — hit the endpoint, open the built app — never from the dashboard that shows what you just typed.- **Adding a secret can activate a previously-skipped CI job** that needs more than that one secret; watch the next run.- **Module-load env reads make pure code un-importable** (a CI red at import, before any test body, is the signature) and crash the process on a missing var — prefer lazy initialisation of external clients.## What this skill does not doIt does not cover schema changes (db-migration-verification) or feature-flag semanticsbeyond their read-time. It does not replace one-real-ride — a ride after an env change isstill the final gate.## WhyConfig is the only layer where a change can be "successfully saved" and have no effect atall, indefinitely, with no error anywhere. Evidence: ASH LESSONS_LEARNED 2026-05-27(evening), 2026-06-04 (night), and the CLAUDE.md Railway section; ICC L-018 and itsCLAUDE.md review-requests note.

Frequently asked questions