---
name: Error Audit
slug: error-audit
category: Quality
description: Error Audit scans code for swallowed exceptions, silent fallbacks, compatibility shims, and missing UI error states. Use it when auditing a scope to ensure failures are surfaced to the user.
github: "https://github.com/markmdev/meridian/tree/main/skills/error-audit"
language: Python
stars: 183
forks: 22
install: "npx degit https://github.com/markmdev/meridian/tree/main/skills/error-audit ~/.claude/skills/error-audit"
installs_to: ~/.claude/skills/error-audit
source_path: skills/error-audit/SKILL.md
collection_size: 6
category_size: 1745
collection_url: "https://dirskills.com/collections/markmdev/meridian"
added: 2026-09-06T05:20:57.961Z
last_synced: 2026-09-06T05:20:57.961Z
canonical_url: "https://dirskills.com/skills/error-audit"
---

# Error Audit

Error Audit scans code for swallowed exceptions, silent fallbacks, compatibility shims, and missing UI error states. Use it when auditing a scope to ensure failures are surfaced to the user.

**Install:**

```bash
npx degit https://github.com/markmdev/meridian/tree/main/skills/error-audit ~/.claude/skills/error-audit
```

## README

# Error Audit

The core principle: **every error belongs to the user**. Not to a catch block, not to a console, not to a null return. Scan the specified code, fix every violation, report what changed.

## Step 0: Understand the app's error mechanisms

Before fixing anything, identify how this app surfaces errors to users — toast notifications, error banners, error boundaries, returned error states, alert dialogs, inline messages. Use these patterns exclusively. Don't invent a new one.

## Anti-patterns to find and fix

**Silent error swallowing — backend/logic layer:**
- Empty catch blocks: `catch(e) {}`
- Log-and-continue: `catch(e) { console.error(e) }` with execution proceeding normally
- `.catch(() => {})` on promises
- Functions returning `null`, `undefined`, or empty defaults on failure instead of throwing

**Silent error swallowing — UI layer:**
- Data fetching catches an error and returns null/empty → component renders blank with no explanation
- Error boundaries that catch but show nothing (or a generic "something went wrong" with no recovery path)
- `try/catch` in a loader or server action that swallows the error and returns partial/empty data
- Async operations where the UI has no error state at all — success renders fine, failure renders identical to loading or empty

**Fallbacks to degraded alternatives:**
- Catch → silently switch to a worse model, API, or service
- Catch → return cached or stale data without telling the user
- Catch → offline/degraded mode with no visible indication

**Backwards compatibility shims:**
- `if (legacyFormat)` or `if (oldVersion)` branches
- Deprecated fields still being populated alongside new ones
- Old code paths running in parallel with new ones

**Config defaults that hide misconfiguration:**
- `process.env.X || 'fallback'` for required values — missing required config is a startup crash, not a default
- Optional environment variables that should be required

**Optional chaining hiding missing required data:**
- `user?.profile?.name ?? 'Guest'` when profile must always exist — the absence is a bug, not an edge case to handle silently

## Fix principles

- Throw or re-throw rather than catch-and-continue
- In the UI: every error path must render something visible — use the app's established error display mechanism
- Required config missing at startup → log a clear message and exit
- Delete fallback branches — don't comment them out
- When unsure if a fallback was intentional, flag it in your report rather than guessing

## Reference files
- `references/error-patterns.md` — Concrete anti-patterns with structural descriptions, bad/good code examples, and false positive notes. Read this before starting the audit.

## Report

After fixing, summarize by file: what was found, what the fix was. Be specific — file paths and the pattern removed.