Error Boundary Coverage Auditor

What this skill does

Statically analyzes a React routes/component tree and surfaces subtrees that have no Error Boundary above them. Suggests placement points so a render-time error in one subtree doesn't blank the whole app.

Inputs

• repo_dir: project root.
• Optional routes_file: a known router config (e.g., src/routes.tsx) used as the entry point.
• Optional boundary_imports: array of module paths whose default export is treated as an Error Boundary (default includes react-error-boundary and any local ErrorBoundary component).

Steps

1. Locate Error Boundary definitions: rg -lN 'componentDidCatch|getDerivedStateFromError' <repo_dir> --glob '*.{jsx,tsx}'. Treat each matching component plus the configured boundary_imports as known boundaries.
2. Parse <repo_dir> JSX/TSX files with @typescript-eslint/parser. Build a coarse component tree from import graph + JSX usage.
3. From the entry point (App or the routes file), DFS to every leaf component.
4. For each leaf path (root -> leaf), check if any node along the path is a known boundary. Otherwise, the leaf is "uncovered".
5. Group uncovered leaves by nearest common ancestor; that ancestor is the suggested placement.
6. Identify special candidates: route-level boundaries (one per route), Suspense-paired boundaries (any <Suspense> not wrapped in a boundary), third-party-component boundaries (e.g., wrapping a <MapboxMap>).
7. Emit a markdown report with a placements table: file:line of the suggested ancestor, the leaves it would cover, and a sample wrapper diff.
8. Provide a code snippet for an ErrorBoundary component if none exists yet (using react-error-boundary).

Output

error-boundary-audit.md with: existing boundaries inventory, uncovered leaf list, and prioritized placement suggestions (top by number of leaves covered). Stdout prints the percent of leaves currently covered.

Verification

After applying a suggested placement, run a synthetic-error test: render the wrapped subtree with a child component that throws on mount; confirm the boundary catches it (via ErrorBoundary's onError callback firing). Cross-check by hot-swapping a real component to throw — the page must show a fallback UI instead of going blank. If the app uses react-router data routers, prefer route-level errorElement over component boundaries; surface a note.

Edge cases

• Server components (Next.js App Router): boundaries must be Client Components; flag any boundary candidate not marked "use client".
• Suspense without boundary: an uncaught suspense rejection is fatal; always pair them.
• Top-level boundary at App root: catches everything but loses granularity; recommend route-level boundaries in addition.
• Hooks-only "boundaries" (using useErrorBoundary from react-error-boundary): still need a class boundary upstream; document the requirement.