Menus, dropdowns, context menus, and command palettes — do they reveal what is inside, work by keyboard and thumb, and still find things as the list grows?
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: audit every place actions and destinations hide behind a click — menus, dropdowns, context menus, overflow "⋯" buttons, and any command palette — and find the ones that hide too much, cost too much to reach, or fall apart at scale.
Read-only pass. Trigger the menus in the running app or trace their components and handlers; your only write is the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
can a user tell what is inside before opening; the critical action buried in an unlabeled kebab
click and keystroke cost to the common items; the everyday action three menus deep
open, arrow, type-ahead, Escape, and focus return on close; the menu you cannot leave without a mouse
hover-only menus with no tap path; targets too small or too close for a thumb
verb-first, plain-language items; icon-only entries with no accessible name or tooltip
related items grouped, destructive items separated, most-used near the top — not source-code order
the menu at 5 items versus 50: search, sections, or a wall to scroll; the flat list that should be grouped
disabled items that explain why, selected/checked state, loading, and closing on select or outside click
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
List every menu species.
Cite the component and trigger for every finding.
Rank by traffic × cost.
Create MENUS.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:menu-command-surface.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-menu-command-surface:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=130 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/130.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Menu & Command Surface Audit You are working inside this repo. Mission: audit every place actions and destinations hide behind a click — menus, dropdowns, context menus, overflow "⋯" buttons, and any command palette — and find the ones that hide too much, cost too much to reach, or fall apart at scale. Read-only pass. Trigger the menus in the running app or trace their components and handlers; your only write is the report file. ## Phase 1 — Inventory the surfaces - List every menu species: primary/secondary nav menus, select dropdowns, context (right-click) menus, overflow and kebab menus, command palette, action bars. - For each, record how it opens, what it contains, and how it is built (native `<select>`, custom, library). - Note keyboard access, focus handling, and whether items are labeled or icon-only. ## Phase 2 — Audit through 8 lenses Cite the component and trigger for every finding. 1. **Discoverability** — can a user tell what is inside before opening; the critical action buried in an unlabeled kebab 2. **Reachability** — click and keystroke cost to the common items; the everyday action three menus deep 3. **Keyboard & focus** — open, arrow, type-ahead, Escape, and focus return on close; the menu you cannot leave without a mouse 4. **Touch & pointer** — hover-only menus with no tap path; targets too small or too close for a thumb 5. **Labeling** — verb-first, plain-language items; icon-only entries with no accessible name or tooltip 6. **Grouping & order** — related items grouped, destructive items separated, most-used near the top — not source-code order 7. **Scale** — the menu at 5 items versus 50: search, sections, or a wall to scroll; the flat list that should be grouped 8. **State & feedback** — disabled items that explain why, selected/checked state, loading, and closing on select or outside click ## Phase 3 — Curate - Rank by traffic × cost: a hidden or unreachable everyday action outranks a cosmetic ordering nit. - Separate "hidden" (cannot find it), "unreachable" (cannot operate it), and "unruly" (does not scale). - For each, name the surface and the fix — promote, label, group, or make a palette. ## Phase 4 — Report Create `MENUS.md` at repo root: 1. **Menu inventory** — species · trigger · contents · how built · keyboard/touch verdict 2. **Findings** — each: lens · component · what the user cannot do · the fix 3. **Promote list** — actions that should leave a menu for a visible control 4. **The one rule** — the menu convention this codebase should standardize on Start the report with today's date. If `MENUS.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - Every finding names the menu component and how it is triggered - An action nobody can find is an action that does not exist - No menus or command surfaces in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which menu fixes to make
reports/ directory exists at the repo root, write the report there instead of the root.Where the eye actually goes versus where it should — focal points, size and weight and contrast doing real work, and the screens where everything shouts at once.
The type scale, or the lack of one — sizes, weights, line lengths and heights, font loading, and every place text is asked to do a job at the wrong size.
The palette as it actually ships — every hex in the codebase, contrast ratios computed, semantic drift named, and whether dark mode is a theme or an apology.
The spacing scale nobody wrote down — margins and paddings inventoried, grid discipline checked, alignment breaks found, and density judged screen by screen.
Runs inside these playbooks — curated sequences you can launch with one paste: