new-ux-discovery
Discover UX a codebase can already support
Ask for UX improvements and you get a wish list: ideas that are plausible, unanchored, and — often enough to be the default — already built. The expensive failures are not the bad ideas. They are the good ones that duplicate something already shipped behind a permission, or that add a second word for a thing the codebase already names, or that put a link on the stale half of a fork nobody noticed had two halves.
This skill finds opportunities the way a search finds evidence. It enumerates the surfaces first, sweeps nine signal classes that each have a recipe and a named false-positive check, and then puts every survivor through two gates before it is allowed onto the page: has this already been implemented, and would proposing this create confusion. Candidates that fail are not deleted — they go into a DROPPED section with one reason line each, because the reason is what stops the next agent proposing them again next month.
Two modes share one gate stack and one output contract, differing only in the seed set: pure analysis, which sweeps the whole surface inventory, and riding a change, which takes a blast map and asks what the change just made newly possible. Neither mode builds anything. A discovery run that starts editing files has failed at its own job.