paint

The Master Painter. A full design pipeline: mandatory brainstorm, a visual and an interaction thesis, a design system written into your repo, then implementation and a full audit against the thesis.

paint builds a complete visual universe. It is not a beautifier and it is not a faster cast. It is a design pipeline with five phases, two validation gates, and a written artefact that outlives the session.

With the Claude Code plugin it is /genjutsu:paint. After an npx install or on claude.ai, type /genjutsu and ask for a design; the router sends it here.

paint against cast

Both call the same modules to implement. The difference is everything that happens before the first line.

One exception, and it announces itself. When the target is a single component, the project already has colours and type, and nothing downstream needs systematising, paint runs light: one question instead of five, an interaction thesis only, no MASTER.md, and the quick audit instead of the full one. It says which pipeline you got in one line before it starts, and you can overrule it.

Phase 1: Brainstorm

Never skipped. Least of all when the brief is “just make it look good”, because that sentence contains no decisions and the decisions still have to be made by somebody.

Right after the stack scan, before its read of the project and the first question, comes one check. When the brief is a whole site or web app on a web stack (or no project yet), the session can spawn subagents, and there is real material to harvest, two audiences or languages, a first version meant for a client, or a request for the full treatment, paint proposes bunshin once: what it would do, whether Impeccable is installed, the two times it would ask you, and its cost range, measured on one seven-page site. It switches only on a yes and does not ask again in that session. With nobody there to answer, it names bunshin in one line and in the final report, and carries on.

It opens with its read of the project in one line (what it is, for whom, where it seems to be heading, on which stack) and asks you to correct it before the first question. Then five domains get covered: product (what it is, and what is true of it that its closest neighbour, or a template, could not claim), audience, mood (three to five adjectives), references, and stack. The stack is usually answered by the scan rather than by you. References only ever come from you: paint never suggests famous sites of its own, because a name it offers anchors the thesis on someone else’s look.

One question at a time. Vague answers get concretised rather than accepted, and a mood word is answered with a fact about the product rather than with another brand: “clean” comes back as “clean compared to what? Tell me one thing that is true of this product and that its closest competitor could not say about itself.” “What would feel wrong” is asked when “what do you want” stalls, because negative examples are often sharper.

If you push to skip ahead, it will not simply comply. It tells you what has been covered, what is missing, what that gap will affect, and offers you the choice: one more question, or it proceeds on stated assumptions that you can correct. Either way the assumptions are named out loud rather than buried.

Phase 2: Two theses, and this is a gate

The visual thesis is one sentence that must address four things explicitly: colour direction, typographic spirit, spacing philosophy, and component style. The typographic spirit names the display face and why this one, or says so plainly when it is still open: display face: undecided, chosen at the design-system gate.

Dark neo-brutalist interface with bold monospace type, fluorescent chartreuse accents, generous whitespace, and raw-edged components with offset shadows.

The interaction thesis is one sentence that must address four others: timing range, hover behaviour, scroll behaviour, and forbidden patterns.

Fast, dry transitions (100 to 200ms), hover with a subtle 1.02 scale, scroll-triggered reveals with stagger, no bounce and no elastic, all sharp ease-out.

The test each has to pass is that you can derive the actual CSS, Kotlin or Swift from reading it. “Nice typography” fails. The second is the guessability test: if someone could have written the thesis from the product category alone (a fintech gets navy and a clean sans, a design studio gets an editorial serif on paper), it is the category’s default rather than a decision, and it is rewritten from what is true of this product.

Under the two theses comes one more line, Allowed patterns:, naming every deliberate device the design relies on that a reader could take for decoration or habit: mono labels, hairline rules, a paper ground, grain, a glow, a looping animation. It reads Allowed patterns: none when there are none. You see it before you say yes, and the audit reads it: a tell counts as allowed only when this line lists it, so a mood word never lets one through.

Both theses must be validated before phase 3, and both are shown the way you chose at the first visual gate: a rendered page, a live preview in your project, or text. What each of those means on claude.ai, Cowork, Claude Code or another host is under cast.

From the validated theses it then reads three dials: how far the layout departs from convention (variance), how much moves (motion), and how tightly the page is packed (density). They come from what the theses say, never from the raw brief or a default, and a dial the theses do not settle is left unset. The values are shown with the design system.

