The harden skill strengthens interfaces against edge cases, errors, internationalization issues, and real-world usage scenarios that break idealized designs. It makes interfaces robust and production-ready.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/pbakaus/impeccable/llms.txt
Use this file to discover all available pages before exploring further.
When to Use
Use the harden skill when you need to:- Handle edge cases and extreme inputs
- Improve error handling and recovery
- Add internationalization (i18n) support
- Fix text overflow and wrapping issues
- Prepare an interface for production
- Handle network failures and slow connections
- Support RTL languages and different character sets
- Make the interface resilient to real-world usage
Parameters
The specific feature or area to harden. If not specified, hardens the entire interface.
Important Principle
Workflow
The harden skill follows a systematic approach:Assess Hardening Needs
Identify weaknesses and edge cases:Test with extreme inputs:
- Very long text (names, descriptions, titles)
- Very short text (empty, single character)
- Special characters (emoji, RTL text, accents)
- Large numbers (millions, billions)
- Many items (1000+ list items, 50+ options)
- No data (empty states)
- Network failures (offline, slow, timeout)
- API errors (400, 401, 403, 404, 500)
- Validation errors
- Permission errors
- Rate limiting
- Concurrent operations
- Long translations (German is often 30% longer than English)
- RTL languages (Arabic, Hebrew)
- Character sets (Chinese, Japanese, Korean, emoji)
- Date/time formats
- Number formats (1,000 vs 1.000)
- Currency symbols
Verify Hardening
Test thoroughly with edge cases:
- Try names with 100+ characters
- Use emoji in all text fields
- Test with Arabic or Hebrew (RTL)
- Test with Chinese/Japanese/Korean (CJK)
- Disable internet, throttle connection
- Test with 1000+ items
- Click submit 10 times rapidly
- Force API errors, test all error states
- Remove all data, test empty states
Hardening Dimensions
Text Overflow & Wrapping
Long Text Handling
Flex/Grid Overflow
Responsive Text Sizing
- Use
clamp()for fluid typography - Set minimum readable sizes (14px on mobile)
- Test text scaling (zoom to 200%)
- Ensure containers expand with text
Internationalization (i18n)
Text Expansion
- Add 30-40% space budget for translations
- Use flexbox/grid that adapts to content
- Test with longest language (usually German)
- Avoid fixed widths on text containers
RTL (Right-to-Left) Support
Character Set Support
- Use UTF-8 encoding everywhere
- Test with Chinese/Japanese/Korean (CJK) characters
- Test with emoji (they can be 2-4 bytes)
- Handle different scripts (Latin, Cyrillic, Arabic, etc.)
Date/Time Formatting
Pluralization
Error Handling
Network Errors
- Show clear error messages
- Provide retry button
- Explain what happened
- Offer offline mode (if applicable)
- Handle timeout scenarios
Form Validation Errors
- Inline errors near fields
- Clear, specific messages
- Suggest corrections
- Don’t block submission unnecessarily
- Preserve user input on error
API Errors
Handle each status code appropriately:- 400: Show validation errors
- 401: Redirect to login
- 403: Show permission error
- 404: Show not found state
- 429: Show rate limit message
- 500: Show generic error, offer support
Graceful Degradation
- Core functionality works without JavaScript
- Images have alt text
- Progressive enhancement
- Fallbacks for unsupported features
Edge Cases & Boundary Conditions
Empty States
- No items in list
- No search results
- No notifications
- No data to display
- Provide clear next action
Loading States
- Initial load
- Pagination load
- Refresh
- Show what’s loading (“Loading your projects…”)
- Time estimates for long operations
Large Datasets
- Pagination or virtual scrolling
- Search/filter capabilities
- Performance optimization
- Don’t load all 10,000 items at once
Concurrent Operations
- Prevent double-submission (disable button while loading)
- Handle race conditions
- Optimistic updates with rollback
- Conflict resolution
Permission States
- No permission to view
- No permission to edit
- Read-only mode
- Clear explanation of why
Input Validation & Sanitization
Client-side Validation
- Required fields
- Format validation (email, phone, URL)
- Length limits
- Pattern matching
- Custom validation rules
Server-side Validation (Always)
- Never trust client-side only
- Validate and sanitize all inputs
- Protect against injection attacks
- Rate limiting
Constraint Handling
Accessibility Resilience
Keyboard Navigation
- All functionality accessible via keyboard
- Logical tab order
- Focus management in modals
- Skip links for long content
Screen Reader Support
- Proper ARIA labels
- Announce dynamic changes (live regions)
- Descriptive alt text
- Semantic HTML
Motion Sensitivity
Performance Resilience
Slow Connections
- Progressive image loading
- Skeleton screens
- Optimistic UI updates
- Offline support (service workers)
Memory Leaks
- Clean up event listeners
- Cancel subscriptions
- Clear timers/intervals
- Abort pending requests on unmount
Throttling & Debouncing
Usage Example
Best Practices
DO:- Test with extreme inputs (very long, very short, empty)
- Test in different languages and RTL
- Test offline and with slow connections
- Handle all error scenarios gracefully
- Validate both client-side and server-side
- Use UTF-8 encoding everywhere
- Assume perfect input (validate everything)
- Ignore internationalization (design for global)
- Leave error messages generic (“Error occurred”)
- Forget offline scenarios
- Trust client-side validation alone
- Use fixed widths for text
- Assume English-length text
- Block entire interface when one component errors
Important Notes
You’re hardening for production reality, not demo perfection. Expect users to input weird data, lose connection mid-flow, and use your product in unexpected ways.
