interaction-feedbacklisted

# Interaction Feedback ## Coverage Design feedback states for user actions and system changes. Covers immediate click feedback, loading indicators, skeletons, optimistic UI, pending and disabled states, progress, success confirmation, persistent errors, retry, undo, autosave, long-running jobs, empty and low-data states, and perceived-latency staging. ## Philosophy Feedback is the user's proof that the system heard them. Without it, users repeat actions, abandon flows, or assume data was lost. Good feedback is honest about uncertainty and gives recovery paths when the system cannot complete the action. Feedback is not the same as performance. A fast system still needs confirmation, and a slow system still needs staged truth. ## Method 1. Name the action or state change that needs feedback. 2. Classify expected duration: instant, short, medium, long, background, or unknown. 3. Decide the feedback surface: inline state, button state, skeleton, banner, toast, progress row, modal, or job history. 4. Define transitions: idle, pending, partial, success, failure, retrying, cancelled, and undoable. 5. Preserve user control for long or destructive actions: cancel, retry, undo, leave-and-return. 6. Hand off wording to `microcopy` and announcement mechanics to `a11y`. 7. Verify the user can tell whether work is still happening, done, failed, or recoverable. ## Evals This skill ships a comprehension-eval artifact at [`examples/evals/interaction-feedback.json`](https://github.com