fortify

Designs edge cases, error states, and recovery flows for real-world product conditions.

Updated Jul 21, 2026
One-click install
npx skills add https://github.com/rakedzior/rootine --skill fortify-rakedzior
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fortify
Source: https://github.com/rakedzior/rootine/tree/main/agent/skills/fortify
Command: npx skills add https://github.com/rakedzior/rootine --skill fortify-rakedzior

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Most designs only cover the happy path, leaving users stranded when data is missing, networks fail, sessions expire, or content overflows. This Skill systematically identifies every non-ideal condition a product will face and designs states, messages, and recovery paths for each one. ## Core Features & Use Cases - State Inventory: Enumerates default, empty, loading, partial, error, success, offline, disabled, and overflow states for every screen, defining what the user sees, can do, and how they recover. - Error Recovery & Stress Testing: Provides recovery patterns (inline recovery, retry logic, graceful degradation, undo, draft preservation) plus structured stress prompts covering content, volume, time, network, device, and user behavior extremes. - First-Run & Latency Design: Covers progressive onboarding, value-first experiences, skeleton screens, optimistic UI, and graduated timeout messaging. - Use Case: Before shipping a checkout flow, run the stress test prompts to discover what happens when payment times out, the cart session expires, or the user opens the flow in two tabs, then design each failure state with a concrete recovery action. ## Quick Start Ask the AI to run an edge case review on your checkout flow and produce a state inventory with recovery actions for every failure mode.

Frequently Asked Questions about fortify

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design error states for a product flow?

Start by classifying errors into validation, system, network, permission, and timeout types, since each needs different messaging and recovery. Then define what the user sees, what they can do, and how they recover, avoiding generic messages like "Something went wrong."

How to stress test a UX design for edge cases?

Run structured prompts across six categories: content extremes, volume extremes, time and latency, network conditions, device constraints, and unpredictable user behavior. Record each scenario as pass, fail, or untested, then prioritize fixes by user impact.

What states should every screen design include?

Beyond the default state, design empty, loading, partial, error, success, offline, disabled, and overflow states. For each one, specify what the user sees, what actions remain available, and the recovery or progress path.

Does this cover accessibility and WCAG compliance?

No, accessibility methodology and assistive technology requirements belong to a separate inclusion-focused skill. This Skill overlaps on real-world conditions like slow connections and small screens but does not own WCAG frameworks or screen reader experience design.

When should I not use optimistic UI patterns?

Avoid optimistic UI for payments, deletions, and other irreversible operations where rollback is not graceful. Reserve it for low-risk actions like toggling favorites or reordering lists, where a server rejection can be rolled back with a clear explanation.