Error handling resilience
Skill JeremyMorgan/code-review-skills/skills/error-handling-resilience
Performs a comprehensive error-handling review across the codebase, checking coverage, propagation, and recovery. Use when auditing how the system handles and recovers from failures.From its SKILL.md
npx -y skills add JeremyMorgan/code-review-skills --skill error-handling-resilienceAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as CC0-1.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
1.9 KB, as published. Nobody here has run it
Target: $ARGUMENTS
If no target path is given above, review the entire codebase.
Evaluate this entire software package.
Perform a comprehensive error handling review:
Evaluate:
-
ERROR HANDLING CONSISTENCY
- Is there a centralized error handler?
- Are errors handled uniformly?
- Custom error classes vs generic errors?
-
ERROR CATEGORIES
- Validation errors (400)
- Authentication errors (401)
- Authorization errors (403)
- Not found errors (404)
- Server errors (500)
- Rate limit errors (429)
- Are they properly categorized?
-
ASYNC ERROR HANDLING
- Unhandled promise rejections
- Async middleware wrapper usage
- Callback error handling
- Event emitter error handling
-
ERROR RECOVERY
- Graceful degradation
- Retry mechanisms
- Circuit breakers
- Fallback strategies
-
ERROR INFORMATION
- Development vs production error details
- Stack trace exposure
- Error logging completeness
- User-friendly error messages
Identify error handling gaps and provide improved implementation.
Provide:
A structured finding report
A scale of 1/10 on how important each finding is
Remediation: precise code-level fix or config change (snippets welcome) if possible
Constraints & style:
Be concrete and cite exact code locations and identifiers.
Prefer minimal, drop-in fix snippets over prose.
Do not invent files or functions that aren’t present; if context is missing, mark as Unable to verify and say what code would prove it.
Write this into a markdown file and place it in the audits/ folder.