/interaction-review
Use to evaluate or design a user interaction flow — states, edge cases, microinteractions, motion, and feedback patterns.
$ npx -y skills add getcrew44/crew44 --skill interaction-review --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/interaction-review
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use to evaluate or design a user interaction flow — states, edge cases, microinteractions, motion, and feedback patterns.
SKILL.md
interaction-review.SKILL.mdname: interaction-review
description: Use to evaluate or design a user interaction flow — states, edge cases, microinteractions, motion, and feedback patterns.
Interaction Review
Make sure every state a user can land in has been considered, and that motion serves the user rather than decorating.
State coverage map
For each user-facing surface, walk through:
| State | Question | |-------|----------| | Loading | What does the user see while waiting? Is it clear progress is happening? | | Empty | What does the user see with zero results, zero items, zero history? Does the empty state guide the next action? | | Error | When the network or backend fails, can the user understand what happened and recover? | | Success | Is feedback clear and the next action obvious? | | Partial | When the operation half-succeeded, is the partial result accurately reported? |
Edge cases to test
- 47-character name. 200-character name. Empty name.
- Zero results. One result. Ten thousand results.
- First-time user. Power user with their own muscle memory.
- Slow connection. Offline. Back button mid-action. Double-click on a critical button.
Motion principles
Motion should communicate, not decorate. Every animation answers one of: confirm an action occurred, orient where things came from or go to, focus attention on a change, or preserve context during a transition. If it does none of these, cut it.
Use a timing scale:
- 100–150 ms: micro-feedback (hovers, clicks)
- 200–300 ms: small transitions (toggles, dropdowns)
- 300–500 ms: medium transitions (modals, page changes)
- 500 ms+: complex choreography only
Prefer spring or ease-out for entrances, ease-in for exits, transform/opacity for performance. Honor `prefers-reduced-motion`.
Microinteraction checklist
- Buttons: hover, press, focus, disabled, loading — each visually distinct, none flicker.
- Inputs: default, focus, error, disabled, success — clear path back from error.
- Toggles and switches: state change is visible at a glance, not just a color shift.
- Drag, swipe, scroll-triggered: discoverable, reversible, non-blocking.
Output
- Specific gaps in state coverage, with the user-visible consequence.
- Specific edge cases not handled.
- Motion that decorates rather than communicates.
- Recommendations sized by impact, not effort.
Read more
name: interaction-review description: Use to evaluate or design a user interaction flow — states, edge cases, microinteractions, motion, and feedback patterns.
Interaction Review
Make sure every state a user can land in has been considered, and that motion serves the user rather than decorating.
State coverage map
For each user-facing surface, walk through:
| State | Question | |-------|----------| | Loading | What does the user see while waiting? Is it clear progress is happening? | | Empty | What does the user see with zero results, zero items, zero history? Does the empty state guide the next action? | | Error | When the network or backend fails, can the user understand what happened and recover? | | Success | Is feedback clear and the next action obvious? | | Partial | When the operation half-succeeded, is the partial result accurately reported? |
Edge cases to test
- 47-character name. 200-character name. Empty name.
- Zero results. One result. Ten thousand results.
- First-time user. Power user with their own muscle memory.
- Slow connection. Offline. Back button mid-action. Double-click on a critical button.
Motion principles
Motion should communicate, not decorate. Every animation answers one of: confirm an action occurred, orient where things came from or go to, focus attention on a change, or preserve context during a transition. If it does none of these, cut it.
Use a timing scale:
- 100–150 ms: micro-feedback (hovers, clicks)
- 200–300 ms: small transitions (toggles, dropdowns)
- 300–500 ms: medium transitions (modals, page changes)
- 500 ms+: complex choreography only
Prefer spring or ease-out for entrances, ease-in for exits, transform/opacity for performance. Honor `prefers-reduced-motion`.
Microinteraction checklist
- Buttons: hover, press, focus, disabled, loading — each visually distinct, none flicker.
- Inputs: default, focus, error, disabled, success — clear path back from error.
- Toggles and switches: state change is visible at a glance, not just a color shift.
- Drag, swipe, scroll-triggered: discoverable, reversible, non-blocking.
Output
- Specific gaps in state coverage, with the user-visible consequence.
- Specific edge cases not handled.
- Motion that decorates rather than communicates.
- Recommendations sized by impact, not effort.
Orchestrate a crew of specialist AI agents in one local-first workspace. Each role on its best model, with memory and skills that compound. Free, MIT.
Repo: getcrew44/crew44
Other skills on crew44.
- /brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Open skill - /executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Open skill - /finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Open skill - /receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Open skill - /requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Open skill - /systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Open skill

