What problem does it solve? Error handling in a TypeScript codebase drifts quickly: codes widen to plain strings, messages become the contract, and errors leak credentials or prompts into logs. This Skill defines the rules for shaping Error subclasses and choosing stable ERR_* code strings so callers can branch reliably and logs stay safe. ## Core Features & Use Cases - Error class shape rules: Subclass Error, set this.name, declare readonly code as a literal type, and keep the underlying failure on cause rather than folding it into message. - Code vocabulary conventions: ERR_ prefix in SCREAMING_SNAKE_CASE, layer prefixes under src/** (e.g. ERR_LLM_* in src/ai/errors.ts) and stage prefixes under scripts/** (e.g. ERR_AGENTS_, ERR_LABELS_). - Safety constraints: Errors must never carry credentials, prompts, model outputs, or request content; abort reasons are preserved by identity via asError and abortedLlmError. - Use Case: When adding a new failure mode to an LLM adapter, use this Skill to decide whether to extend the LlmError union, pick the right ERR_LLM_* code, and write the PR line announcing the contract change. ## Quick Start Ask the AI to design a new error class and ERR_* code for a failure you are adding, following the designing-errors conventions.