One art director, many clones. You keep the vision; the clones carry the width. This is genjutsu's heaviest pipeline. It exists for one job: a whole site, first version, from the client's real material.

• "Summoning four clones for the research."
• "The clones return: six pages, five builds green."
• "Sealing round two."

1. The summoning comes first. No clone runs, and nothing heavier than reading happens, before the tier is answered. With nobody answering, see "When nobody is answering".
2. Ask twice, then decide from evidence. The summoning and the direction are the user's. Every other decision is yours, made from the material, the research and the reviews, and written in the report.
3. One art director. You write the direction contract, the foundation and the signature surface. Clones build inside the contract and never redefine it.
4. Never code without a validated thesis. The direction gate validates the visual and the interaction thesis together, with the

   Allowed patterns:

   line.
5. Disjoint ownership. Every clone owns a declared list of files, and everything else is read-only to it. A shared need is a request, never an edit.
6. No dev server, no shared browser. Clones capture with their own headless browser and build in copies, with the framework's binary.
7. Evidence or it did not happen. Every finding cites a capture region or a

   file:line

   , every "done" has a build that printed exit code 0, every behaviour a measured value.
8. Nothing invented. Facts come from the material and the answers. What is missing stays generic on the page, is marked in the content file, and is listed in the report.
9. The loop ends on a rule. Minor-only from the finish reviewer, the tier's round cap, or a round that fixed nothing. Never open-ended, never past the cap without asking.
10. Never install a dependency without asking. Impeccable and browser tooling included. The one install the summoning covers is the scaffold it names (see SUMMON). With nobody answering, nothing beyond it.
11. Nothing leaves the machine unasked. No commit, no push, no deploy, no publish.
12. Web only, for now. On Compose or SwiftUI, say that bunshin does not cover native stacks yet and step down to

    paint

    .

cast

paint

paint

paint

"This is one landing page, so paint is the right pipeline, not bunshin. Running paint."

genjutsu:paint

genjutsu:cast

$GENJUTSU_SKILL_DIR/../paint/

../cast/

• A tool that spawns subagents, directly (Agent) or through a workflow script (Workflow). Without either there are no clones: step down. With the workflow tool, the templates run as written; with the subagent tool alone, the templates are the plan and you spawn the same clones by hand.
• A structured question tool (AskUserQuestion), for the two gates. Without one, one message per gate.
• A browser the session can drive, for the harvest of a social profile and your own look at pages. Clones never use it.
• Permissions. Clones run

  rsync

  ,

  ln

  ,

  find

  ,

  node

  , the framework's binary and a headless Chrome, in parallel, with new paths every time. When this session asks before each command, say so at the summoning and list the allow rules the run needs (for example

  Bash(rsync:*)

  ,

  Bash(find:*)

  ,

  Bash(node:*)

  ,

  Bash(./node_modules/.bin/astro:*)

  ); never write them into a settings file yourself.

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 ($(sed -n 's/^version: //p' "$e.md" | head -1))"; break; fi
done
node -e 'process.exit(typeof WebSocket === "function" ? 0 : 1)' 2>/dev/null && echo "node: 22+ (shoot.mjs runs)" || echo "node: missing or older than 22 (shoot.mjs cannot run)"
for c in "${CHROME_PATH:-}" "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" "/Applications/Chromium.app/Contents/MacOS/Chromium" \
    "$(command -v google-chrome google-chrome-stable chromium chromium-browser chrome 2>/dev/null | head -1)"; do
  [ -n "$c" ] && [ -x "$c" ] && { echo "chrome: $c"; break; }
done
command -v magick >/dev/null 2>&1 && echo "imagemagick: yes" || echo "imagemagick: no"
python3 -c 'import PIL, numpy' 2>/dev/null && echo "python PIL + numpy: yes" || echo "python PIL + numpy: no"

scripts/brief.mjs

references/impeccable.md

npx impeccable install --project -y

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.

$SKILL_BASE

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"

~/.claude

Artifact

• 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.

• 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.

bunshin for <what>: <N> pages in <languages>, from <sources>. The plan: harvest the material, research with four clones and a synthesis, you choose a direction, I build the foundation and the signature surface, <N> page clones build the rest, then refine rounds and verdicts until only minor issues remain or the tier's cap is reached. This host: <clones in parallel through workflows | clones one by one | cannot summon>. Impeccable: <version, it leads the direction | not installed: the direction round is weaker;

npx impeccable install --project -y

