visant-design

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:

Clean

Keep the design. Remove the tells.

1. node <skill-dir>/scripts/check.mjs <ui paths> --url <running app>
2. Fix every finding at its cause. Hiding what a finding points at does not count.
3. 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.
4. Run it again until it is clean. Report what you removed.

End to end

1. See it first. Start the app and run check.mjs as above. Read the screenshots before reading the code. If the app cannot start, say so and fix that first.
2. 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

1. Diagnose from the image. Run foundations.md on the screenshot, in order. List what is wrong, biggest first.
2. Cut before adding. For each element ask which decision it helps. No answer, it goes. Most screens get better by losing things.
3. 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.
4. Look at the result. Run check.mjs again 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.
5. 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. check.mjs runs in Chromium: a custom touch gesture that never ran on a real iPhone goes under what you did not check.

Many screens

Each screen looks right alone, so fixing them one at a time hardens the disagreement. Write the pattern first.

1. See them together. Run check.mjs and put the sister screens' screenshots side by side. List what each one does differently: the same control in another place, another name, another empty state.
2. Write the pattern. A short list in the repo: which control does each job, where it lives, what it is called. If a choice is really the owner's, ask once.
3. Change the shared piece, not each screen. Fix or extract the one component and have the screens import it. A shared piece reaches every screen using it, so list them first and look at all of them after.
4. Then each screen, from step 3 of End to end. Report the pattern with the work.

Single topic

Before writing a component, check the repo's primitives, then @visant/ui.

Neighbors

• Feedback: when the work is delivered, ask once per session, in one line, what helped and what was missing; it goes to https://ui.visantlabs.com/skills#feedback
• [[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