К основному содержанию
скилл CX Codex

paint — скилл для Claude Code: что делает и как установить

Запускает пайплайн дизайн-системы для веба, Compose и SwiftUI: от брейншторма арт-дирекшна до кода и аудита доступности.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add AThevon/genjutsu --skill paint -a claude-code
Открыть на GitHub

Что делает paint

Скилл выстраивает визуальный стиль проекта с нуля через строгий регламент из пяти этапов. Сначала агент задаёт вопросы по арт-дирекшну строго по одному за раз. Затем формулирует визуальный и интерактивный тезисы, которые разработчик должен одобрить явно. Без этого переход к коду заблокирован.

После утверждения концепции скилл создаёт дизайн-систему в файле MASTER.md и генерирует токены под стек проекта. Никаких случайных шестнадцатеричных цветов или магических чисел в кодовой базе не остаётся: все значения берутся только из единого источника. Реализация идёт строго по одной странице с промежуточной проверкой каждого шага. В конце всегда запускается аудит, где проверяются соответствие кода утверждённому тезису, поддержка reduced-motion и плавная анимация в 60fps.

Если в проекте уже есть библиотека анимации вроде GSAP, Motion, Lottie или Rive, скилл сохраняет её и не предлагает замену. Для правок единичного элемента автоматически включается укороченный режим light scope: он пропускает генерацию MASTER.md и считывает текущие токены из репозитория.

Какие задачи решает

  • собрать визуальную дизайн-систему и токены в MASTER.md
  • согласовать интерактивный и визуальный тезисы перед вёрсткой
  • адаптировать единый визуальный стиль под Web, Compose или SwiftUI
  • проверить вёрстку на соответствие reduced-motion и 60fps

Примеры запросов агенту

  • /genjutsu:paint создай дизайн-систему и главную страницу для веб-приложения
  • /genjutsu:paint настрой визуальный стиль и анимации для экрана на SwiftUI

Как установить paint

1Через Skills CLI (Vercel)

npx skills add AThevon/genjutsu --skill paint -a claude-code

2Вручную: положить файлы

~/.claude/skills/paint/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/paint/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Вопросы о paint

Как установить paint в Claude Code?

Выполните в терминале команду npx skills add AThevon/genjutsu --skill paint -a claude-code.

Что делает скилл paint?

Он проводит проект через полный цикл арт-дирекшна: опрашивает разработчика, фиксирует тезисы интерфейса, генерирует файл MASTER.md с токенами, пишет код страниц и проводит финальный аудит анимаций.

Чем paint отличается от команды cast?

Команда /genjutsu:cast предназначена для точечной полировки одного эффекта или готового компонента. Команда /genjutsu:paint создаёт целостную визуальную идентичность проекта с обязательным брейнштормом, генерацией файла MASTER.md и глубоким дизайн-аудитом.

Исходный текст

SKILL.md · MIT
---
name: paint
description: "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)."
allowed-tools: Bash, Read, Edit, Write, Grep, Glob, WebSearch, Artifact
---

# 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; on an existing design, asks preserve, partial or redesign |
| **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.

A whole site or web app built from real material is the job of the third pipeline,
`/genjutsu:bunshin`: a team of subagents under one art director, with independent reviews
until only minor issues remain or the tier's round cap is reached. paint proposes it right after
the stack scan when the brief is that size, the stack is web or there is no project yet, and the
host can spawn subagents, and switches only on a yes.

---

## 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. With nobody answering, see "When nobody is answering": the questions are answered from the brief, as assumptions.
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. With nobody answering, see "When nobody is answering".
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.** With nobody answering, never install one (see "When nobody is answering").
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 - thesis against code, 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: thesis against code, 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. Rendered page** - a live HTML 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 - rendered page |
| 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 - rendered page |
| No dev server, or the repo must not be written to | A - rendered page |
| Host is Cowork and there is no project checkout to write into | A - rendered page, B is unavailable |

**The choice sticks for the whole session.** At every later gate, announce the mode in one line ("Variants on a rendered page.") and go. Do not reopen the menu. The user switches by saying so - "show me that as text", "put it on a page", "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:

```bash
if [ -d /mnt/skills/plugins ] || [ -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:

| Host | A - rendered page | C - inline |
|---|---|---|
| claude.ai | Rendered natively as an artifact. 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 the session has it, else the capability rule below. | Written out in the conversation. |
| unknown (any other host) | The capability rule below. | Written out in the conversation. |

**A, by capability.** Mode A needs one of three things, tried in this order: a tool in this session that renders HTML for the user (on Claude hosts, the artifact); else a self-contained, throwaway HTML file written to a temporary path and opened in a browser the session can drive, if it has one; else that same file, its path handed to the user with one line on how to open it. Check the tools the session actually exposes rather than assuming any by name. If nothing works, fall back to C 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:**

- **The message that carries it names the thesis in plain text.** Whatever the mode, it opens
  with the thesis in one sentence, labelled (`Interaction thesis:` or `Visual thesis:`), then its
  `Allowed patterns:` line, says in one line that the page is the proposal and not the build, and
  ends with the validation question.
  It holds no implementation: code starts in a later turn, after a yes. Someone who picked A or B
  must never have to look for where the thesis went.
- **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.
- A web face the preview cannot load in this session is still shown under its own name, set in its fallback stack and labelled `not rendered in this session`. Never swap it for a face the session can render: what the sandbox can fetch is not what the site will ship.
<!-- genjutsu:shared:preview:end -->

<!-- genjutsu:shared:headless:start -->
## When nobody is answering

Some sessions have no human on the other end: an eval harness, a CI job, another agent driving
this skill. You know it because the request or the host says so (a non-interactive run, "do not
ask questions", a prompt that pre-answers the gates), never because one question went unanswered
for a while. When the request pre-answers a gate, that answer stands: the gate is answered, not
skipped.

In such a session every gate still produces its output. What changes is that nobody validates it:

- **Discovery and brainstorm questions:** do not ask them. Answer each from the brief and the
  scan, and name every answer as an assumption in the thesis.
- **Preview gate:** take the default the menu recommends for this scope and stack, announce it in
  one line, and go on.
- **Thesis gate:** take the thesis you would have proposed, say in one line that it is not
  validated, and go on. The final report prints it, marked **UNVALIDATED**.
- **Dependencies:** never install one. Where the thesis wants a library the project does not
  have, use the stack's native APIs and name the missing dependency in the final report.

Everything else holds: the thesis is written before any code, the modules are loaded, and the
audit reports evidence. A headless run skips the waiting, never the work.
<!-- genjutsu:shared:headless:end -->

---

## Sub-skills Path Detection

**Tell the block where this skill lives.** The block's first line reads `GENJUTSU_SKILL_DIR`.
Claude Code fills it in by itself. On any other host, put one line in front of the block, in the
same shell call, naming the directory you read this file from:
`GENJUTSU_SKILL_DIR='/absolute/path/to/paint'`. When the genjutsu router printed a
`GENJUTSU_SKILL_DIR=` line, use that value as it is.

<!-- genjutsu:shared:skill-base:start -->
**This block defines shell state, and shell state does not survive between shell calls.**
`$SKILL_BASE`, `load_skill` and `load_ref` exist only inside the single shell call 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 shell 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>/...`, the `cat` fails, and the module is lost.

**If the block prints `could not find the genjutsu modules`, stop the pipeline.** Show the
user the message, install command included, and do nothing else: every later step depends
on the modules, and running without them produces exactly the generic output this skill
exists to prevent.