fixes that>. Captures: <yes | no, and what that costs>. Stack: <framework and adapter, already in place | no project yet: each option of the stack question below names its exact scaffold command and packages, the type-check ones included>. Your answers to the tier and the stack cover that one install and nothing else. Cost: one run has been measured, a seven-page bilingual site, about 10.5M subagent tokens over six to eight hours. Estimated from it: lean ~6M, standard ~8-9M, full ~12-13M, plus this session's own tokens; yours scales with the page count. <Permissions: the allow rules the run needs, when this session asks before each command.>

init

new-work

.bunshin/

.gitignore

.bunshin/run.json

<dir>/scripts/impeccable context

<dir>

PATH

load_skill <name>

NOT LOADED

• load_skill motion-principles

  - the foundation

validate-skills.py

load_skill

NOT LOADED

load_skill

load_ref

head

tail

sed

grep

load_skill tells

references/web.md

load_skill mobile-principles

load_skill desktop-principles

load_skill design-audit

load_skill ui-ux-pro-max

tells

undefined

load_ref orchestration references/evidence.md

• The build and the type check, each printing exit code 0;

  <dir>/scripts/impeccable detect --json <source folders>

  when Impeccable is installed; the tells audit (in one shell call, re-emit the skill-base block, then

  python3 "$SKILL_BASE/design-audit/scripts/audit.py" . --group tells

  ); and a grep for U+2014 unless the thesis allows it.
• Captures of every page and language with

  shoot.mjs

  : the standard shot list, one shots file and one call per page and language, into

  .bunshin/captures/round-1/

  . With Impeccable, add the two shots its finish reviewer requires, unsegmented, straight to their files:

  { "path": "/", "w": 1440, "h": 900, "full": true, "out": "<root>/.impeccable/review/desktop.png" }

  and the same at 390x664 to

  mobile.png

  , with the same

  reveal

  , at every PROVE: its verdict pass reads those exact paths again. Read the first screens yourself.
• The functional tests of the paths that sell (menu, sticky bar, selection into the form, form steps, endpoint failure and success), each reported with its measured value.

