What problem does it solve? Backend services need consistent, structured error handling where every domain or application failure maps to a stable error code, an HTTP status, and a frontend translation. Without a registry pattern, ad-hoc errors silently fall through to HTTP 500 and leak inconsistent responses across handlers. ## Core Features & Use Cases - Runtime error registry: Core exposes registerErrorCodes (TypeScript) and RegisterErrorCodes (Go); each bounded context plugs in its own codes at startup without core ever importing from contexts. - Language-specific playbooks: A dispatch hub routes to the TypeScript variant (type unions, BaseError<T> generics, side-effect imports in registry.ts) or the Go variant (typed errors.ErrorCode consts, init() registration, anonymous imports in module.go). - Pattern and bad-practice registries: registry.yaml files codify mandatory patterns (ERR-01 through ERR-P10, ERR-GO-01 through ERR-GO-05) and mechanical detection rules for violations like unregistered codes or fmt.Errorf misuse. - Use Case: When adding a new INVOICE_NOT_FOUND error to a billing context, the skill guides declaring the typed code, registering its 404 status, wiring the side-effect import, and adding frontend translations in pt.json and en.json. ## Quick Start Ask the agent to define and register a new domain or application error code for a specific bounded context, and it will follow the TypeScript or Go playbook matching the file you are editing.