Paint

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: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:

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:

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:

if [ -d /mnt/skills/user ]; then
  GENJUTSU_HOST=claude-ai
elif [ -d /mnt/.claude/skills ] \
  || [ -n "$(find /sessions -maxdepth 6 -type d -path '*/.claude/skills' 2>/dev/null | head -1)" ]; then
  GENJUTSU_HOST=cowork
elif [ -n "${CLAUDE_PLUGIN_ROOT:-}" ] || [ -d "$HOME/.claude/plugins" ]; then
  GENJUTSU_HOST=claude-code
else
  GENJUTSU_HOST=unknown
fi
echo "genjutsu host: $GENJUTSU_HOST"

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: