genjutsu

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.

All documentation

/genjutsu: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.

paint against cast

cast paint
Premise Make this thing exceptional Build an identity from nothing
Entry Adapts to existing code Mandatory brainstorm, replaces the existing design
Discovery Light, and only when vague Full brainstorm, never skipped
Design system Optional, implicit Required, writes MASTER.md
Audit Quick check before delivery The full audit
Scope One component, page or effect The project’s visual identity

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

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.

Five domains get covered: product, audience, mood (three to five adjectives), references, and stack. The stack is usually answered by the scan rather than by you.

One question at a time. Vague answers get concretised rather than accepted: “clean” comes back as a choice between Stripe’s editorial whitespace, Linear’s dense-but-organised, and Apple’s dramatic minimalism. “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.

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. Both must be validated before phase 3.

Phase 3: Design system

This phase produces a file, not a vibe. 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:

Stack Generated
Web CSS custom properties, or a Tailwind config extension
Android Compose Theme.kt, Color.kt, Type.kt, Shapes.kt, Motion.kt
SwiftUI Color+App.swift, Font+App.swift, Animation+App.swift, Shape+App.swift
Compose Multiplatform Tokens in commonMain, with expect/actual for fonts and platform colours

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.

Phase 4: Implement

Page by page, validated page by page. Never the whole site in one pass, because a wrong turn found on page four is cheaper than a wrong turn found on page one after four pages were built on it.

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. See the audit checklist in cast; paint runs the same one, in full, plus a token-consistency sweep that fails on any value not traceable to the design system.

Findings come back grouped by severity: critical, important, nice-to-have.

Running it on a project that already has a design

It still runs the full brainstorm, and it still acknowledges what is there, but the new thesis overrides the old direction. Phase 4 replaces existing tokens and styles rather than layering over them. Functionality and layout structure are preserved; the visual layer is what changes.

That is deliberate. If you want to keep the current direction and improve it, that is cast.