Ux Menus logo

Ux Menus

Organization
Uxcel-Lab
ux-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.

Overview

PublisherUxcel-Lab
Repositoryproduct-skills
Skill nameux-menus
Stars
35
Forks
8
Bundled files
Instructions only
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by Uxcel-Lab on GitHub. Read the source before you install it.

Installation

Install the Ux Menus AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/Uxcel-Lab/product-skills/tree/main/ux/components/menus
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/Uxcel-Lab/product-skills.git /tmp/product-skills
mkdir -p .claude/skills
cp -r /tmp/product-skills/ux/components/menus .claude/skills/ux-menus
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Ux Menus in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Ux Menus on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Ux Menus is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

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:

  1. Establish the action set — what actions, how related, how many, selection or command?
  2. Apply the always-true core — type from structure, priority ordering, grouping, labels, states.
  3. 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-navigation owns where menus live in the overall navigation system (hamburger placement, mega menus, top bar vs. sidebar), and ux-selection-controls owns 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)

DecisionApply whenAvoid / adapt whenDefault recommendation
Cascading menuTrue parent-child action categories; desktop, with room to unfoldMany/deep children (cumbersome, overwhelming); mobile; tight layouts — check unfold space with mockupsOne child level max; if it grows, restructure the flow
Contextual (right-click) menuDesktop power workflows; element-specific frequent actionsAs the only access to a function (undiscoverable); touch-first productsContext menu as accelerator; every action also reachable visibly
Search inside the menuLong lists where scrolling is tediousShort lists (overhead)Add when the list exceeds a couple of scroll-turns
Keyboard shortcuts shown in the menuProductivity tools with repeat actions (copy/cut/paste)Inventing non-standard shortcuts; shortcut-only accessStandard shortcuts on the most common commands, displayed in the menu
Multiselect patternHotkey+click, checkboxes, or tag collection — pick by audience and platformHotkey-based multiselect on mobile or for casual audiencesCheckboxes/tags; selections visible and removable in place
Icon-only inline menus (⋮)Dense tables needing per-row actionsBurying the row's single most important action in the overflowPrimary 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 actionRelated actions only; restructure when it stops being a set
Three levels of cascading childrenOne child level; if it grows, change the flow
Alphabetical order regardless of useMost-used first; secondary items a level down
Flat list of 14 ungrouped itemsDividers clustering related actions
"Insert" when everyone says "Paste"Conventional, tested labels
Decorative or clever icons per itemUniversal icons only — or no icon
Right-click as the only way to deleteContextual menu as accelerator, visible path exists
Deselecting requires reopening and huntingSelected items shown and removable in place
Menu stays open on outside clickStandard open/close behavior
32px cramped rows≥48px items with breathing room
Ship without checkingHand off to heuristics + accessibility + aesthetics + microcopy

Source lessons (Uxcel)

Frequently asked questions

What does the Ux Menus AI skill do?

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.

Why use Ux Menus on TypingMind?

Because you install it once and use it with any model. Ux Menus is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Ux Menus in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/Uxcel-Lab/product-skills/tree/main/ux/components/menus. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Ux Menus?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Ux Menus?

As many as you like. As long as a model supports skills, you can use Ux Menus with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Ux Menus AI skill free?

Yes. It is published on GitHub by Uxcel-Lab under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