```bash
GENJUTSU_SKILL_DIR="${GENJUTSU_SKILL_DIR:-${CLAUDE_SKILL_DIR}}"
# Resolution order, first hit wins:
#   0. claude.ai, /mnt/skills/plugins (or the older /mnt/skills/user): the
#      genjutsu bundle.
#   1. This skill's own directory: its _jutsu, or the _jutsu next to it.
#   2. ${CLAUDE_PLUGIN_ROOT}/skills/_jutsu, when Claude Code substituted it.
#   3. Bounded probes: .claude/skills and .agents/skills from $PWD upward, then
#      the skills directories installers write to, then /sessions (Cowork).
#   4. The Claude Code plugin cache, newest version. Last on purpose: an old
#      plugin install must never win over a newer bundle.
# Resolved from scratch every time. A cache was tried here and removed: after a
# plugin update the old version directory is still on disk, so a cached path
# passes an "is it a directory" check and serves the previous release.

# No function below names a positional parameter (a dollar sign followed by a
# digit, or the whole argument list). Claude Code replaces those tokens in a
# skill's text with the words typed after the slash command, before the model
# reads this block: after "/genjutsu:cast make the cards feel physical", a path
# built from a function's first parameter would read "the/motion-principles/...",
# the second word typed. Each function reads its arguments with a bare
# `for name; do`, which walks the positional parameters without writing any out.

# A _jutsu directory counts only if it holds motion-principles. The shared
# skills directory of npx serves about 80 agents, so a directory name proves
# nothing. The entry file is named SKILL or GUIDE depending on the artifact
# (the bundle renames it at packaging time), so the name is assembled from
# parts: spelled out in full, the packaging step would rewrite it too.
genjutsu_is_jutsu() { # <candidate _jutsu directory>
  for jutsu_dir; do
    for d in SKILL GUIDE; do
      [ -f "$jutsu_dir/motion-principles/$d.md" ] && return 0
    done
  done
  return 1
}

# Print the first genjutsu _jutsu among the candidate paths read on stdin.
genjutsu_first_jutsu() {
  while read -r jutsu_c; do
    genjutsu_is_jutsu "$jutsu_c" && { printf '%s\n' "$jutsu_c"; return 0; }
  done
  return 1
}

SKILL_BASE=""
# 0. claude.ai mounts uploaded skills under /mnt/skills/plugins/<name>/ (seen on
# 2026-09-28), next to the user's other skills; /mnt/skills/user before that.
# GENJUTSU_CLAUDE_AI_ROOT stands in for /mnt/skills in the test suite only.
# Only a _jutsu holding motion-principles counts: a mount without genjutsu in it
# must never pass for a resolved base.
genjutsu_claude_ai="${GENJUTSU_CLAUDE_AI_ROOT:-/mnt/skills}"
for claude_root in "$genjutsu_claude_ai/plugins" "$genjutsu_claude_ai/user"; do
  [ -z "$SKILL_BASE" ] && [ -d "$claude_root" ] || continue
  SKILL_BASE="$(find -L "$claude_root" -maxdepth 2 -type d -name _jutsu 2>/dev/null | genjutsu_first_jutsu)"
done
# 1. This skill's own directory. Empty means unknown: never probe "/_jutsu".
if [ -z "$SKILL_BASE" ] && [ -n "$GENJUTSU_SKILL_DIR" ]; then
  SKILL_BASE="$(printf '%s\n' "$GENJUTSU_SKILL_DIR/_jutsu" "$GENJUTSU_SKILL_DIR/../_jutsu" | genjutsu_first_jutsu)"
fi
# 2. Claude Code plugin root.
if [ -z "$SKILL_BASE" ] && [ -n "${CLAUDE_PLUGIN_ROOT}" ]; then
  SKILL_BASE="$(printf '%s\n' "${CLAUDE_PLUGIN_ROOT}/skills/_jutsu" | genjutsu_first_jutsu)"
fi
# 3. Bounded probes, following symlinks (npx links .claude/skills/<name> to
# .agents/skills/<name>). The case guard stops the walk at "/", "." or "".
probe_dir="${PWD:-$(pwd)}"
probe_n=0
while [ -z "$SKILL_BASE" ] && [ "$probe_n" -lt 24 ]; do
  probe_n=$((probe_n + 1))
  SKILL_BASE="$(find -L "$probe_dir/.claude/skills" "$probe_dir/.agents/skills" -maxdepth 2 -type d -name _jutsu 2>/dev/null | genjutsu_first_jutsu)"
  case "$probe_dir" in /|.|"") break ;; esac
  probe_dir="$(dirname "$probe_dir")"
done
for probe_root in "$HOME/.agents/skills" "$HOME/.claude/skills" "$HOME/.codex/skills" \
    "$HOME/.cursor/skills" /mnt/.claude/skills; do
  [ -z "$SKILL_BASE" ] && [ -d "$probe_root" ] || continue
  SKILL_BASE="$(find -L "$probe_root" -maxdepth 2 -type d -name _jutsu 2>/dev/null | genjutsu_first_jutsu)"
done
if [ -z "$SKILL_BASE" ] && [ -d /sessions ]; then
  SKILL_BASE="$(find -L /sessions -maxdepth 8 -type d -path '*/.claude/skills/*/_jutsu' 2>/dev/null | genjutsu_first_jutsu)"
fi
# 4. Claude Code plugin cache, newest version first. Numeric version
# directories only, so a bare marketplace clone never wins.
if [ -z "$SKILL_BASE" ] && [ -d "$HOME/.claude/plugins/cache" ]; then
  SKILL_BASE="$(find "$HOME/.claude/plugins/cache" -maxdepth 6 -type d -path '*/genjutsu/[0-9]*/skills/_jutsu' 2>/dev/null | sort -V -r | genjutsu_first_jutsu)"
fi
[ -n "$SKILL_BASE" ] && SKILL_BASE="$(cd "$SKILL_BASE" 2>/dev/null && pwd -P)"

# Stop instead of running the pipeline without its modules. Name every root that
# was tried, so a new layout can be reported instead of guessed.
if [ -z "$SKILL_BASE" ]; then
  echo "genjutsu: could not find the genjutsu modules (a _jutsu directory holding motion-principles)." >&2
  echo "  genjutsu's pipelines do not work without them. Install the full bundle:" >&2
  echo "    any agent    npx skills add https://genjutsu.athevon.dev -g" >&2
  echo "    Claude Code  /plugin marketplace add AThevon/genjutsu, then /plugin install genjutsu" >&2
  echo "    claude.ai    upload genjutsu.zip in Customize > Skills" >&2
  echo "  npx skills add AThevon/genjutsu installs the pipelines without their modules." >&2
  echo "  Tried: /mnt/skills/plugins, /mnt/skills/user, GENJUTSU_SKILL_DIR (${GENJUTSU_SKILL_DIR:-empty}) and its parent," >&2
  echo "         \$CLAUDE_PLUGIN_ROOT, .claude/skills and .agents/skills from \$PWD upward," >&2
  echo "         ~/.agents/skills, ~/.claude/skills, ~/.codex/skills, ~/.cursor/skills," >&2
  echo "         /mnt/.claude/skills, /sessions, ~/.claude/plugins/cache." >&2
  echo "genjutsu: stop the pipeline here and show this message to the user." >&2
  return 1 2>/dev/null || exit 1
fi
echo "genjutsu: modules from $SKILL_BASE" >&2

# Print a module's entry file. A missing module does not stop the pipeline (a
# partial claude.ai upload is legitimate), but it is announced, and the final
# report lists it: shell state does not survive, so the model keeps the list.
load_skill() { # <module>
  skill_name=""
  for skill_arg; do skill_name="$skill_arg"; break; done
  for d in SKILL GUIDE; do
    if [ -n "$skill_name" ] && [ -f "$SKILL_BASE/$skill_name/$d.md" ]; then
      cat "$SKILL_BASE/$skill_name/$d.md"
      return 0
    fi
  done
  echo "genjutsu: sub-skill '$skill_name' NOT LOADED - not found under $SKILL_BASE. Carry on, and list it under 'Modules not loaded' in the final report." >&2
  return 1
}

# Print one reference file of a module: load_ref <module> <path inside it>.
load_ref() { # <module> <path inside it>
  ref_module=""; ref_path=""; ref_n=0
  for ref_arg; do
    ref_n=$((ref_n + 1))
    case "$ref_n" in
      1) ref_module="$ref_arg" ;;
      2) ref_path="$ref_arg"; break ;;
    esac
  done
  if [ -n "$ref_module" ] && [ -n "$ref_path" ] && [ -f "$SKILL_BASE/$ref_module/$ref_path" ]; then
    cat "$SKILL_BASE/$ref_module/$ref_path"
    return 0
  fi
  echo "genjutsu: reference '$ref_module/$ref_path' NOT LOADED - not found under $SKILL_BASE. Carry on, and say so in the final report." >&2
  return 1
}
```
<!-- genjutsu:shared:skill-base:end -->

