dependency-outage-auditlisted

# Dependency Outage Audit ## Install Save this file as `~/.claude/skills/dependency-outage-audit/SKILL.md`, or `.claude/skills/dependency-outage-audit/SKILL.md` to scope it to one repo. Claude Code auto-discovers it. Invoke with `/dependency-outage-audit` or by asking "what breaks if my database goes down?". ## Why this exists Most apps have never been tested with their database unavailable. The first real outage is the experiment, it runs in front of customers, and the result is usually worse than anyone expected: not one broken feature, but every page at once, because a single unguarded call in a shared layout or helper takes down surfaces that did not need that data at all. Two failure modes cost the most, and both are invisible from a status dashboard: 1. **A read-only page dying for a write-path dependency.** Browsing a catalog does not need a live database on every request, and yet it usually does. 2. **Failing at HTTP 200.** A page that renders an error boundary still returns 200. Uptime monitors see success. Crawlers store the empty page as your content. You find out weeks later, from a human. ## Step 1 — Inventory what each public page actually needs ``` rg --files -g '**/page.tsx' -g '**/page.jsx' -g '**/+page.svelte' -g 'pages/**/*.tsx' ``` For each page, list its data calls, following helpers rather than trusting names. A page calling `getProduct()` may pull five queries three levels down. ``` rg -n "await (prisma|db|sql|supabase|fetch|redis)\."