Error Handling and Silent-Failure Audit
Find swallowed errors and fix them: classify each failure, retry only safe ones, log once with context, show users a safe message.
Before & after
Same prompt, same agent — the only difference is the skill.
I'll create a signup flow for you. I can add basic error handling to make sure things don't break silently. That's definitely important — errors can be confusing for users if they're not handled properly. I can include try-catch blocks and some logging so that if something goes wrong, you'll be able to see what happened. Would you like me to include any specific error messages for the user? And do you have a particular logging tool you use? Once I know that, I can generate the code with the appropriate error handling patterns baked in.
SIGNUP FLOW WITH CONSISTENT ERROR HANDLING:
ERROR HANDLING PATTERN (applied throughout):
function validateEmail(email) {
try {
const result = emailValidator.check(email);
if (!result.valid) {
logger.warn('signup:validation_failed', { field: 'email', reason: result.error });
return { success: false, userMessage: 'Enter a valid email address' };
}
return { success: true };
} catch (error) {
logger.error('signup:email_validation_error', { error: error.message, stack: error.stack });
return { success: false, userMessage: 'Email validation service down. Try again in 30 seconds.' };
}
}
SIGNUP FLOW SECTIONS:
→ Email validation: Logs failed attempts + invalid formats, retries up to 3 times with exponential backoff
→ Password strength check: Errors logged but not exposed to user (prevents brute-force leaking)
→ Account creation API call: Catches rate limits (429), service outages (500), and missing fields, returns user-facing message + auto-retry after 5 seconds
→ Email confirmation: Timeout after 60 seconds logged as 'email_send_timeout', user sees retry option
LOGGING OUTPUT: Every error tagged by component and failure type. Silent failures = zero. Users see appropriate next steps; ops team gets full trace.About this skill
Your code returns None when the API is down. A catch {} hides the real bug until it surfaces three modules away. One error shows up in the logs four times, and a retry loop just double-charged a customer. This skill makes Claude treat each failure point as a decision. It decides whether the failure is an expected outcome, a transient fault, or a bug, and handles each one differently.
What it does
- Audits pasted code for silent-failure patterns: empty catches,
except: pass,.catch(() => {}), ignored Go errors,returninsidefinally,?? []defaults that mask outages, and unawaited promises. - Classifies every failure point as an expected outcome, a transient fault, or a bug, then applies the matching handling: a typed error, a bounded retry, or propagation to one top-level handler.
- Writes retries that are safe. It adds explicit timeouts, exponential backoff with jitter, and a total deadline, honors Retry-After, keeps retries in a single layer, and refuses to retry non-idempotent calls without an idempotency key.
- Preserves the cause chain with each language's idiom:
raise ... from,{ cause },%w,.context(). It logs each error once, at the boundary that handles it. - Maps internal errors to safe user-facing messages and HTTP statuses, with a request ID so support can find the log line.
What you get
A findings table that lists each problem, its real-world consequence, and the fix. You also get patched code and a short error contract showing who handles each failure, what the user sees, and what gets logged.
Best for
Developers shipping AI-generated or legacy code that touches networks, databases, files, or payments, and anyone tired of debugging failures that left no trace.
SKILL.md preview
---
name: error-handling-silent-failure-audit
description: Finds and fixes silent failures in code, and writes new code with an explicit error contract. It classifies each failure as an expected outcome, a transient fault, or a bug, then applies the matching handling: a typed result, a bounded retry with timeout and jitter, or propagation to one top-level handler that logs once with full context. Use when the user says "add error handling to this", "review this for swallowed exceptions", "my app fails silently", "the same error gets logged four times", "add retries to this API call", "why does this return None instead of failing", "what should the user see when this breaks".
---
… (sign up to view the full skill)More development skills
View all Development skills →Performance Bottleneck Profiling: Node, Python, Go
Classifies a slowdown, gives exact profiler commands, reads the output, and proves the fix with same-conditions p95/p99 numbers.
Feature Scaffolding with Working Tests
Turn a short feature spec into code, runnable tests, and integration wiring that match your existing project.
Feature Flag Rollouts and Kill Switches
Design staged flag rollouts, verify rollback paths, and audit flag debt with explicit defaults, gates, and retirement plans.
Microcontroller Firmware and RTOS Engineering
Build and debug MCU firmware with bounded ISR/RTOS timing, safe DMA ownership, and measured power budgets.