All sub-skills are loaded via `load_skill <name>` (defined above), which prints the module's
entry file, or a `NOT LOADED` line when the module is missing, and carries on: keep the list, the
final report needs it. When the block cannot find the modules at all, it stops, and so does the
pipeline. Every phase below that loads something must re-emit the resolution block in the same
shell 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 -->
```bash
# 1. Web (existing)
cat package.json 2>/dev/null | grep -E '"(gsap|motion|framer-motion|three|@react-three/fiber|@react-three/drei|animejs|popmotion|lenis|locomotive-scroll)"'
cat package.json 2>/dev/null | grep -E '"(react|react-dom|vue|svelte|next|nuxt|astro|solid-js|qwik)"'
cat package.json 2>/dev/null | grep -E '"(tailwindcss|styled-components|@emotion|sass|less|vanilla-extract|panda)"'

# 2. Android / Compose
ls build.gradle.kts build.gradle settings.gradle.kts settings.gradle 2>/dev/null
grep -rE 'androidx\.compose|implementation\("androidx\.compose' build.gradle* settings.gradle* 2>/dev/null

# 3. Compose Multiplatform / KMP
grep -rE 'org\.jetbrains\.compose|kotlin\("multiplatform"\)|id\("org\.jetbrains\.kotlin\.multiplatform"\)' build.gradle* settings.gradle* 2>/dev/null

# 4. Apple / SwiftUI
ls *.xcodeproj *.xcworkspace Package.swift 2>/dev/null
grep -lE 'import SwiftUI|@main.*App' --include="*.swift" -r . 2>/dev/null | head -1

# 5. Apple platform sub-detection (iOS vs macOS)
grep -E '\.iOS\(|\.macOS\(' Package.swift 2>/dev/null
grep -E 'SDKROOT = (iphoneos|macosx)' *.xcodeproj/project.pbxproj 2>/dev/null

# 6. Mobile web indicators
grep -rE 'viewport.*width=device-width|@media.*pointer:\s*coarse|@media.*max-width' --include='*.html' --include='*.css' --include='*.scss' . 2>/dev/null | head -3
ls public/manifest.json public/sw.js 2>/dev/null

# 7. Legacy bridge indicators (mention in DISCOVER, do not auto-load)
ls -- *.xib *.storyboard 2>/dev/null
find . -path '*/res/layout/*.xml' 2>/dev/null | head -1
grep -rE 'setContentView\(R\.layout' --include='*.kt' --include='*.java' . 2>/dev/null | head -1
```

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 follow whichever one the file you are editing already imports.
- **Framework**: React, Vue, Svelte, Next.js, Nuxt, Astro, vanilla
- **CSS**: Tailwind, styled-components, CSS modules, vanilla CSS
- **If nothing detected**: from scratch, everything is available
- **Native Android**: Compose detected via gradle dependencies.
- **Native Apple**: SwiftUI detected via Package.swift / xcodeproj + swift files. Distinguish iOS vs macOS via Package.swift platforms or pbxproj SDKROOT.
- **Compose Multiplatform**: kotlin-multiplatform plugin + jetbrains.compose plugin.
- **Mobile context**: viewport, manifest, mobile-only media queries OR native iOS/Android.
- **Desktop context**: macOS target OR no mobile indicators on web.
- **Legacy mixed**: presence of `.xib`, `.storyboard`, layout XML, `setContentView(R.layout.*)`. Mention only, no auto-load.
<!-- genjutsu:shared:scan:end -->