1. Run

   refine.js

   with

   root

   , the packet (PRODUCT.md, the contract, the quality floor, by absolute path),

   planPath

   (round 1: the review's plan file; later rounds: the plan the last verdict wrote),

   decisions

   (from round 2: the last decisions file), the owners that have fixes or decisions to apply,

   shared

   when it has some (it runs first and alone), and the same

   build

   as phase 7. Write its result to

   .bunshin/reviews/round-N-refine.json

   .
2. PROVE again: the checks, then new captures into

   .bunshin/captures/round-<N+1>/

   , and the two

   .impeccable/review/

   captures shot again over the same files.
3. Run

   verdict.js

   with the new packet,

   history

   (the round's plan file, its refine results, its decisions file),

   round

   , every owner,

   planOut

   set to

   <root>/.bunshin/reviews/round-<N+1>.json

   , the same

   finishAgent

   as the review, and

   freshEyes: true

   when the tier says so, with the one-sentence scenario of how the audience meets the site. It writes the next round's plan from the finish reviewer's remaining points, with an empty fixes list when nothing is left. Write its result to

   .bunshin/reviews/round-N-verdict.json

   .
4. When the verdict ran cold eyes and the loop goes on, turn their notes into decisions, yourself (when the stop rule ends the loop, the notes go into the report):

   .bunshin/decisions/round-N.md

   , rules the next round applies everywhere (the one role of each hero image, where saturated colour is allowed, the type roles, the shape of controls, the shared contracts that change). Never hand the notes to clones as a task list. Apply the plan's

   orchestrator

   fixes yourself.
5. Apply the stop rule (orchestration module), the disposition first:

   recapture

   means recapture and run the verdict again;

   rebuild

   sends you back to the review. Then: ship when nothing above minor is left, stop at the tier's round cap, stop when a round fixed nothing. Otherwise the next round starts at step 1.

• DESIGN.md: spawn Impeccable's documenter by the agent type the host lists (Claude Code:

  impeccable-documenter

  ) with the project root, the artifact paths (the source folders and the built output), the direction contract, PRODUCT.md, the absolute path of Impeccable's

  reference/document.md

  , and the write boundary (the project root); it writes DESIGN.md and

  .impeccable/design.json

  from the shipped code. Without Impeccable, write DESIGN.md yourself from the shipped code, never from intentions.
• AGENTS.md (with a

  CLAUDE.md

  pointing to it): for the AI that will maintain the site, in the client's language. Where each kind of change is made, the design rules, the writing rules, the commands, what to check before pushing.
• A launch guard: a build-time warning listing every fact still missing (contacts, legal details, the domain), with a strict mode that fails the production build.
• The audit, below, run over the whole project.
• The report, below, also written to

  .bunshin/report.md

  .

check - verdict - the evidence

file:line

• Thesis against code. First, because every check below assumes the code is the thesis that was validated. For each promise the validated thesis actually makes (durations, easing, springs, palette, type, layout family) give the

  file:line

  that holds it, or "not found". A thesis that makes no palette or type promise, an interaction thesis alone, gets no palette or type line. A promise with no

  file:line

  is a problem found, not a pass. Honest downgrade: when promised motion cannot be shipped working, ship the static version, say so here, and name the promise that was dropped; it counts as a problem found. Never ship motion that is half broken to keep a promise on paper. Evidence: one line per promise, e.g.

  hover 180ms ease-out - src/Card.tsx:42

  .
• Reduced motion honoured. Web: a

  prefers-reduced-motion

  block that actually degrades the animation, not an empty one. SwiftUI:

  accessibilityReduceMotion

  . Compose: a helper on

  ValueAnimator.areAnimatorsEnabled()

  /

  Settings.Global.ANIMATOR_DURATION_SCALE

  . Evidence: the file and line of the guard, and what it degrades to.
• Exit animations present wherever something unmounts. Evidence: the conditional render and its exit path, or the list of unmounts that have none.
• No layout-property animation. Nothing animating

  width

  ,

  height

  ,

  top

  ,

  left

  ,

  margin

  or

  padding

  ; use transform, opacity or

  graphicsLayer

  . Evidence: the grep and its hits, or that it returned nothing.
• Focus visible on every interactive element, and no

  outline: none

  without a replacement. Evidence: the grep.
• All five states on interactive elements: default, hover or press, focus, active, disabled. Evidence: the states you found per component, and the ones missing.
• Tokens, not magic numbers. Colours and spacing come from the project's design tokens (MASTER.md when one exists). Evidence: the rogue values, with

  file:line

  .
• Contrast at least 4.5:1 for body text, 3:1 for large text and UI boundaries. Compute it from the token values you emitted; do not eyeball a swatch. Evidence: the pair and the computed ratio, e.g.

  #831843 on #FDF2F8 = 9.4:1

  .
• Semantics. Web: no clickable

  div

  without a role,

  aria-hidden

  on decorative motion. Compose:

  Modifier.semantics

  on custom interactive components. SwiftUI:

  .accessibilityLabel

  on controls that have no text. Evidence: the grep.
• Web only. Conditional renders wrapped in

  AnimatePresence

  or the framework's equivalent;

  will-change

  used sparingly and removed after the animation. Evidence: the grep.
• Tells confronted with the thesis. Only when

  tells

  was loaded. In one shell call, re-emit the skill-base block and run

  python3 "$SKILL_BASE/design-audit/scripts/audit.py" . --group tells

  , whether or not

  design-audit

  was loaded. Evidence, for each finding: either the problem you kept, with its

  file:line

  , or the entry of the thesis's

  Allowed patterns:

  line that names it. A kept tell counts among the problems found. An allowed one is listed as "allowed by the thesis", with that entry quoted, and is not a problem. The manual reads

  tells

  lists (fake product in divs, repeated layout family, floating corner paragraph, copy register, copy held in JavaScript data) are reported the same way. Each finding has one of three outcomes, never a fourth: allowed by the thesis, its

  Allowed patterns:

  entry quoted; not this tell, only when the detection contradicts the entry's own marker (the loop reports a real loading state, the blur is a modal backdrop, the matched line is not displayed text), with the

  file:line

  that proves it and never on a matter of taste; or a problem. Fix before you report, and only what this run introduced: a problem on a line this run wrote (read

  git diff

  when the project has one) is removed or rewritten, then this check runs again, two passes at most, and what still fails is reported with its

  file:line

  . A tell that was already in the project, on a line this run did not write, is never changed here: it is listed for the user. Nothing on the protected list of an existing project (public token names, URLs, navigation labels, form field names, logo, legal mentions) is changed by this step.

1. Built: the routes, per language, and where the design system and the contract live.
2. Verified, with the evidence: build, type check, detector, tells, captures (where), each functional test with its measured value, the last verdicts and their dispositions.
3. Not verified: the handed-over rows of the audit, marked UNVERIFIED, and anything a lens could not check.
4. Left: the minor points after the last round, by page.
5. For the client: every fact still missing, from

   missing.md

   and the content files, and the open questions the clones raised.
6. Cost: the tier, the rounds run, the agent count per workflow, and the tokens when the host reported them.
7. Assumptions, and in a headless run every gate answer marked UNVALIDATED.
8. The two module lines, from the audit.