Visant Design
Takes "clean the slop" or "improve the UX" to a finished screen you have looked at. Rulebooks can't see your product or your result; this process makes you see both.
<skill-dir> is the folder holding this file. Other playbooks are next to it: read ../<name>/SKILL.md. If one is missing: npx skills add pedrojaques99/visant-skills-public --skill <name>.
Work to the end without stopping to ask. Ask only what the code cannot answer and would change what gets built. Follow the product's own design system and components; only create a new one if nothing exists.
Pick one track:
| The ask | Track |
|---|---|
| "Clean the slop", "looks AI-made", remove the tells | Clean |
| "Improve", "redesign", "UI/UX end-to-end", "this looks bad" | End to end |
| "Audit", "review", "is this good" | visant-killer, and change nothing |
| One detail: motion, chart, panel, component demo | Single topic |
Clean
Keep the design. Remove the tells.
node <skill-dir>/scripts/check.mjs <ui paths> --url <running app>- Fix every finding at its cause. Hiding what a finding points at does not count.
- Read the images. Fix the tells no detector sees: decorative gradients, purple as "AI", glow, emoji as icons, cards in cards, eyebrow labels over every heading, hype words, invented numbers.
- Run it again until it is clean. Report what you removed.
End to end
- See it first. Start the app and run
check.mjsas above. Read the screenshots before reading the code. If the app cannot start, say so and fix that first. - Name the job. Write one line per screen: who arrives, what they came to do, which number moves. Read the file for that surface:
- Landing, pricing, signup, onboarding: acquisition
- Queue, table, editor, admin: work
- Payment, permission, deletion, money: trust
- Diagnose from the image. Run foundations.md on the screenshot, in order. List what is wrong, biggest first.
- Cut before adding. For each element ask which decision it helps. No answer, it goes. Most screens get better by losing things.
- Build. The product's tokens and components first. Motion and data get their playbook only if this screen needs them. Write copy from what the product really does; a number you don't have stays a visible placeholder.
- Look at the result. Run
check.mjsagain and read the new screenshots at every width, next to the old ones. Ask the most exacting designer's question: what would I screenshot and send back? Fix the biggest thing and repeat, up to three rounds. - Report. What changed and which number each change is meant to move; what you cut and why; the widths you looked at; what you did not check. A redesign is a hypothesis: say how to measure it.
If check.mjs says NOT VERIFIED, the first line of your answer says so. The work is not done. Stop any server you started.
Single topic
| The ask | Read |
|---|---|
| Animation, transition, loading, skeleton | visant-motion |
| Chart, gauge, slider, metric tile, control panel | visant-refine |
| Hierarchy or what to remove on one screen | visant-frontend |
| Too cluttered, too many labels | declutter |
| Component demo, library page, mock product | component-showcase |
| Fake product UI for a hero, cursor demo | stageshow, third party: npx skills add benjitaylor/skills --skill stageshow |
Before writing a component, check the repo's primitives, then @visant/ui.
Neighbors
- [[visant-killer]]: audit what exists
- [[visant-frontend]]: decide what should exist
- [[visant-motion]]: how it moves
- [[visant-refine]]: data and controls
- [[stageshow]]: a fake product UI for a hero or feature card
- [[visant-copy]]: the words on the screen
- [[visant-preflight]]: a large client project, before any screen
