What this prompt does
This prompt makes the AI act as a senior software architect and design a production-grade error handling strategy for a [app_type] built with [tech_stack]. It works through five ordered steps: a custom exception hierarchy, a consistent error response format, a logging and monitoring strategy, retry and circuit-breaker policies, and finally a complete code implementation. The result is not advice in the abstract; it is a typed exception system with machine-readable codes you can actually drop into a real codebase.
The structure works because each step constrains the next. The exception hierarchy assigns every error a class name following [language] conventions, an HTTP status, a stable code like AUTH_001, a retryable-or-terminal flag, and a log level. The response format for [api_style] then standardizes how those errors reach clients while forbidding stack traces, SQL, or internal paths from leaking. [additional_domain] lets you add a domain the defaults miss, and [timeout_context] names the dependencies that need explicit timeout and circuit-breaker values. This is what makes an app debuggable at 2 a.m. instead of a guessing game.
When to use it
- You are building a new API and want error handling designed before features pile up
- Your current errors leak stack traces or SQL to clients and you need to lock that down
- You need stable, machine-readable error codes for an SDK or external consumers
- You want retry with exponential backoff and circuit breakers for flaky dependencies
- You need structured logging with correlation IDs and sane alert thresholds
- You want copy-paste-ready middleware, formatters, and unit tests, not just a description
Example output
You get a five-part deliverable: a table of exception classes with their codes, statuses, and log levels; a documented error response schema for [api_style]; a logging and alerting plan; per-dependency retry and circuit-breaker policies; and the full [tech_stack] implementation including base exception classes, a global handler or middleware, a response formatter, controller usage, and unit tests per exception type.
Pro tips
- Set
[tech_stack]and[language]precisely so class names and middleware match your framework's conventions - Use
[api_style]to pin the response shape; specifying RFC 7807 Problem Details gives you a documented standard - Add the domain your app actually has via
[additional_domain](file uploads, billing) rather than accepting the default - List every flaky dependency in
[timeout_context]so each gets its own timeout and breaker threshold - Ask it to verify no response example exposes internal paths before you trust the output
- Treat the generated tests as a starting point and run them; AI-written assertions still need to actually pass
