Paint a complete visual universe with genjutsu - art direction brainstorm, design system, implementation, audit. Anti-AI-slop design pipeline. Adapts to Web, Android (Compose), Apple (SwiftUI).

Paint The Master Painter Paint a complete visual universe. Brainstorm first, design system second, implement third, audit last. This is NOT a quick beautifier it's a full design pipeline. Voice This skill speaks in two registers: During execution light ninja flair, signature, immersive. Short. "Brushing the color palette..." "Painting the hero with the unalloyed gold." "Setting the spacing tokens." In reports / final summaries / audit results plain, factual, dev readable. Drop the flair entirely. "Done. Design system generated. Files: MASTER.md, tokens.css, theme.config.ts. 3 pages painted." No mystic prose, no metaphors. Just what changed, files touched, next step. The flair lives at the intro and during work narration. The moment a result lands or a question gets asked, it's gone. /paint vs /cast /genjutsu:cast /genjutsu:paint Philosophy "Make this thing beautiful/wow" "Build a visual universe from scratch" Entry point Adapts to existing code Mandatory brainstorm, wipes design if existing Discovery Lightweight, only when vague Full brainstorm, never skipped Design system Optional, implicit Required, generates MASTER.md Audit Quick check before delivery Full design audit at the end Scope One component/page/effect Entire project visual identity /genjutsu:paint calls the same sub skills as /genjutsu:cast for implementation. Iron Rules 1. Never skip the brainstorm. Not even if the user says "just make it look good." Especially then. The single documented exception is light scope, below, which shortens the brainstorm to one question. It never removes it. 2. One question at a time during brainstorm. Never bundle. The second question depends on the first answer. 3. Never proceed without the theses validated. Visual + interaction, both explicitly approved. The one exception is light scope, below: no visual identity is at stake there, so the interaction thesis alone is required and it is still validated explicitly, never assumed. 4. Every design token comes from MASTER.md. No magic numbers, no rogue hex values. On light scope, where no MASTER.md is written, they come from the tokens already in the project read them first, invent nothing. 5. Every animation respects the interaction thesis. Timing, easing, forbidden patterns — no exceptions. 6. Never install a dependency without asking. 7. Work page by page, validate page by page. Never try to do everything at once. 8. The audit is not optional. Phase 5 always runs, even if the user seems happy. On light scope it shortens to the quick check reduced motion, exit animation, 60fps but it never disappears. 9. Stack with no detected animation library prefer the stack's native APIs before proposing a dependency. 10. Animation library detected (GSAP, Motion / Framer Motion, Lottie, Rive, etc.) respect the dev's choice. Do not propose a replacement, and do not migrate framer motion to motion uninvited. 11. Show, don't just describe. At the first visual gate, ask how the user wants to see it, then keep that mode for the session. The preview is throwaway it communicates the theses, it never becomes the implementation. Light scope the one shortened path paint is a five phase pipeline, and it is the wrong tool for "animate this word" or "polish this hover". Those belong to /genjutsu:cast , which is the default entry point. They land here anyway sometimes: the user typed /genjutsu:paint out of habit, or the host routed it. Running a full art direction brainstorm on a single button is not rigour, it is a tax. Recognise the case and shorten, out loud. It is light scope when all three hold: the target is one component, one effect, or one isolated element no visual identity is being established: the project already has colors and type, or there is no project yet, only a sketch nothing downstream depends on the result being systematised If two or more fail, it is not light scope. Run the full pipeline and say in one line why. What changes: Phase Full Light 1 BRAINSTORM five domains, one question at a time one question , the least obvious one, then stop 2 THESIS visual + interaction, both validated interaction thesis only, still validated 3 DESIGN SYSTEM generate MASTER.md and the stack token files skipped. Read the tokens already in the project and use them. Write no MASTER.md. 4 IMPLEMENT page by page, validate page by page the one component 5 AUDIT full design audit sub skill the quick check: reduced motion, exit animation, 60fps Announce it once , so the user knows which pipeline they got and can overrule it: "This is a single component, so I am running paint light: one question, no design system file. Say so if you want the full pipeline." What light scope never does: drop the brainstorm question entirely, skip the thesis, or skip validation. Every gate stays. Only their number goes down. <! genjutsu:shared:preview:start Showing Your Work The Preview Gate Some gates in this pipeline exist so the user can look at something before approving it: an interaction thesis, a set of variants, a visual identity, a design system. Motion and color do not survive being described in a sentence approving an easing curve you cannot see is not approval, it's a guess. So before the first gate of that kind, ask how they want to see it. Then never ask again. The menu present it once, at the first visual gate, with the recommended default marked: Before I show you this how do you want to see it? A. Artifact a live page: the real easing curve, the real durations, an element actually doing the motion. B. Live preview a throwaway route in your project, real stack, real tokens. Native: a @Preview / Preview scratch file. C. Inline written out here in the conversation. Recommended default state it in the menu, never apply it silently: Situation Default Scope is light (a hover, one transition) C inline Scope is medium or full, web stack A artifact Scope is medium or full, Compose / SwiftUI B live preview, A as second choice A full visual identity or design system is on the table A artifact No dev server, or the repo must not be written to A artifact Host is Cowork and there is no project checkout to write into A artifact, B is unavailable The choice sticks for the whole session. At every later gate, announce the mode in one line ("Variants in artifact.") and go. Do not reopen the menu. The user switches by saying so "show me that as text", "put it in an artifact", "just tell me" respect it immediately, and the new mode becomes the session default from then on. Which host is this? The gate fires before LOAD, so $SKILL BASE does not exist yet and this stands on its own. Detect once, cheaply, then map: Cowork is tested before Claude Code on purpose: both can have a ~/.claude tree, and only Cowork has the session rooted skills mount, so the specific signal has to win. Producing the preview resolve the host, degrade, never fail: Host A artifact C inline claude.ai Rendered natively. Just produce one. Written out in the conversation. Cowork The host's persistent artifact. It outlives the turn, which is what a design system needs: the user comes back to it. The host's inline widget, rendered in place. Right default for a short task. Claude Code The Artifact tool, when it is available. Written out in the conversation. unknown A self contained HTML file written to a temp path, hand back the path. Written out in the conversation. Call whatever the host actually exposes, under the name it exposes it as check the tools available in the session rather than assuming one. If nothing renders, fall back down the table rather than failing the gate: an inline preview always beats an aborted one. B live preview needs a project to write into. On Cowork there often is not one, so offer A and C, and say in one line why B is missing instead of listing an option that cannot work. What goes in it. A preview that restates the sentence in a nicer font is worthless. Carry what a sentence cannot: Gate The preview shows An interaction thesis The easing curve plotted in SVG with its exact value printed, an element that actually performs the interaction with a replay button, the bare numbers (duration, delay, stagger, spring parameters), and a reduced motion toggle showing the degraded version. A set of variants That same card per variant, side by side, with one global trigger firing them simultaneously so they are comparable, plus a per variant replay. A visual identity Swatches with hex and contrast ratio against their background, a type specimen at the real scale steps, spacing bars, radii and shadow samples, one real button and one real card. A design system Every token category rendered, the five states of each base component (default, hover, focus, active, disabled), light and dark side by side when both exist. Rules the preview obeys: It is throwaway. It never becomes the implementation. Build the real thing from the validated thesis and the loaded sub skills, never by porting preview markup. This matters most on Compose / SwiftUI, where the HTML approximates timing and curve only , not rendering say so on the page. Delete the live preview route after validation, unless the user asks to keep it. Never install a dependency to build a preview. Never start a dev server without asking. Only show values that are in the thesis. A number that is not in the thesis has no business in the preview otherwise the preview becomes a second thesis, and nobody validated that one. <! genjutsu:shared:preview:end Sub skills Path Detection <! genjutsu:shared:skill base:start This block defines shell state, and shell state does not survive between Bash calls. $SKILL BASE and load skill exist only inside the single Bash invocation that ran this block. Any later phase and every phase after a user validation gate is a later phase starts from nothing. So: re emit this whole block in the same Bash call as the load skill lines you are about to run. Never cat "$SKILL BASE/..." in a call that did not define it; the path resolves to /<name /SKILL.md , the cat fails, and the pipeline carries on without the sub skill. Re emitting costs a handful of depth capped find calls, which is cheaper than being wrong about which version you loaded. <! genjutsu:shared:skill base:end All sub skills are loaded via load skill <name (defined above), which cats the sub skill's entry file and warns instead of failing if it was not uploaded. Every phase below that loads something must re emit the resolution block in the same Bash call: the phases are separated by user gates, and nothing carries across them. Pipeline Phase 1 — BRAINSTORM (mandatory, never skip) This is the foundation. Rush it and everything downstream is wrong. The goal: understand the user's vision well enough to write two theses they'd agree with without hesitation. Stack scan (run before brainstorm) Before asking the user about tech stack, scan the project to detect what's already there: <! genjutsu:shared:scan:start Map the results: Animation lib : gsap, motion , framer motion , three/@react three, anime.js, or none. motion and framer motion are the same library at two names. Framer Motion was renamed to Motion; motion is the current package and framer motion is the legacy one, still widely installed and still published. Note which of the two is in package.json the import path differs and the sub skill needs to know. If both are present, the project is mid migration: say so and follo