error-recovery
Error Handling
When to Use
- Implementing input validation at system boundaries
- Designing error responses for APIs or user interfaces
- Building recovery mechanisms for transient failures
- Establishing logging and monitoring patterns
- Distinguishing between errors that need user action vs system intervention
Philosophy
Errors are not exceptional - they are expected. Good error handling treats errors as first-class citizens of the system design, not afterthoughts. The goal is to fail safely, provide actionable feedback, and enable recovery.
Error Classification
Operational Errors
Runtime problems that occur during normal operation. These are expected and must be handled.
More from rsmdt/the-startup
specify-requirements
Create and validate product requirements documents (PRD). Use when writing requirements, defining user stories, specifying acceptance criteria, analyzing user needs, or working on requirements.md files in .start/specs/. Includes validation checklist, iterative cycle pattern, and multi-angle review process.
121analyze
Deep-dive codebase analysis that explains how things actually work — business rules, architecture patterns, auth flows, data models, integrations, and performance hotspots. Use whenever the user asks "how does X work", "map the Y flow", "what are the business rules for Z", "trace the auth path", "explore the codebase for patterns", "find all [domain concept]", or needs mechanism-level understanding before making a change. Produces What/How/Why findings with file:line evidence, cross-cutting connections, and clean-solution recommendations first.
57review
Multi-agent code review with specialized perspectives (security, performance, patterns, simplification, tests)
57specify
Create a comprehensive specification from a brief description. Manages specification workflow including directory creation, README tracking, and phase transitions.
54refactor
Refactor, simplify, or clean up code for improved maintainability without changing business logic
52specify-solution
Create and validate solution design documents (SDD). Use when designing architecture, defining interfaces, documenting technical decisions, analyzing system components, or working on solution.md files in .start/specs/. Includes validation checklist, consistency verification, and overlap detection.
50