一键导入
env-configuration
Adding or reading env vars, updating .env.example, or validating config at startup with parseEnv / parseEnvOptional.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Adding or reading env vars, updating .env.example, or validating config at startup with parseEnv / parseEnvOptional.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | env-configuration |
| description | Adding or reading env vars, updating .env.example, or validating config at startup with parseEnv / parseEnvOptional. |
When to use: Adding or reading env vars, updating .env.example, or validating config at startup with parseEnv / parseEnvOptional.
LAT_ prefix conventionAll application environment variables must be prefixed with LAT_ so they do not collide with third-party services, Docker, or common names.
Use LAT_ for:
LAT_DATABASE_URL, LAT_PG_POOL_MAX, …)CLICKHOUSE_URL, LAT_REDIS_HOST, …)LAT_API_PORT, LAT_WEB_PORT, LAT_INGEST_PORT)LAT_BETTER_AUTH_SECRET, LAT_MAILPIT_HOST, …)Do not use LAT_ for:
NODE_ENVPOSTGRES_USER, CLICKHOUSE_USER, …)VITE_LAT_* (Vite requires the VITE_ prefix)Reference: .env.example lists Docker “Services” vs “Latitude Application” (LAT_*) variables.
.env.example maintenanceEvery new variable must appear in .env.example:
LAT_API_PORT=3001)# LAT_STRIPE_SECRET_KEY=sk_test_xxx)Always use parseEnv or parseEnvOptional from @platform/env — never process.env.FOO ad hoc or unprefixed names for app config.
// ❌ Bad - unprefixed or direct access
const port = Number(process.env.PORT)
// ✅ Good - pass the variable name string (parseEnv reads process.env internally)
import { parseEnv, parseEnvOptional } from "@platform/env"
import { Effect } from "effect"
const port = Effect.runSync(parseEnv("LAT_API_PORT", "number", 3001))
const dbUrl = Effect.runSync(parseEnv("LAT_DATABASE_URL", "string"))
For where configuration is wired in apps (clients, routes), see architecture-boundaries.
Layering and boundaries, web vs public API, app layout (clients, routes, logging), ports/adapters, runtime-portable domain/shared/utils code, multi-tenancy, DDD layout, or anti-patterns.
Review the current conversation context and git changes, then persist durable repository knowledge into `dev-docs/*.md` by domain and into `AGENTS.md` for cross-cutting repo rules. Use after features, fixes, refactors, architecture changes, schema changes, or when the user mentions docs, documentation, design, architecture, business logic, conventions, or `AGENTS.md`.
Biome formatting, import style, strict TypeScript, naming (including React file names), or generated files.
Writing or debugging tests, choosing unit vs integration style, Postgres/ClickHouse tests, regenerating ClickHouse test schema, or exporting test helpers from packages without pulling test code into production bundles.
Queues and workers, domain event publishers, async notifications or projections, or not doing that work inside HTTP handlers.
apps/web UI — routes, @repo/ui, TanStack Start server functions and collections, forms (useForm + createFormSubmitHandler + fieldErrorsAsStrings for Zod field errors), Tailwind layout rules, design-system updates, and useEffect / useMountEffect policy.