Menus
Design or critique UI menus — pick the right menu type (dropdown, cascading, contextual, single/multi-select, search, inline) for the action set, and apply item ordering, grouping, labeling, and state best practices. Trigger when the user asks to design or review a menu, dropdown, context/right-click menu, overflow (⋮) menu, or asks how to organize actions into a menu.From its SKILL.md
npx -y skills add Uxcel-Lab/product-skills --skill menusAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
9.7 KB, ~2.1k tokens by cl100k_base, as published. Nobody here has run it
Menus Skill
How this skill behaves (read first)
This is a generative skill. The default failure modes: catch-all dropdowns (unrelated actions dumped into one menu), deep ambiguous nesting (cascading levels users get lost in), and unordered item lists (no prioritization, no grouping, jargon labels). A menu is a curated, ordered set of related actions — when it stops being that, the fix is changing the flow, not adding levels. This skill gates:
- Establish the action set — what actions, how related, how many, selection or command?
- Apply the always-true core — type from structure, priority ordering, grouping, labels, states.
- Surface the context-dependent decisions (cascading, contextual, search-in-menu, shortcuts) with trade-offs.
Then it hands off to ux-heuristics-audit, ux-accessibility-audit, ux-aesthetics-audit, and ux-microcopy-audit for validation.
Scope & composition (per
docs/orchestration-policy.md§9): this skill owns menu structure and anatomy. Peers that own a sub-part (defer — each handles its sub-part if reached):ux-navigationowns where menus live in the overall navigation system (hamburger placement, mega menus, top bar vs. sidebar), andux-selection-controlsowns the choice between menus vs. radio/checkboxes for form selection.
Step 0 — Establish the action set
Ask if not known; state the assumption if proceeding without an answer:
- Commands or selection? Triggering actions (Copy, Delete) vs. choosing values (filter options) — selection menus need selection indicators and single/multi-select decisions; command menus need verbs and possibly shortcuts.
- How many items, how related? A menu only earns its place if the items belong together. Unrelated actions → split or rethink the flow. Very long lists → search menu or a different control.
- Is there sub-structure? Real parent-child categories may justify cascading — but if children multiply, change the user flow instead.
- Platform — contextual (right-click) menus are desktop-native; multiselect menus are hard on mobile; hover states need touch equivalents.
The always-apply core (correct for almost every case)
Pick the type from the structure of the choice
- Basic dropdown — one pick from a simple list; closes on selection.
- Single-select — mutually exclusive options with a clear selection indicator (checkmark, bold, overlay). Don't use it to launch modals or dynamic controls.
- Multiselect — checkboxes/tags for combinable options; selected items always visible and removable in the menu input — never force backtracking to deselect.
- Search menu — long lists (countries, languages): auto-suggest filtering as users type.
- Contextual menu — frequent actions for the clicked element (right-click/long-press), appearing at the pointer, options varying by target.
- Inline / overflow (⋮) menu — per-row actions in tables and lists (Edit, Delete, Download) without leaving the view.
- Cascading menu — only for genuinely categorized actions (New → document types); see the gated table.
Order and group — this is where menus are won
- Most-used items at the top. Don't hide critical options behind extra levels when space exists; working memory holds ~5–9 items, so the primary list carries the important actions, the rest go a level down or out.
- Dividers cluster related items — pale lines, not separate menus; grouping makes the list scannable without clutter.
- Scrolling is a smell: a scroll bar is mandatory if you scroll, but beyond a couple of wheel-turns of options, add search or change the flow.
Labels and icons
- Labels say what happens — short, conventional ("Paste," not "Insert"), no jargon or wordplay; truncate unavoidable long labels with tooltip access; a wrapped label is a label that needs rewriting. Test labels (card sorting) — what's clear to you confuses users.
- Leading icons before labels (LTR) — familiar, universal icons only (scissors = Cut); unfamiliar icons slow users down more than no icon.
- Familiar selection marks — checkmark or ×; nothing inventive.
States and behavior
- Hover/focus feedback on every item (subtle overlay, elevation, or border) and visible states for selected/disabled.
- Predictable open/close: opens on tap/click, closes on outside click. No surprises.
- Items ≥48×48px with comfortable padding — legibility and motor-impairment access.
- Elevation (~8dp) separates the menu from the page — it should read as a floating, actionable surface.
The context-dependent decisions (surface, don't auto-apply)
| Decision | Apply when | Avoid / adapt when | Default recommendation |
|---|---|---|---|
| Cascading menu | True parent-child action categories; desktop, with room to unfold | Many/deep children (cumbersome, overwhelming); mobile; tight layouts — check unfold space with mockups | One child level max; if it grows, restructure the flow |
| Contextual (right-click) menu | Desktop power workflows; element-specific frequent actions | As the only access to a function (undiscoverable); touch-first products | Context menu as accelerator; every action also reachable visibly |
| Search inside the menu | Long lists where scrolling is tedious | Short lists (overhead) | Add when the list exceeds a couple of scroll-turns |
| Keyboard shortcuts shown in the menu | Productivity tools with repeat actions (copy/cut/paste) | Inventing non-standard shortcuts; shortcut-only access | Standard shortcuts on the most common commands, displayed in the menu |
| Multiselect pattern | Hotkey+click, checkboxes, or tag collection — pick by audience and platform | Hotkey-based multiselect on mobile or for casual audiences | Checkboxes/tags; selections visible and removable in place |
| Icon-only inline menus (⋮) | Dense tables needing per-row actions | Burying the row's single most important action in the overflow | Primary row action visible; secondary actions in ⋮ |
Validate the result (orchestration)
Hand-offs name each lens by its installable skill
name. Invoke one only if that skill is installed; if it isn't, this skill's own core already carries these rules — proceed without it rather than blocking.
After generating or revising, hand the result to the audit lenses rather than declaring it done. These are candidate lenses — posture is set by docs/orchestration-policy.md, or route the whole thing through ux-design-review. Here, heuristics and microcopy are Tier A (auto-run); accessibility, aesthetics, information-architecture, and mobile-responsiveness are Tier B (offered) — under an existing design system aesthetics is suppressed and accessibility narrows to usage; mobile-responsiveness applies only on mobile. If the user invoked this skill for one specific thing, respect that scope.
ux-heuristics-audit(Tier A) — recognition over recall (visible critical options), consistency of behavior, user control (easy deselection, predictable dismissal).ux-accessibility-audit(Tier B — offer; narrow under a design system) — keyboard navigation through items, 48px targets, contrast of labels and dividers, non-hover access to everything.ux-aesthetics-audit(Tier B — offer; suppress under a design system) — spacing, elevation, grouping rhythm; whether the menu reads as one clean surface.ux-microcopy-audit(Tier A) — label clarity, conventional verbs, truncation choices.ux-information-architecture-audit(Tier B — offer) — whether the menu's grouping, depth, and label system match user mental models and carry information scent; this skill structures the menu surface, IA owns the category model behind it.ux-mobile-responsiveness-audit(Tier B — offer; applies only on mobile) — when the context is mobile: touch targets, no hover-dependence, multiselect pattern fit.
If the audits surface a conflict (e.g., completeness vs. scannability), resolve back toward the primary task: the user opens a menu to act fast — every item competes for the same scan.
Common do/don't patterns
| ❌ Don't | ✅ Do |
|---|---|
| One dropdown holding every miscellaneous action | Related actions only; restructure when it stops being a set |
| Three levels of cascading children | One child level; if it grows, change the flow |
| Alphabetical order regardless of use | Most-used first; secondary items a level down |
| Flat list of 14 ungrouped items | Dividers clustering related actions |
| "Insert" when everyone says "Paste" | Conventional, tested labels |
| Decorative or clever icons per item | Universal icons only — or no icon |
| Right-click as the only way to delete | Contextual menu as accelerator, visible path exists |
| Deselecting requires reopening and hunting | Selected items shown and removable in place |
| Menu stays open on outside click | Standard open/close behavior |
| 32px cramped rows | ≥48px items with breathing room |
| Ship without checking | Hand off to heuristics + accessibility + aesthetics + microcopy |
Source lessons (Uxcel)
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.