Menu
Use when TypeScript work involves env values, config parsing, contextual config objects, config defaults, validation boundaries, or migration from legacy config reads.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when designing, reviewing, refactoring, or implementing code that should stay simple, testable, readable, and sustainable. Applies principles for investigating before changes, keeping few layers, making I/O explicit, using dependencies deliberately, organizing by feature, naming consistently, and presenting plans progressively.
Makes answers easier to start reading, scan, resume, and understand without losing important detail. Uses useful-answer-first structure, short paragraphs, clear literal headings, simple language, preserved nuance, natural voice, and small ASCII diagrams when they clarify structure or flow.
Use when working on TypeScript code and needing to choose the smallest focused TypeScript skill for coding standards, boundaries, composition, configs, async control, error handling, observability, security, or testing.
Use when TypeScript code coordinates async work — Promise.all vs sequential, bounded concurrency, AbortSignal cancellation, cleanup/teardown, or process lifecycle (SIGTERM, graceful shutdown).
Use when TypeScript code moves provider, SDK, API, request, response, generated, or raw input shapes across owned application boundaries.
Use when TypeScript work involves naming, abstractions, classes, local reasoning, semantic centers, full cutovers, type assertions, or design cleanup.
| name | typescript-configs |
| description | Use when TypeScript work involves env values, config parsing, contextual config objects, config defaults, validation boundaries, or migration from legacy config reads. |
Use this skill when unknown runtime values become typed application configuration.
Config shape depends on app scale and framework pressure:
| Application nature | Start with |
|---|---|
| Simple script, single file, usually one maintainer | One small manual parser and one local config object is fine |
| Medium app, multiple files/features, one person to small team | Contextual feature/module configs such as EmailConfig, BillingConfig, StorageConfig |
| Large app, many modules/features, one or more teams | Root parsing plus module config factories; pass only contextual configs inward |
| Framework-shaped app, such as Next.js, React Native/Expo, NestJS | Respect the framework's config/composition entrypoints, then project contextual configs at module/feature boundaries |
Default for non-trivial apps: avoid a god AppConfig flowing everywhere. Parse raw values at the boundary, then project the smallest contextual config each module needs. Framework conventions decide where parsing/assembly starts; they do not require feature modules to consume unrelated config.
| If you see... | Read |
|---|---|
process.env, raw config strings, !, as, untyped config | rules/parse-and-expose-config.md |
broad AppConfig passed into feature modules or tests | rules/contextual-config.md |
| schema does network/file/cloud checks | rules/validation-vs-verification.md |
| default value, fallback, dev default, global config owner question, production-safe behavior tuning | rules/defaults-and-ownership.md |
| URL, host, IP, endpoint, token, credential, secret-bearing fallback | ../typescript-security/rules/secrets-lifecycle.md |
| feature flag, mode, stage-derived behavior decision, repeated raw flag check | rules/feature-decisions.md |
| legacy env reads or risky config refactor | rules/migration.md |
../typescript-security/SKILL.md.../typescript-composition/SKILL.md.../typescript-testing/SKILL.md.Parse unknown values once at the boundary. Pass contextual typed config inward. If a missing value would not be production-correct, require it. Keep app-wide config only for app-wide facts, and keep dependency verification separate from parsing.