# Interaction Engine > Design interaction contracts, feedback, motion, timing, direct manipulation, interruption, cancellation, and recovery. Use when specifying or reviewing how an interface responds to input, choosing whether and how to animate, or fixing behavior that feels unresponsive or theatrical. - Skill: `dragoon0x/interaction-engine` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add dragoon0x/interaction-engine` - Raw SKILL.md: https://api.skillmd.com/api/skills/dragoon0x/interaction-engine/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: dragoon0x (https://skillmd.com/u/dragoon0x) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dragoon0x/interaction-engine --- # Interaction Engine ## Mission Make software respond to intent with clarity, continuity, and appropriate energy. ## Interaction contract For every meaningful interaction define intent, trigger, immediate response, resulting state, completion signal, cancellation, failure, and recovery. ## Feedback After an action the interface should answer the user's current question: did it register, is it happening, did it complete, or what can I do after failure? ## Frequency Frequent interactions deserve quiet, fast feedback. Rare interactions may justify richer explanation. Repeated theatrical motion is friction. ## Motion gate Animate for spatial continuity, state communication, feedback, direct manipulation, orientation, or explanation. If motion has no meaningful purpose, omit it. ## Timing Choose duration based on frequency, travel distance, complexity, importance, and interruptibility. Never use one duration globally without considering behavior. ## Easing Direct manipulation should follow input. Transitions should communicate state changes. Entrances should not feel sluggish and exits should not make users wait. ## Interruption Test rapid reversal, double activation, immediate dismissal, state changes during transition, navigation away, focus loss, and pointer release. Avoid visibly restarting from unrelated starting states. ## Direct manipulation For drag/gesture behavior consider pointer capture, ownership, movement mapping, boundaries, resistance, velocity, release, cancellation, and keyboard alternatives where essential. ## Velocity continuity When autonomous motion follows a gesture, preserve the sense of continuity when appropriate. Avoid visible velocity seams. ## Boundaries Use constrained movement, resistance, snap, or feedback when a meaningful boundary is reached. Do not make resistance feel unresponsive. ## Loading Choose immediate feedback, skeleton, progress, activity indicator, or optimistic state based on what users need to understand. Do not use optimistic UI when failure would create unsafe or misleading state. ## Errors Explain what failed, what changed, whether retry/undo exists, and what to do next. ## Cancellation A cancel control should actually cancel or supersede the operation when technically possible. ## Focus Preserve focus intent through overlays, navigation, replacement, async completion, and validation. ## Reduced motion Preserve state comprehension and feedback while removing unnecessary movement. ## Input Verify pointer, keyboard, touch, and assistive technology. Essential behavior must not depend on hover. ## Reference artifact Use `references/interaction-review.md` to review interaction contracts, feedback, motion, interruption, cancellation, focus, and input coverage. ## Completion criteria Intent, feedback, transitions, cancellation, interruption, recovery, and input behavior are coherent and testable. ## Expert Review Protocol ### First pass: understand Before changing anything, identify the actual user outcome, the existing system, the relevant constraints, and the evidence available. Do not begin by choosing a visual treatment. ### Second pass: compare Ask: - What is the simplest credible solution? - What is the strongest alternative? - What does the current solution cost? - What behavior does each option teach the user? - Which decision is easiest to reverse? - Which failure would be most expensive? Choose deliberately. ### Third pass: stress Do not review only the happy path. Apply pressure through: - repetition - interruption - missing content - long content - slow operations - narrow space - large text - keyboard use - touch use - focus changes - error recovery - restoration Use only scenarios that are relevant to the surface. ### Fourth pass: inspect the implementation When code exists, verify that the implementation preserves the interface decision. Look for: - duplicated sources of truth - styling that bypasses the system - state that can become stale - behavior that differs from adjacent components - abstractions that obscure rather than simplify - dependencies that are not earning their cost - performance work performed without evidence ### Fifth pass: critique the result Ask: > If this were shipped tomorrow, what would users notice that the builder has stopped noticing? Look for: - friction - ambiguity - inconsistency - unnecessary movement - weak recovery - hidden state - visual noise - inaccessible behavior - fragile edge cases ### Sixth pass: distinguish polish from substance A useful change improves one or more of: - understanding - speed - confidence - recovery - accessibility - consistency - maintainability If a change improves none of these and only adds decoration, treat it as suspect. ### Seventh pass: verify A claim is complete only when an appropriate form of evidence supports it. Use: - direct interaction - tests - runtime inspection - visual comparison - accessibility checks - performance measurement - source inspection Do not claim a check that did not occur. ### Completion standard Stop when: 1. the intended outcome is achieved 2. important states are handled 3. meaningful failure modes were considered 4. the interface fits its surrounding system 5. important claims are verified 6. remaining imperfections are lower-value than the risk of further change The goal is not maximal polish. The goal is a result that is difficult to improve without changing the underlying decision.