Phase 3: Design system

This phase produces a file, not a vibe. On a web stack it first loads tells, the catalogue of defaults models reach for, so palette and type are chosen with it in view rather than audited afterwards.

The design-system dataset is then queried with the validated thesis and the dials, and what it returns is a proposal, not an answer. Every suggestion passes through the thesis and through tells before it is kept. The display face, serif or sans, gets in only with a reason for this product. The visual thesis gives it, or, when the thesis left the face undecided, this phase chooses it and says why in one line, shown with the design system: validating the design system amends the visual thesis with that line, and the build and the audit read the amended sentence. “Creative”, “premium” or “editorial” summon an editorial serif; “clean”, “modern” or “SaaS” summon a heavy grotesque; neither set of words is a reason, and trading one reflex for the other is not a decision. A warm paper ground stays only when the thesis says why this product belongs on paper. Glassmorphism because the product is a SaaS does not get in at all unless the thesis asked for it.

MASTER.md lands at your project root and becomes the single source of truth: colour palette (including semantic colours and both themes where relevant), a type scale with weight and line-height rules, a spacing scale with a stated base unit, radii, elevation levels, base component styling, and motion tokens for duration, easing and stagger.

Alongside it come the token files your stack actually reads:

Those files are children of MASTER.md and reference it. In a multi-stack repository, MASTER.md gets one delimited section per stack and each set of token files is generated.

Three MCP servers are used when the session has them connected, and only then: Stitch for mockups and wireframes, Nano Banana for visual assets such as illustrations, icons and backgrounds, and 21st.dev Magic for UI components from a description. They are optional. Without them paint skips that step; the design system and the code are the core path.

Phase 4: Implement

Page by page, validated page by page. Never the whole site in one pass: a wrong turn caught on page one costs one page. The same wrong turn caught on page four costs four.

Two rules hold throughout. Every colour, size, spacing, shadow and radius traces back to a MASTER.md token, with no magic numbers and no rogue hex values. And every interactive element gets all five states: default, hover, focus, active, disabled.

Phase 5: Audit

Always runs, in full. It opens with the thesis against the code: each promise of both theses matched to the file:line that keeps it, or reported missing. Then the checklist described under cast, a token-consistency sweep that flags any value not traceable to the design system, and the tells audit, where every finding gets one of three outcomes: allowed by an entry of the Allowed patterns: line, quoted next to it; not this tell, when the detection contradicts the entry’s own marker (a loop that reports a real loading state, a blur that is a modal backdrop), with the file:line that proves it, and never on a matter of taste; or a problem. A problem on a line the run wrote is fixed before the report, and the check runs again, two passes at most. What still fails after the second pass is reported with its file:line. A tell that was already in your project is listed for you and never changed by the audit.

What an agent cannot measure (frame timing, breakpoints, device settings) is handed over as a block marked unverified, with the exact thing to run. The report gives the counts, “N checked, M problems found, K handed over”, and ends with the modules that loaded and the ones that did not.

Running it on a project that already has a design

In phase 1, on a web project that already has a look, paint first takes an inventory of what is already there. The tells audit runs over the project, and the result comes back as one short block, What this project already does by reflex, counted by family with two or three file:line examples each. You see it before the preserve, partial or redesign question, and every finding in it is settled in the theses by the mode you pick: in preserve mode they stay by default, listed in the Allowed patterns: line as the brand’s own; in partial mode they go by default inside the areas you named; in redesign mode they go by default everywhere. You can keep or drop any one of them by name at the thesis gate.

Then, alongside the question about legacy code, paint asks which of three modes you want:

• Preserve the brand. The thesis works inside the existing identity; the tokens stay.
• Partial. The thesis replaces what you name and keeps the rest.
• Redesign. The thesis replaces the visual layer. Existing tokens are only ever replaced in this mode.

In every mode, some things never change without your explicit agreement: public token names, URLs, navigation labels, form field names, the logo, and legal notices.

Before any token file is written, you see the diff. Afterwards the project is built the way its stack builds (tsc or the npm build, Gradle, xcodebuild), or, when that cannot run in the session, the check comes back marked unverified with the exact command.

If what you want is motion on the design you already have, that is still cast. If it is a whole site, first version, built by a team of subagents under one art director, that is bunshin.