<!-- genjutsu:shared:escalate:start -->
**When the job is a whole site: propose bunshin.** genjutsu has a third pipeline for the one job
this one is too small for. `bunshin` builds a whole website or web app with a team of subagents
under one art director, with Impeccable drawing the direction when it is installed, and it loops
independent reviews and fixes until only minor issues remain, the tier's round cap is reached, or
a round fixes nothing. It is heavy, so it is proposed, never started on its own.

Propose it once, right after the scan and before anything else you would ask, when **all three**
of these hold:

- the target is a whole site or web app: several pages or screens, from scratch or as a full
  redesign;
- the stack is web, or there is no project yet;
- this session can spawn subagents: a subagent tool or a multi-agent workflow tool is among the
  tools it exposes (in Claude Code, `Agent` or `Workflow`);

and **at least one** of these:

- there is real material to harvest: a social profile, a current site, brand assets, documents;
- the site serves two audiences, or two languages;
- it is a first version meant for a client or a stakeholder;
- the request asks for the best possible, the full treatment, all out.

Before writing the proposal, check whether Impeccable is installed:

```bash
for d in .claude/skills/impeccable .agents/skills/impeccable "$HOME/.claude/skills/impeccable" "$HOME/.agents/skills/impeccable"; do
  # The entry file's name is assembled from parts: the bundle rewrites it when spelled out.
  e="$d/SKILL"
  if [ -f "$e.md" ]; then echo "impeccable: $d"; break; fi
done
```

The proposal is one message, then wait:

