designing-errors

Designs Error subclasses and ERR_* code vocabularies for TypeScript source and scripts.

Updated Sep 15, 2026
One-click install
npx skills add https://github.com/tomada1114/quick-reply-drill --skill designing-errors-tomada1114
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: designing-errors
Source: https://github.com/tomada1114/quick-reply-drill/tree/main/.agents/skills/designing-errors
Command: npx skills add https://github.com/tomada1114/quick-reply-drill --skill designing-errors-tomada1114

SYSTEM DOCUMENTATION & REQUIREMENTS

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.

Frequently Asked Questions about designing-errors

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a custom Error class in TypeScript?▼

Subclass Error, set this.name to the class name in the constructor, and declare readonly code as a literal type rather than string. Keep the underlying failure on the cause property instead of folding it into the message.

How should I name error codes in a TypeScript project?▼

Use an ERR_ prefix with SCREAMING_SNAKE_CASE describing the failure, not the function that raised it, such as ERR_LLM_TIMEOUT. Under src/** the prefix names the owning layer; under scripts/** it names the check's stage, like ERR_AGENTS_*.

Should callers match on error message or error code?▼

Callers should branch on code or use instanceof on the class, never on message text. The code is a stable string literal contract, while message is prose for humans that may be reworded at any time.

What data should an error object never contain?▼

An error must never carry credentials, API keys, prompts, model outputs, or parsed request bodies, because errors travel into logs, aggregators, and response bodies. Name the shape instead, such as a field path or an exceeded length.

How do I preserve the abort reason when a request is cancelled?▼

Return the caller's reason as the same object rather than wrapping it in a fresh error, so error.cause === myReason identity checks still pass. Helpers like asError and abortedLlmError keep the raw reason on cause.

When should I use a discriminated union instead of one error class?▼

Use a discriminated union keyed on code, or one class per failure, when a function can fail for several structurally different reasons. This lets consumers switch on code and get every field narrowed instead of checking optional fields.