ワンクリックで
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 職業分類に基づく
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.
| 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.