> "This is a whole site<, from scratch | , a full redesign>. genjutsu has a pipeline for exactly
> that: `bunshin`. It
> harvests your real material, researches with parallel agents, lets Impeccable draw the
> direction (<installed here | not installed: bunshin runs without it, better with it>), builds
> the pages with parallel agents, and reviews and refines them until only minor issues remain,
> the round cap of the tier you pick is reached, or a round fixes nothing.
> It asks you twice: once to start, with a budget, and once to choose the direction. One run has
> been measured, a seven-page site: about 10.5 million subagent tokens over six to eight hours.
> The tiers are estimated from it, from about 6 to about 13 million, and scale with the pages.
> Say `bunshin` to switch, or I carry on with this pipeline."

- **A yes**: stop this pipeline and load bunshin. Invoke it as a skill when the host lists
  `genjutsu:bunshin`; otherwise read its entry file next to this one, in
  `$GENJUTSU_SKILL_DIR/../bunshin/` (the one Markdown file at the top of that folder), and follow
  it from its first step.
- **Anything else**: carry on here, and do not propose it again in this session.
- **Never** when one of the first three conditions fails: a host that cannot spawn subagents
  cannot run bunshin, and a native stack is not covered by it yet.
- **With nobody answering**: do not propose and wait. Say in one line that bunshin would fit this
  brief, carry on with this pipeline, and name bunshin in the final report.
<!-- genjutsu:shared:escalate:end -->

**Declare your read before the f...

© AThevon · MIT · AThevon/genjutsu

Похожие скиллы

Всё по теме «Дизайн» →
motion-system Owl-Listener Задаёт единый набор длительностей, кривых и правил для анимаций в продукте. Пригодится, когда у каждого компонента свои тайминги. CX Codex +1 1 800установок swiftui-design nexu-io Скилл помогает проектировать интерфейсы SwiftUI по чётким правилам, избегая типичных ошибок AI-кода. Направляет дизайн-решения, проверяет бренд-активы и оценивает макеты по пяти критериям. CX Codex +1 2 900установок swiftui-design-principles arjitj2 Скилл задаёт ИИ-агенту правила сетки, типографики и цветов для SwiftUI и WidgetKit, чтобы интерфейс выглядел как нативное приложение, а не как сгенерированная разметка. CX Codex +1 1 300установок design rshankras Набор дизайн-скиллов для интерфейсов Apple: Liquid Glass, анимации, игровой отклик, UX-тексты, SF Symbols и типографика. Пригодится, когда экран выглядит плоско и нужен план правок. CX Codex +1 677установок swiftui-animation jamesrochabrun Скилл помогает настраивать пружинные анимации SwiftUI и эффекты Metal-шейдеров в приложениях для iOS и macOS. CX Codex +1 567установок design-code plugin87 Скилл помогает агенту собирать код компонентов и экранов под выбранный фреймворк. Он пригодится, когда нужен готовый UI с токенами и проверками доступности. CX Codex +1 525установок

Из того же набора17

ui-ux-pro-max Подбирает дизайн-системы, палитры и шрифтовые пары под стек и тип продукта через локальную базу правил. Пригодится при вёрстке интерфейсов и проверке доступности. CX Codex +1 948установок cast Скилл для творческого кодинга: превращает статичный интерфейс в живой — движение, микроинтеракции, отклик на действия. Работает с Web, Android (Compose) и Apple (SwiftUI). CX Codex +1 1 300установок motion-principles Скилл задаёт правила интерфейсной анимации: безопасные свойства, тайминги, кривые разгона и режим reduced-motion для веба, SwiftUI и Jetpack Compose. CX Codex +1 1 100установок design-audit Проверяет код фронтенда на проблемы с анимацией, доступностью и дизайн-токенами. Находит визуальные штампы ИИ и ошибки вёрстки перед сдачей проекта. CX Codex +1 1 000установок threejs-r3f Скилл по Three.js и React Three Fiber: правила сцен, хуков, постобработки и производительности. Пригодится, когда агент пишет 3D на React. CX Codex +1 1 000установок css-native Скилл для ИИ-агента, который подсказывает, как делать анимации и визуальные эффекты на нативном CSS без библиотек. CX Codex +1 1 100установок gsap Скилл помогает агенту писать анимации GSAP: таймлайны, каскадные эффекты и ScrollTrigger. Нужен для сложных движений и прокрутки. CX Codex +1 997установок canvas-generative Скилл для алгоритмической графики на Canvas 2D: частицы, flow fields, шум, фракталы и L-системы. Пригодится, когда нужна анимация или генеративная картинка в браузере. CX Codex +1 995установок

Спонсоры проекта

Компании, которые помогают держать аналитику открытой