error-handlinglisted

# Error Handling Patterns Skill Enforce consistent error handling across all projects. Flag anti-patterns proactively. ## When This Activates - Writing try/catch blocks - Creating API error responses - Implementing form validation - Writing async/await operations - Adding error boundaries ## API Error Response Format All API errors must follow this shape: ```typescript { success: false, error: { code: "VALIDATION_ERROR", // Machine-readable error code message: "Email is required", // Human-readable message details?: [...] // Optional field-level errors } } ``` **Status codes:** - `400` - Validation error (bad input) - `401` - Not authenticated - `403` - Not authorized (authenticated but insufficient permissions) - `404` - Resource not found - `409` - Conflict (duplicate, stale data) - `422` - Unprocessable entity (valid syntax, invalid semantics) - `429` - Rate limited - `500` - Internal server error (never expose stack traces) ## Async/Await Error Handling ```typescript // Good: specific error handling with context try { const user = await db.user.findUnique({ where: { id } }); if (!user) throw new NotFoundError("User", id); return user; } catch (error) { if (error instanceof NotFoundError) throw error; throw new DatabaseError("Failed to fetch user", { cause: error }); } // Bad: silent catch, generic catch, no rethrow try { await fetchData(); } catch (e) {} // Silent failure try { await fetchData(); } catch (e) { r