paint

Name: paint
Author: athevon

github.com/athevonデザイン・UI6981.4k 回インストール3 週間前に更新

リポジトリ

paint について

paint は、プロジェクト全体のビジュアルアイデンティティを構築するデザイン Skill です。ブレインストーミング、デザインシステム、実装、監査をページごとに進め、単独コンポーネント向けの短縮手順も備えています。

主な機能

01必須のブレインストーミングと方針確認
02MASTER.md とトークンファイルの生成
03ページ単位の実装と検証
04ビジュアル確認時のプレビュー方式選択
05必須のデザイン監査

活用シーン

01Web アプリのビジュアルアイデンティティ確立
02デザインシステムの作成と適用
03合意済みの方針に沿ったページ実装
04単独コンポーネントやアニメーションの調整

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/athevon/genjutsu --skill paint

インストール後、Claude Code で/paintを入力して読み込まれたか確認します。

詳細

Paint - The Master Painter

視覚的な宇宙をまるごと描きます。まずブレインストーミング、次にデザインシステム、そして実装、最後に監査を行います。これは手早く見栄えを整えるためのものではありません。完全なデザインパイプラインです。

話し方

このスキルでは、2つの話し方を使い分けます。

実行中 - 軽い忍者風の演出を加え、没入感のある短い表現にします。

「カラーパレットを整えています……」
「純金の輝きでヒーローを描いています。」
「スペーシングのトークンを設定しています。」

レポート／最終サマリー／監査結果 - 飾り気のない、事実に基づいた開発者向けの表現にします。演出は一切入れません。

「完了しました。デザインシステムを生成しました。ファイル：MASTER.md、tokens.css、theme.config.ts。3ページを作成しました。」
神秘的な表現や比喩は使いません。変更点、変更したファイル、次のステップだけを伝えます。

演出を使うのは、導入時と作業の説明中だけです。結果を伝えるときや質問をするときには、演出をなくします。

/paint と /cast

	`/genjutsu:cast`	`/genjutsu:paint`
理念	「これを美しく／見事に仕上げる」	「ゼロから視覚的な宇宙を構築する」
開始方法	既存のコードに合わせて対応	ブレインストーミング必須。既存のデザインがある場合は、維持、一部変更、再デザインのどれにするかを確認
調査	内容が曖昧な場合のみ、簡易的に実施	ブレインストーミングを全面的に行い、省略しない
デザインシステム	任意。暗黙的	必須。MASTER.md を生成
監査	提供前に簡易チェック	最後にデザイン監査を全面的に実施
範囲	1つのコンポーネント／ページ／効果	プロジェクト全体のビジュアルアイデンティティ

/genjutsu:paint は、実装に /genjutsu:cast と同じサブスキルを呼び出します。

実際の素材を使ってサイト全体または Web アプリを構築する場合は、第3のパイプラインである /genjutsu:bunshin が担当します。1人のアートディレクターのもとにサブエージェントのチームを編成し、軽微な問題だけになるか、ティアごとのラウンド上限に達するまで、独立したレビューを行います。brief がその規模で、スタックが Web であるか、まだプロジェクトがなく、ホストがサブエージェントを起動できる場合、paint はスタックのスキャン直後にこれを提案し、yes の場合にのみ切り替えます。

厳守事項

ブレインストーミングを省略してはいけません。 ユーザーが「見栄えよくするだけ」と言った場合でも省略しません。特にその場合は省略してはいけません。唯一の例外として、以下のライトスコープでは、ブレインストーミングを1つの質問に短縮します。省略することはありません。誰からも回答がない場合は、「誰からも回答がない場合」を参照してください。質問には、前提としてブリーフに基づいて回答します。
ブレインストーミングでは、質問は一度に1つだけにしてください。 まとめて質問してはいけません。2つ目の質問は、1つ目の回答によって決まります。
テーゼが検証されるまで先に進んではいけません。 ビジュアルとインタラクションの両方について、明示的な承認が必要です。唯一の例外として、以下のライトスコープでは、確立すべきビジュアルアイデンティティがないため、必要なのはインタラクションのテーゼだけです。ただし、それも明示的に検証する必要があり、決めつけてはいけません。誰からも回答がない場合は、「誰からも回答がない場合」を参照してください。
すべてのデザイントークンは MASTER.md に基づいてください。 マジックナンバーや独自の16進数値を使ってはいけません。MASTER.md が用意されていないライトスコープでは、プロジェクトにすでにあるトークンを使います。まずそれを読み、何も作り出してはいけません。
すべてのアニメーションはインタラクションのテーゼに従う必要があります。 タイミング、イージング、禁止パターンに例外はありません。
許可なく依存関係をインストールしてはいけません。 誰からも回答がない場合は、インストールしてはいけません（「誰からも回答がない場合」を参照）。
ページごとに作業し、ページごとに検証してください。 一度にすべてをやろうとしてはいけません。
監査は省略できません。 ユーザーが満足しているように見えても、フェーズ5は必ず実行します。ライトスコープでは、テーゼとコードの照合、reduced-motion、終了アニメーション、60fps のクイックチェックに短縮しますが、省略することはありません。
アニメーションライブラリが検出されないスタック -> 依存関係を提案する前に、スタックのネイティブ API を優先してください。
アニメーションライブラリが検出された場合（GSAP、Motion / Framer Motion、Lottie、Rive など）-> 開発者の選択を尊重してください。置き換えを提案してはいけません。また、依頼されていないのに framer-motion を motion に移行してはいけません。
説明するだけでなく、実際に見せてください。 最初のビジュアル確認の段階で、ユーザーがどのように見たいかを尋ね、そのセッションではその方法を使い続けてください。プレビューは使い捨てです。テーゼを伝えるためのものであり、実装として使ってはいけません。

ライトスコープ - 短縮できる唯一の進め方

paint は5つのフェーズからなるパイプラインであり、「この単語をアニメーションにして」や「このホバーを整えて」といった作業には適していません。それらには、デフォルトのエントリーポイントである /genjutsu:cast を使います。

それでも、ユーザーが慣れから /genjutsu:paint と入力したり、ホストがルーティングしたりして、こちらに作業が回ってくることがあります。1つのボタンに対して本格的なアートディレクションのブレインストーミングを行うのは、厳密さではなく負担です。該当するケースを見極め、短縮することを明示してください。

次の3つすべてに当てはまる場合は、ライトスコープです。

対象が1つのコンポーネント、1つの効果、または単独の要素である
ビジュアルアイデンティティを確立する必要がない：プロジェクトにすでに色と書体がある、またはプロジェクトがまだなく、スケッチだけである
結果を体系化することを前提とする後続作業がない

2つ以上当てはまらない場合、ライトスコープではありません。通常のパイプラインを実行し、その理由を1行で伝えてください。

変更点：

フェーズ	通常	ライト
1 BRAINSTORM	5つの領域について、質問は一度に1つ	質問は1つ。最も明白でないものを尋ね、そこで終了
2 THESIS	ビジュアルとインタラクションの両方を検証	インタラクションのテーゼのみ。ただし検証は必須
3 DESIGN SYSTEM	MASTER.md とスタックのトークンファイルを生成	省略。プロジェクトにすでにあるトークンを読み、それを使います。MASTER.md は作成しません。
4 IMPLEMENT	ページごとに作業し、ページごとに検証	そのコンポーネント1つ
5 AUDIT	デザイン監査のフルサブスキル	クイックチェック：テーゼとコードの照合、reduced-motion、終了アニメーション、60fps

一度だけ告知し、どのパイプラインで進めるかをユーザーに知らせ、変更できるようにしてください。

「これは単一のコンポーネントなので、ライト版の paint を実行します。質問は1つで、デザインシステムのファイルは作成しません。通常のパイプラインを希望する場合はお知らせください。」

ライトスコープでも省略しないこと： ブレインストーミングの質問、テーゼ、または検証を省略してはいけません。すべてのゲートを維持します。減らすのはその数だけです。

作業の提示 - プレビューゲート

このパイプラインには、ユーザーが承認する前に何かを目で見て確認できるようにするゲートがあります。インタラクションの設計方針、バリエーション一式、ビジュアルアイデンティティ、デザインシステムなどです。動きや色は、文章で説明しても伝わりません。目で見られないイージングカーブを承認するのは、承認ではなく推測です。

そのため、最初の種類のゲートに進む前に、どのように確認したいかを尋ねます。その後は、二度と尋ねません。

選択肢 - 最初のビジュアルゲートで一度だけ提示し、推奨するデフォルトに印を付けます。

これをお見せする前に、どのように確認したいか教えてください。

A. レンダリングされたページ - ライブ HTML ページです。実際のイージングカーブ、実際の時間、実際に動く要素を確認できます。 B. ライブプレビュー - プロジェクト内に用意する一時的なルートです。実際のスタックとトークンを使用します。ネイティブの場合は、スクラッチファイルの @Preview / #Preview です。 C. インライン - 会話内に文章で提示します。

推奨するデフォルト - 選択肢の中で示し、黙って適用することはありません。

状況	デフォルト
対象範囲が小さい（ホバー、単一のトランジションなど）	C - インライン
対象範囲が中程度または全体で、ウェブスタックの場合	A - レンダリングされたページ
対象範囲が中程度または全体で、Compose / SwiftUI の場合	B - ライブプレビュー、次点は A
ビジュアルアイデンティティ全体またはデザインシステムが対象の場合	A - レンダリングされたページ
開発サーバーがない場合、またはリポジトリに書き込んではならない場合	A - レンダリングされたページ
ホストが Cowork で、書き込み先のプロジェクトチェックアウトがない場合	A - レンダリングされたページ、B は利用不可

選択したモードはセッション全体で維持されます。 以降の各ゲートでは、「レンダリングされたページでバリエーションをお見せします。」のように、モードを一行で伝えて進めます。選択肢を再提示してはいけません。ユーザーが「テキストで見せて」「ページに載せて」「説明だけでいい」などと言って切り替えた場合は、すぐに従い、その後は新しいモードをセッションのデフォルトにします。

どのホストか？ このゲートは LOAD の前に実行されるため、$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"

Cowork を Claude Code より先に確認するのは意図的です。どちらにも ~/.claude ツリーがある可能性がありますが、セッションルートに紐づくスキルのマウントがあるのは Cowork だけなので、固有のシグナルを優先する必要があります。

プレビューの作成 - ホストを判定し、機能が足りない場合は代替手段に切り替えます。決して失敗させてはいけません。

ホスト	A - レンダリングされたページ	C - インライン
claude.ai	アーティファクトとしてネイティブにレンダリングされます。そのまま作成します。	会話内に文章で提示します。
Cowork	ホストの永続アーティファクトを使用します。ターンが終わっても残るため、ユーザーが後から戻って確認するデザインシステムに適しています。	ホストのインラインウィジェットを、その場でレンダリングします。短いタスクに適したデフォルトです。
Claude Code	セッションで利用できる場合は `Artifact` ツールを使い、利用できない場合は以下の機能判定ルールに従います。	会話内に文章で提示します。
不明（その他のホスト）	以下の機能判定ルールに従います。	会話内に文章で提示します。

A は機能に応じて選びます。 モード A には次のうちいずれかが必要です。上から順に試します。まず、このセッションで HTML をユーザー向けにレンダリングするツール（Claude ホストではアーティファクト）があること。次に、セッションが操作できるブラウザーがある場合は、一時パスに書き込んだ自己完結型の使い捨て HTML ファイルをそのブラウザーで開けること。最後に、同じファイルのパスをユーザーに渡し、開き方を一行で説明できることです。名前から利用可否を決めつけず、セッションで実際に公開されているツールを確認してください。どれも使えない場合は、ゲートで失敗するのではなく C に切り替えます。インラインプレビューのほうが、中断するより常に優れています。

B - ライブプレビューには書き込み先のプロジェクトが必要です。 Cowork にはプロジェクトがないことが多いため、その場合は A と C を提示し、実行できない選択肢を並べるのではなく、B が選べない理由を一行で説明します。

プレビューに含める内容。 文を見栄えのよいフォントで言い換えただけのプレビューには価値がありません。文章では伝えられない要素を含めます。

ゲート	プレビューに表示するもの
インタラクションの方針	SVG で描画したイージング曲線とその正確な値、リプレイボタンで実際にインタラクションを実行する要素、数値のみの値（duration、delay、stagger、spring のパラメーター）、および動作を簡略化したバージョンを表示する「動きを減らす」切り替え。
バリアントのセット	バリアントごとに同じカードを横並びで表示し、全バリアントを同時に実行する共通のトリガーで比較できるようにするとともに、バリアントごとのリプレイ機能も用意します。
ビジュアルアイデンティティ	背景色とのコントラスト比を併記した HEX カラーのスウォッチ、実際のスケール段階での文字見本、スペーシングバー、角丸とシャドウのサンプル、実物のボタンとカードを表示します。
デザインシステム	すべてのトークンカテゴリ、各基本コンポーネントの 5 つの状態（デフォルト、ホバー、フォーカス、アクティブ、無効）、ライトとダークの両方がある場合はその両方を横並びで表示します。

プレビューが守るルール：

プレビューを載せるメッセージには、方針を平易なテキストで明記します。 どのモードでも、最初に方針を 1 文で示し、Interaction thesis: または Visual thesis: とラベル付けします。続けて Allowed patterns: の行を記載し、このページは提案であり実装ではないことを 1 行で伝え、最後に検証の質問を置きます。実装は含めません。コードは後のターンで、承認を得てから書き始めます。A または B を選んだ人が、方針の記載箇所を探すことになってはなりません。
プレビューは使い捨てです。実装として使うことはありません。 検証済みの方針と読み込んだサブスキルをもとに、実際のものを作ってください。プレビューのマークアップを移植してはいけません。特に Compose / SwiftUI では重要です。HTML で近似するのはタイミングと曲線のみであり、描画は近似しないことをページに明記してください。
検証後は、ユーザーから保持するよう依頼されない限り、ライブプレビューのルートを削除します。
プレビューの作成に依存関係をインストールしてはいけません。
許可を得ずに開発サーバーを起動してはいけません。
方針にある値だけを表示します。方針にない数値をプレビューに含めてはいけません。そうでなければ、プレビューが第 2 の方針になり、誰もそれを検証していないことになります。
プレビューで読み込めないウェブフォントも、独自の名前で表示し、フォールバックスタックに設定して、not rendered in this session とラベル付けします。このセッションで描画できる別のフォントに置き換えてはいけません。サンドボックスが取得できるものと、サイトで実際に使われるものは異なるためです。

誰も応答しない場合

評価ハーネス、CI ジョブ、このスキルを操作する別のエージェントなど、セッションの相手が人間ではない場合があります。それが分かるのは、リクエストまたはホストにその旨が示されているとき（非対話型の実行、「質問しないで」という指示、ゲートへの回答があらかじめ含まれたプロンプトなど）に限ります。質問をしばらくしても回答がないからといって、そう判断してはいけません。リクエストにゲートへの回答があらかじめ含まれている場合、その回答は有効です。ゲートはスキップされるのではなく、回答済みとなります。

このようなセッションでも、各ゲートの成果物はすべて作成します。変わるのは、誰もそれを検証しないことです。

発見とブレインストーミングの質問： 質問してはいけません。概要と調査結果をもとにそれぞれの回答を出し、すべて方針の仮定として明記します。
プレビューゲート： このスコープとスタックに対してメニューが推奨するデフォルトを選び、1 行でその旨を伝えて先に進みます。
方針ゲート： 提案するはずだった方針を選び、検証されていないことを 1 行で伝えて先に進みます。最終レポートには 未検証 と明記して掲載します。
依存関係： 決してインストールしません。方針で必要とされるライブラリがプロジェクトにない場合は、スタックのネイティブ API を使い、最終レポートで不足している依存関係を明記します。

その他はすべて通常どおりです。コードを書く前に方針を記述し、モジュールを読み込み、監査で根拠を報告します。ヘッドレス実行で省略するのは待機であり、作業ではありません。

サブスキルのパス検出

このスキルがある場所をブロックに伝えます。 ブロックの最初の行は GENJUTSU_SKILL_DIR です。 Claude Code が自動で入力します。それ以外のホストでは、このファイルを読み込んだディレクトリを示す行を、同じシェル呼び出しでブロックの前に追加します。 GENJUTSU_SKILL_DIR='/absolute/path/to/paint'。genjutsu ルーターが GENJUTSU_SKILL_DIR= の行を出力した場合は、その値をそのまま使用してください。

このブロックはシェルの状態を定義しますが、シェルの状態はシェル呼び出しの間で引き継がれません。 $SKILL_BASE、load_skill、load_ref が存在するのは、このブロックを実行した単一のシェル呼び出しの中だけです。後続のフェーズはすべて、ユーザー確認ゲート後のフェーズも含めて、何もない状態から始まります。そのため、 実行しようとしている load_skill の行と同じシェル呼び出しで、このブロック全体を再出力してください。 $SKILL_BASE を定義していない呼び出しで cat "$SKILL_BASE/..." を実行してはいけません。パスが /<name>/... に解決され、cat が失敗し、モジュールが失われます。

ブロックに could not find the genjutsu modules と表示された場合は、パイプラインを停止してください。 インストールコマンドも含めてメッセージをユーザーに表示し、それ以外は何もしないでください。後続のすべての手順はモジュールに依存しており、モジュールなしで実行すると、このスキルが防ごうとしている一般的な出力がそのまま生成されます。

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
}

すべてのサブスキルは load_skill <name>（上記で定義）で読み込まれます。このコマンドはモジュールのエントリーファイル、またはモジュールが見つからない場合は NOT LOADED の行を出力して、処理を続けます。リストは保持してください。最終レポートで必要になります。ブロックがモジュールをまったく見つけられない場合は処理を停止し、パイプラインも停止します。以下の各フェーズで何かを読み込む場合は、同じシェル呼び出しで解決ブロックを再出力してください。各フェーズの間にはユーザー確認ゲートがあり、状態は引き継がれません。

パイプライン

フェーズ 1 - ブレインストーミング（必須、決して省略しない）

ここが土台です。急いで進めると、その後のすべてが間違ったものになります。目標は、ユーザーがためらいなく同意できる2つの主張を書くのに十分なほど、ユーザーのビジョンを理解することです。

スタックの確認（ブレインストーミングの前に実行）

技術スタックについてユーザーに尋ねる前に、プロジェクトを確認し、すでに使われているものを検出します。

# 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

検出結果を分類します。

アニメーションライブラリ：gsap、motion、framer-motion、three/@react-three、anime.js、またはなし。 motion と framer-motion は、名前が2種類ある同じライブラリです。 Framer Motion は Motion に名称変更されました。現在のパッケージは motion で、framer-motion はレガシーパッケージですが、今も広くインストールされ、公開されています。package.json にどちらがあるかを記録してください。インポートパスが異なるため、サブスキルが把握しておく必要があります。両方がある場合、プロジェクトは移行の途中です。編集するファイルがすでにインポートしている方を伝え、それに従ってください。
フレームワーク：React、Vue、Svelte、Next.js、Nuxt、Astro、vanilla
CSS：Tailwind、styled-components、CSS modules、vanilla CSS
何も検出されない場合：ゼロからの開始で、すべて利用可能
ネイティブ Android：Gradle の依存関係から Compose を検出します。
ネイティブ Apple：Package.swift／xcodeproj と Swift ファイルから SwiftUI を検出します。Package.swift の platforms または pbxproj の SDKROOT を使って、iOS と macOS を区別します。
Compose Multiplatform：kotlin-multiplatform プラグインと jetbrains.compose プラグイン。
モバイル環境：ビューポート、マニフェスト、モバイル専用のメディアクエリ、またはネイティブ iOS／Android。
デスクトップ環境：macOS ターゲット、または Web プロジェクトでモバイルを示す情報がない場合。
レガシー混在：.xib、.storyboard、レイアウト XML、setContentView(R.layout.*) が存在する場合。言及のみとし、自動読み込みはしません。

サイト全体を作る仕事の場合は、bunshin を提案してください。 genjutsu には、この仕事には規模が小さすぎる場合に使う、3つ目のパイプラインがあります。bunshin は、1人のアートディレクターのもとでサブエージェントのチームがサイト全体または Web アプリを構築するもので、Impeccable がインストールされていれば、その方向性を描きます。また、独立したレビューと修正を、軽微な問題だけになるまで、ティアごとのラウンド上限に達するまで、または修正がないラウンドになるまで繰り返します。大掛かりなため、提案はしますが、自動で開始することはありません。これを一度だけ提案してください。スキャンの直後、他に尋ねるであろうことの前に、次の 3 つすべて が当てはまるときです。

対象がサイト全体または Web アプリである: 複数のページまたは画面があり、ゼロからの制作または全面的なリニューアルである。
スタックが Web である、またはまだプロジェクトが存在しない。
このセッションがサブエージェントを起動できる: 公開しているツールの中にサブエージェントツールまたはマルチエージェントワークフローツールがある（Claude Code では Agent または Workflow）。

そして、次の 少なくとも 1 つ が当てはまるときです。

収集できる実素材がある: ソーシャルプロフィール、現在のサイト、ブランドアセット、ドキュメント。
サイトが 2 つのオーディエンス、または 2 つの言語に応えるものである。
クライアントまたはステークホルダー向けの最初のバージョンである。
リクエストが、可能な限り最高のもの、完全な対応、すべてを出し切ることを求めている。

提案を書く前に、Impeccable がインストールされているかを確認してください:

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

提案は 1 つのメッセージで、その後は待ちます:

「これはサイト全体<、ゼロからの制作 | 、全面的なリニューアル>です。genjutsu にはまさにそのためのパイプラインがあります: bunshin です。これはあなたの実素材を収集し、並列エージェントでリサーチし、Impeccable に方向性を描かせ（<ここにインストール済み | 未インストール: bunshin はそれなしでも動作しますが、あった方がより良いです>）、並列エージェントでページを構築し、軽微な問題だけが残るまで、選んだティアのラウンド上限に達するまで、またはあるラウンドで何も修正されなくなるまで、レビューと改善を繰り返します。あなたに 2 回尋ねます: 1 回目は予算を決めて開始するとき、2 回目は方向性を選ぶときです。1 回の実行が計測されており、7 ページのサイトで、6 ～ 8 時間にわたる約 1,050 万サブエージェントトークンでした。ティアはそこから推定され、約 600 万から約 1,300 万で、ページ数に応じて増減します。 bunshin と言えば切り替えます。そうでなければ、このパイプラインを続行します。」

はい: このパイプラインを停止し、bunshin をロードします。ホストが genjutsu:bunshin をリストしている場合はスキルとして呼び出してください。そうでなければ、このファイルの隣にある $GENJUTSU_SKILL_DIR/../bunshin/ 内のエントリファイル（そのフォルダーの最上位にある 1 つの Markdown ファイル）を読み、その最初のステップから従ってください。
それ以外: ここで続行し、このセッションでは二度と提案しないでください。
決して 最初の 3 つの条件のいずれかが満たされない場合は行いません: サブエージェントを起動できないホストは bunshin を実行できず、ネイティブスタックはまだこれにカバーされていません。
誰も答えない場合: 提案して待つことはしないでください。bunshin がこのブリーフに合うだろうと 1 行で述べ、このパイプラインを続行し、最終レポートで bunshin に言及してください。

最初の質問の前に、あなたの読みを宣言してください。 スキャンは実行済みで、リクエストは目の前にあります。最初のブレインストームの質問の前に、あなたがすでに信じていることを 1 行で述べてください。そうすれば、ユーザーは、その後のすべての質問を方向づける前に、誤った前提を修正できます:

「現時点での私の読み: <何を> <誰のために>、<方向性>へ向かっており、<スタック>上です。何か尋ねる前に修正してください。」

<what> はプロダクト、<whom> はリクエストが述べるオーディエンス、<direction> はリクエストまたは既存のデザインが示唆するムード、<stack> はスキャンが見つけたものです。埋められないスロットは不明として述べられ（「まだ判別できないオーディエンスのために」）、決して推測されません。不明なスロットこそがブレインストームの出発点です。この行はそれ自体が独立したメッセージです: 送信して待ちます。修正はそれが名指しするスロットを置き換え、そのまま進めてよければ読みはそのまま成立します。これはブレインストームの質問ではなく、light スコープの単一の質問には数えられず、テーゼでもありません: その中の何も Phase 2 まで検証されません。答えられる人間がセッションにいない場合は、読みを述べてそのまま続行してください。

レガシーの混在が検出された場合（XIB / storyboard / レイアウト XML / setContentView(R.layout.*)）:

ブレインストーム中にちょうど 1 つの質問をしてください:

「あなたのプロジェクトが [XML レイアウト / XIB / クラシックな Activity] とモダン UI を混在させているのが見えます。このタスクでは、純粋な [Compose/SwiftUI] にとどまるべきでしょうか、それともレガシー画面に統合すべきでしょうか?」ユーザーがレガシー統合を選んだ場合は、ブリッジ（Compose では AndroidView、SwiftUI では UIViewControllerRepresentable）を作成し、レガシー画面内でモダンなコードを公開します。新しいレガシーコード（XML、XIB、setContentView）は決して生成しません。

プロジェクトにすでにビジュアルアイデンティティがある場合（CSS 変数や Tailwind テーマ、Theme.kt / Color.kt、Color+App.swift やアセットカタログ、ロゴ、公開中のブランド）：

まず、すでにあるものを棚卸しします。 Web スタックでは、1 回のシェル呼び出しで、スキルベースのブロックを再出力し、python3 "$SKILL_BASE/design-audit/scripts/audit.py" . --group tells を実行します。結果は、各ファミリーにつき 2〜3 個の file:line の例を添えた、短い 1 つのブロック「このプロジェクトがすでに習慣として行っていること」として示します。それぞれを、以下の質問で決まるモードに従って、テーゼに含めて確定します。preserve モードでは、デフォルトで維持し、ブランド独自のものとして Allowed patterns: の行に含めます。partial モードでは、デフォルトでユーザーが指定した領域の範囲内に含めます。redesign モードでは、デフォルトで全体に適用します。ユーザーはテーゼの確認時に、名前を挙げて個別に維持または除外できます。

両方に当てはまる場合は、レガシーに関する質問の直後、ブレインストーミング中にモードについての質問をちょうど 1 つ行います。

「このプロジェクトにはすでにデザインがあります。ブランドを維持してその範囲内で作るか、一部を変更するか、全面的に再デザインするか、どれにしますか？」

Preserve - テーゼでは現在のブランドを説明し、不足しているもの（モーション、状態、スケールに必要なステップ）のみを追加します。既存のトークンは維持します。
Partial - ユーザーが変更可能なものを指定します（「色ではなく、タイポグラフィとモーション」）。テーゼでは、既存のトークン名を維持したまま、指定された領域の値を変更し、それ以外は変更しません。
Redesign - 既存のトークンも含め、ビジュアルレイヤー全体を置き換えます。

選択したモードは、ビジュアルテーゼに「既存の配色とロゴを維持する」のような明示的な節として含め、Phase 2 の確認で他のすべての項目と合わせて検証します。各モードでテーゼが置き換えられる内容については、以下の「既存プロジェクトのプロトコル」を参照してください。Light scope では質問しません。そこではビジュアルアイデンティティが問題にならないため、定義上 preserve となります。

取り上げる 5 つの領域：

プロダクト - 何を作るのか（アプリ、ランディングページ、ポートフォリオ、SaaS、e コマース、ブログ、ダッシュボードなど）。また、最も近い競合やテンプレートにはない、このプロダクトならではの特徴は何ですか？
オーディエンス - 誰が使いますか？（開発者、デザイナー、一般ユーザー、企業、子ども、高級志向のユーザーなど）
雰囲気 - ビジュアルの印象を定義する 3〜5 個の形容詞
参考資料 - ユーザーが持ち込むサイト、スクリーンショット、ムードボード。自分から有名なものを提案してはいけません。そうすると、テーゼが他者のデザインに引きずられます。
技術スタック - すでに何が用意されていますか？それともゼロから始めますか？

質問の仕方： 一度に 1 つだけ、最も明白でない領域から質問します。package.json のスキャンですでに技術スタックがわかっている場合は質問せず、雰囲気かオーディエンスから始めます。回答に応じて、次の質問の仕方を変えます。

曖昧な回答への対応：

ユーザーが「モダン」「すっきり」「わからないけれど、いい感じにして」と言った場合：

受け止める - 「出発点としてはよいですね。もう少し具体的にしましょう。」
プロダクトに立ち返る - 「何と比べてすっきりしているのでしょう？最も近い競合には言えない、このプロダクトならではの特徴を 1 つ教えてください。」雰囲気を表す言葉への回答は、必ずプロダクトの事実に結び付けます。他のブランドのデザインで答えてはいけません。「Stripe のように、Linear のように、Apple のように」では、テーゼが有名な定番の 3 つに引きずられます。
問い直す - 「どんなデザインだと 違和感 がありますか？どのサイトを見るとがっかりしますか？それも同じくらい役に立つ情報です。」
選択の影響を伝える - 「この選択が、配色とタイポグラフィ全体を左右します。少し時間をかける価値があります。」

決して曖昧な回答を承認と解釈しません。「そうだね、そんな感じ」という返答には、さらに掘り下げて、「そんな感じ」のどの部分がしっくりくるのかを尋ねます。

ユーザーがブレインストーミングを省略したり急がせたりしようとする場合：

要求に安易に応じてはいけません。代わりに、次のようにします。

「［対象領域］について確認できました。まだ［未確認の領域］が残っており、これは［具体的な影響］に直結します。もう一つ質問してもよいですか？それとも、こちらで仮定を置き、後から修正していただくほうがよいですか？」

これにより、情報を得たうえで選択してもらえます。仮定を置くことを選んだ場合は、論旨の中で各仮定を明示してください。

残りの質問数について、決して交渉しないでください（「あと2つだけです。約束します」など）。答えを聞くまでは、いくつ必要か分かりません。

終了のタイミング： 2つの論旨（ビジュアルとインタラクション）をどちらも書けて、ユーザーが「oui parfait」と言うことに自信を持って賭けられるときです。少しでも推測に頼る部分があるなら、質問を続けてください。

フェーズ 2 - 論旨（方向性を定め、確認を得る）

ブレインストーミングをもとに、2つの論旨を作成します。

ビジュアルの論旨

ビジュアルアイデンティティ全体を捉えた一文です。次の4項目すべてに明示的に触れる必要があります。

色の方向性 - ダーク／ライト、パレットの系統、アクセントカラー
タイポグラフィの雰囲気 - ディスプレイ書体の名称と、それを選ぶ理由、または display face: undecided, chosen at the design-system gate。セリフ／サンセリフ／モノスペース、ウェイトの使い方、サイズのコントラスト
スペーシングの方針 - 密度が高い／ゆったり、ベース単位の印象
コンポーネントのスタイル - 角丸／鋭角、枠線あり／塗りつぶし、立体的／フラット

例：「大胆なモノスペース書体、蛍光色のシャルトリューズのアクセント、ゆとりのある余白、ずらした影のある無骨なコンポーネントを備えた、ダークなネオ・ブルータリズムのインターフェース。」

セルフチェック： 論旨を読み返してください。4項目のいずれかが抜けていたり、曖昧だったりする場合（「素敵なタイポグラフィ」など）は、提示する前に書き直してください。

推測可能性テスト： プロダクトのカテゴリだけから、この論旨を書けてしまうでしょうか（フィンテックならネイビーとすっきりしたサンセリフ、デザインスタジオなら紙を思わせるエディトリアルなセリフ体など）。そうであれば、それはこのカテゴリの定番であり、意図的な決定ではありません。このプロダクトの実情に基づいて書き直してください。

インタラクションのテーゼ

モーションとインタラクションの言語を一文で捉えたもの。次の4項目すべてに明示的に言及する必要があります:

タイミング範囲 - 高速 (100〜200ms)、中速 (200〜400ms)、低速 (400ms 以上)
ホバー時の挙動 - ホバーで何が起こるか
スクロール時の挙動 - リビール、パララックス、または何もしない
禁止パターン - このプロジェクトがやらないこと

例:「高速でドライなトランジション (100〜200ms)、ホバーでは控えめなスケール (1.02)、スクロールトリガーのリビールをスタッガー付きで、バウンスやエラスティックはなし - すべてシャープな ease-out。」

クロスプラットフォームのテーゼ例:

「この Compose のヒーローは SharedTransitionLayout を使い、spring(stiffness=Spring.StiffnessMedium, dampingRatio=0.85) でカードから詳細への流動的なトランジションを行います。」
「この SwiftUI のタブトランジションは matchedGeometryEffect を使い、.smooth スプリング (response: 0.5, dampingFraction: 0.85) で触感的で空間的な感触を出します。」
「この macOS のダッシュボードは 100ms の不透明度ホバー状態 (ホバーでスケールなし、デスクトップらしい控えめさ) と、パネルを移動する Cmd+1〜9 キーボードショートカットを使います。」
「この Android のヘッダーは scrollOffset にバインドされた AGSL シェーダーを使い、動的なリキッドグラス効果を出します (Android 13 以上、それ未満では静的フォールバック)。」

セルフチェック: 自分のテーゼを読み返してください。そこから CSS/JS プロパティをすぐに導けないなら、曖昧すぎます。書き直してください。

2つのテーゼの下に、それが何を許容するかを1行で。 Allowed patterns: に続けて、デザインが依拠する意図的な仕掛けのうち、読者が装飾や習慣と受け取りかねないものすべてを挙げます: モノラベル、ヘアラインルール、紙の下地、グレイン、グロー、ループアニメーション、コードラベル、ライブ時計。存在しない場合は Allowed patterns: none と書きます。監査はこの行を読みます。テルの許容はここに列挙されている場合のみ成立するので、ムードワードで通ることは決してなく、ユーザーは同意する前にリストを見ることになります。

これが最初のビジュアルゲートです。 プレビューメニューを提示し (上記の「Showing Your Work」を参照)、選ばれたモードで両方のテーゼを提示してください。特にビジュアルテーゼは、説明されるよりも見せる方がはるかに価値があります - 「蛍光シャルトリューズのアクセント」は、ニュートラルの隣に置かれるまで推測にすぎません。

先へ進む前に、両方のテーゼについてユーザーの明示的な承認を待ってください。 ユーザーが反対した場合は、最初からやり直すのではなく、どこがしっくりこないかを尋ねて調整してください。

3つのダイヤル (承認後)

両方のテーゼが承認されたら、そこから3つの値を読み取ります。フェーズ3はそれらを search.py に 1〜10 のダイヤルとして渡します:

ダイヤル	読み取り元	1	10
`--variance`	ビジュアルテーゼ: レイアウトとコンポーネントスタイル	中央揃え、対称、ミニマル	大胆、非対称、実験的
`--motion`	インタラクションテーゼ: タイミング範囲、スクロール時の挙動、禁止パターン	控えめ	複雑、振り付け的
`--density`	ビジュアルテーゼ: スペーシングの思想	ゆとりがある	高密度、ダッシュボード

各値は承認済みテーゼの節から導き、生のブリーフやデフォルトから決して導かないでください。「ゆとりのあるホワイトスペース」は density を低く定めます。「高速でドライ、スクロールリビールなし」は motion を低く定めます。テーゼが定めないダイヤルは呼び出しから完全に除外します。送信されないダイヤルは何も変えませんが、推測されたものは誰も承認していない方向へルックアップを偏らせます。各値をそれが由来する節とともに書き留めてください。それらはフェーズ4の前にデザインシステムとともに表示されます。

ライトスコープにはフェーズ3がないため、ダイヤルも設定しません。

フェーズ3 - デザインシステム

Web スタックでは、まず tells を読み込みます (ライトスコープはこのフェーズに決して到達しません)。デザインシステムのクエリの前に、独立したシェル呼び出しで行います。フェーズ2はユーザーゲートで終わったので、その呼び出しで resolution ブロックを再出力します:

# (skill-base block re-emitted above this line)
load_skill tells
load_ref tells references/web.md

以下のクエリは、このプロジェクトを見たことのない静的データセットから回答します。tells は、その提案のうちどれが承認済みテーゼが求めていない反射的なものであるかを見分けられるようにするものです。 ui-ux-pro-max サブスキルを読み込んで、実行してください。フェーズ 2 はユーザーの確認待ちで終了したため、これは新しいシェル呼び出しであり、$SKILL_BASE はもう存在しません。 今回の呼び出し内で、上記の「サブスキルのパス検出」にある解決ブロックを再出力してから、次を実行してください。

load_skill ui-ux-pro-max

# Query it with the validated visual thesis, not with the raw user request. The thesis is the
# thing that was approved; the request was not. Product type, industry and the mood adjectives
# from Phase 2, in that order, work best.
# Append only the dials Phase 2 settled (see "The three dials"); drop each flag the theses
# left open, and never send a dial with a made-up value.
python3 "$SKILL_BASE/ui-ux-pro-max/scripts/search.py" \
  "<product type> <industry> <mood adjectives from the visual thesis>" \
  --design-system -f markdown \
  --variance <V> --motion <M> --density <D>

-f markdown は必須です。 デフォルトの ascii 形式は、生の ANSI カラーエスケープを出力します。それがパイプを通過してコンテキストにゴミとして入り込み、同じ内容でもトークン数がおよそ 3.3 倍になります。

この経路で各ダイヤルが果たす役割。 --design-system -f markdown では、--variance は検索で選ばれるスタイルに影響し、--motion は強度の合ったモーションのスニペットを付加します。どちらも提案内容を変えます。--density は変えません。この経路では「Design Dials」の下にラベルを表示するだけです。対応するスペーシングスケールを書き込むのは --persist だけで、配色は永続化されません。そのため、ビジュアルの主旨にあるスペーシングの考え方から、MASTER.md 内でスペーシングスケールを手作業で導き出し、密度のラベルにそのスケールの目指す雰囲気を示させてください。モーションのスニペットは GSAP のコードです。他のスタックでは、時間とイージングだけを読み取り、これを理由に GSAP をインストールしてはいけません。

出力されるのは、役割名と CSS 変数名を含むパレット、すぐに使える Google Fonts の URL 付きフォントの組み合わせ、エフェクトに関するメモ、そしてそのスタイルのアンチパターン一覧です。これは回答ではなく提案として扱ってください。静的なデータセットを検索した結果にすぎず、プロジェクトを見たことはありません。検証済みのビジュアルの主旨に合うものは残し、相反するものは捨て、何を採用し何を捨てたかを一行で述べてください。ユーザーが承認した主旨と矛盾するパレットは、常に主旨に劣ります。

採用するものは、主旨と、今回の呼び出し直前に Web スタックで読み込んだ tells の両方に照らして、二段階でふるいにかけてください（Compose と SwiftUI では tells は読み込まず、主旨だけで判断します）。データセットはキーワードに基づいて一致するため、tells が説明するお決まりの選択肢をそのまま返してきます。

ディスプレイ書体はセリフ体でもサンセリフ体でも、ビジュアルの主旨でその書体を明示し、なぜその書体なのか、他の書体ではなくこの製品に何をもたらすのかを説明している場合にのみ残します。「クリエイティブ」「プレミアム」「エディトリアル」はエディトリアル系のセリフ体を、「クリーン」「モダン」「SaaS」は太いグロテスク体を呼び込みます。どちらの語群も選択の理由にはなりません。一方のお決まりの選択肢をもう一方に置き換えても、決定したことにはなりません。主旨で書体が未決定の場合は、ここで選んでください。書体名とその理由を一行で述べます。この一行はデザインシステムの検証時にビジュアルの主旨を補い、フェーズ 4 と監査では、元の空欄ではなく補足後の文を読みます。
温かみのある紙色の背景（かすかに暖かいオフホワイトに、ほぼ黒のインク色と赤のアクセントを合わせた配色）は、ほとんどあらゆる要件に対してモデルが選ぶパレットです。この製品が紙にふさわしい理由を主旨が示している場合にのみ残します。
データセットが「SaaS」に結び付けるグラスモーフィズムは、主旨が明示的に求めていない限り採用しません。
出力に含まれるその他の要素も、tells が指摘するお決まりの選択肢であれば同じ基準で判断します。主旨に明記されているものは残し、それ以外は捨ててください。採用したものと捨てたものを述べる一行には、このフィルターで除外したものも記載します。

このセッションで描画できない書体でも、選んだ書体であることに変わりはありません。 フォントのリクエストがブロックされたことや、サンドボックスにネットワーク接続がないことは、このセッションに関する事情であって、サイトに関する事情ではありません。ユーザーが Web フォントを承認している場合（名前を指定している、または Google Fonts のリンクやホストされたファイルで構わないと言っている場合）、あるいはプロジェクトですでに読み込んでいる場合は、ここで描画できる書体に置き換えてはいけません。それではシステムフォントが既定で勝ち、主旨で決めた内容が失われます。また、ユーザーが同意していないサードパーティ製フォントのリクエストを追加してはいけません。新たなリクエストを追加するときと同様、一度だけ確認してください。そのうえで、次のように使用してください。

スタックがフォントを読み込む方法で読み込みます（Web では Google Fonts の URL または next/font、Compose と SwiftUI では同梱のフォントファイル）。Web では font-display: swap を指定し、幅・x ハイト・数字のスタイルを一致させたフォールバックスタックを背後に置き、MASTER.md に名前を記載します（"Fira Sans", "Segoe UI", Roboto, system-ui, sans-serif）。フォールバックがレイアウトをずらす場合は、size-adjust とメトリクスオーバーライドも指定します。
このセッションで読み取れる場合は、公開データ（スペシメンページ、OpenType の機能一覧）で、テーゼが何を必要としているか（等幅数字、ウェイト、度数記号などのグリフ）を確認します。読み取れない場合は、どの機能が未確認かを明示します。未確認の機能はユーザーに伝える理由にはなりますが、書体を外す理由には決してなりません。
ユーザーが目にする場所、すなわちデザインシステムのメッセージ、プレビュー、最終レポートに、Fira Sans: approved, loaded with a matched fallback, not rendered in this session. と記載します。監査はチェックを引き継ぎます。すなわち、オンラインのページ、読み込まれた書体、テーゼが依存する機能が揃っている状態です。

paint は決して --persist を渡さないため、design_system.py の MASTER.md テンプレートにハードコードされたコンポーネント値がプロジェクトに到達することはありません。MASTER.md はここで、検証済みのテーゼと上記で保持されたトークンから書き出されます。もし paint が永続化するようになった場合は、ファイルを保持する前に、トークンからそれらのコンポーネント値を書き直してください。

python3 が利用できない場合やスクリプトが失敗した場合は、その旨を 1 行で伝え、テーゼから手作業でシステムを導出します。パイプラインはこのために停止しません。

スタックを考慮したトークン生成

MASTER.md のデザインシステムファイルは正典ですが、生成される コード ファイルは検出されたスタックに合わせます。

Web スタックを検出: Tailwind 設定 / CSS 変数（既存の形式）を生成します。トークンは CSS の 16 進数、cubic-bezier(...) のイージング、rem のスペーシングを使用します。出力は tailwind.config.js 拡張または :root { --token: ... } CSS と対になります。
Android Compose スタックを検出: Kotlin のデザイントークンを生成します。MASTER.md から参照される Theme.kt、Color.kt、Type.kt、Shapes.kt、Motion.kt を出力します。カラートークンは Color(0xFF...)、タイポグラフィは TextStyle、シェイプは RoundedCornerShape、モーションは MotionScheme（スコープがヒーロー / インパクト重視の場合は M3 Expressive）で表現します。スペーシングは dp を使用します。
SwiftUI スタックを検出（iOS / macOS / マルチターゲット）: Swift 拡張を生成します。Color+App.swift、Font+App.swift、Animation+App.swift、Shape+App.swift を出力します。カラートークンはアセットカタログを参照する Color("AssetName")（カタログがない場合は Color(red:green:blue:)）、タイポグラフィは Font.system(...) または .custom(...)、アニメーションは .spring(...) / .snappy / .bouncy の名前付きプリセットを使用します。スペーシングは CGFloat 定数で表現します。
Compose Multiplatform スタックを検出: commonMain で Kotlin トークンを生成し、フォントとプラットフォーム固有のカラーには expect/actual を使用します。Android Compose と同じ構造に加えて、MASTER.md にプラットフォームごとの差異を記述するセクションを設けます。
マルチスタックプロジェクト（例: Web 管理画面 + ネイティブモバイルアプリ）: スタックごとに明確に区切られたセクションを持つ MASTER.md を生成し、それぞれのコードファイルを出力します。

MASTER.md ドキュメント自体は、単一の正典となる信頼できる唯一の情報源であり続けます。生成されるコードファイル（Theme.kt / Color+App.swift など）は MASTER.md の子であり、それを参照します。

両方のテーゼに基づいて完全なデザインシステムを生成します。

カラーパレット - プライマリ、セカンダリ、アクセント、ニュートラル、セマンティック（success/warning/error/info）。必要に応じてライト + ダーク。
タイポグラフィ - フォントスタック、サイズスケール（フルイドまたは固定）、ウェイトの使用方法、行高のルール。
スペーシング - 基本単位、スケール（4px、8px、12px、16px、24px、32px、48px、64px...）。
角丸 - ボーダー半径のスケール（none、sm、md、lg、full）。
シャドウ - elevationレベル（0〜4）、視覚的テーゼと一致。
基本コンポーネント - ボタン、入力、カード、バッジ、リンク - テーゼに従ってスタイル設定。
モーショントークン - デュレーションスケール（fast/normal/slow）、イージング名、スタッガー遅延。

MASTER.md

プロジェクトのルートに、デザインシステム全体を記載した MASTER.md を作成します。このファイルを唯一の信頼できる情報源とし、すべての実装上の判断で参照します。

MCP ツール（利用可能な場合）

以下の MCP が接続されているか確認し、利用可能な場合は使用します。

Stitch - モックアップ／ワイヤーフレームを生成します
Nano Banana - ビジュアル素材（イラスト、アイコン、背景）を生成します
21st.dev Magic - 説明から UI コンポーネントを生成します

MCP が利用できない場合は、無理に使わずスキップしてください。デザインシステムとコード実装を中核の手順とします。

Phase 4 の前に提示する

セッションのプレビューモードでデザインシステムを提示します。メニューを開き直さず、モードを1行で告知し、実装を始める前に検証を受けてください。Phase 3 でディスプレイ書体を選んだ場合は、その理由も1行で併記してください。デザインシステムを検証することは、ビジュアルの方向性へのその変更を検証することになります。パレットと文字サイズのスケールが、トランスクリプトに16進数コードやピクセル値で列挙されているだけでは、正確でもまったくレビューできません。MASTER.md のすべてのトークンがこれからあらゆる箇所に適用されるため、誤りを見つけるにはここが最も低コストのタイミングです。

ダイヤルも併せて提示します。search.py に渡した各値と、それが由来する方向性の節を示し、省いた各ダイヤルと、その理由も示してください。

Phase 4 - IMPLEMENT

技術スタックとインタラクションの方向性に基づいて、サブスキルを読み込みます。

必ず読み込む（上記で定義した load_skill <name> を使用します。不足しているモジュールは NOT LOADED と表示され、パイプラインは続行するため、最終レポートに記載する対象としてリストに残してください）：

load_skill motion-principles - 基盤

シェル呼び出し1回につき、モジュールは1つです。 約30,000文字を超えるシェル呼び出しの出力はインラインで届きません。2,000文字のプレビューとファイルパスが届きますが、読み取れなかったモジュールは読み込んでいないのと同じです。そのため、各読み込み呼び出しではスキルベースのブロックを再出力し、モジュールを1つ読み込みます。これにより、出力を25,000文字未満に保てます。モジュールのエントリーファイルはどれもこの上限を超えず、validate-skills.py によってその状態が維持されます。読み込み状況を記録してください。load_skill は不足しているモジュールに対して NOT LOADED と表示し、そのまま続行します。最終レポートには、読み込んだものと読み込めなかったものの両方を記載してください。各モジュールは全体を読み込みます。上記のバッチ処理ルールですでに各呼び出しが上限未満に保たれているため、load_skill または load_ref を head、tail、sed、grep にパイプしないでください。途中で切り詰められたモジュールは、読み込んでいないのと同じです。

コンテキストレイヤー（該当する場合に読み込みます）：

検出条件	読み込むもの
Web スタックで、スコープが中規模または全体	`load_skill tells`（専用の呼び出しで、以下の `references/web.md` と併せて読み込みます）
モバイルのコンテキスト（Web モバイル、またはネイティブ iOS／Android）	`load_skill mobile-principles`
デスクトップのコンテキスト（macOS、またはモバイルの指標がない Web デスクトップ）	`load_skill desktop-principles`
明示的に監査が依頼された場合、または scope=full	`load_skill design-audit`
高度な UI／UX に関する質問	`load_skill ui-ux-pro-max`

tells は単独のシェル呼び出しで読み込みます。 Web の参照ファイルと合わせると約20,000文字になり、他のモジュールと同じ呼び出しに含めた場合、シェル呼び出しの出力がインラインで届かなくなる境界に近すぎます。その呼び出しではスキルベースのブロックを再出力し、その後、次を実行します。

# (skill-base block re-emitted above this line)
load_skill tells
load_ref tells references/web.md

これは方向性の確認後、ビジュアルの選択を確定する前に読み込みます。検証済みの方向性によって、求められるパターンが定まり、tells によって誰も求めていない反射的な選択が明らかになります。Compose または SwiftUI のスタックでは決して読み込まず、スコープが軽量の場合も読み込みません。paint では、この行はすでに満たされています。Phase 3 でデザインシステムのクエリより前に tells を読み込みます。

スタック固有の項目（SCAN に基づいて読み込みます）：

検出されたスタック	読み込むサブスキル
gsap	`load_skill gsap`
`motion` または `framer-motion`（同じライブラリ、2つのパッケージ名）	`load_skill framer-motion`
Pure CSS / Tailwind / ライブラリなし	`load_skill css-native`
three / @react-three	`load_skill threejs-r3f`
Canvas / ジェネラティブ	`load_skill canvas-generative`
Android Compose	`load_skill compose-motion`（常に）+ `load_skill compose-graphics`（scope=full または thesis が advanced の場合 - 下記参照）
Compose Multiplatform	`load_skill compose-motion` + `load_skill compose-multiplatform`（常に）、iOS ターゲットが検出され SwiftUI 相互運用が要求される場合は `load_skill swiftui-motion`、advanced の場合は `load_skill compose-graphics`
SwiftUI iOS または macOS	`load_skill swiftui-motion`（常に）+ `load_skill swiftui-graphics`（scope=full または thesis が advanced の場合）

compose-graphics / swiftui-graphics の**「advanced thesis」トリガー**：

thesis が以下のいずれかの用語を含む場合、thesis は「advanced」であり（graphics サブスキルの読み込みをトリガーします）：

shader、Metal、AGSL、RuntimeShader、MSL
liquid-glass、glassEffect、morphing transition
M3 Expressive、MotionScheme、expressive motion
colorEffect、distortionEffect、layerEffect
Canvas（ジェネラティブ / パーティクル / フローフィールドの文脈を伴う場合）
holographic、CRT、displacement、ripple

それ以外の場合は、基本の motion サブスキルにとどめてください。

実装ルール：

ページ単位またはコンポーネント単位で作業してください - 一度にすべてをやろうとしないでください。
すべての色、フォント、スペーシング、シャドウ、角丸は MASTER.md のトークンから取得 MUST。マジックナンバーは禁止です。
すべてのアニメーションはインタラクション thesis（タイミング、イージング、禁止パターン）に従う MUST。
インタラクティブ要素には 5 状態ルールを適用してください：default、hover、focus、active、disabled。
次のページ/セクションに進む前に、主要な各ページ/セクションについてユーザーに検証を求めてください。

フェーズ 5 - AUDIT（決してスキップしない）

design-audit サブスキルを読み込んでください。フェーズ 4 はユーザーゲートで終了したため、$SKILL_BASE は再び失われています。 この同じ呼び出しで解決ブロックを再出力し、その後：

load_skill design-audit

検出されたスタックに一致する完全な監査チェックリストを実行してください。design-audit が grep を提供し、以下の分割がそれらから何を主張してよいかを決定します。

このパイプラインの締めくくりのステップは、以前は 25 個のチェックボックスでしたが、そのうちのいくつかはエージェントが実行できないツールを指定していました。Chrome を開かずに「Chrome DevTools で 60fps を検証済み」にチェックを入れると、「私は見ていない」が「私は見て、問題ない」に変わってしまい、何も言わないよりも悪くなります。

そこで、チェックは分割されます。最初のグループは、使用した証拠とともに報告してください。2 番目のグループには決してチェックを入れないでください - それは引き渡してください。

ここでチェックされ、証拠を伴うもの

各行は check - verdict - 証拠 として報告されます。証拠とは、実行した grep、計算した値、または読んだ file:line です。そばに証拠がない verdict は所見ではなく、チェックできなかった項目は合格ではなく未チェックとして報告されます。

ここに記載した項目は実行が必要です。ここでは検証していません

エージェントはプロファイラーを開いたり、デバイスに接続したり、ポインターを動かしたりできません。正確な実行方法を記した引き継ぎブロックとして報告し、未検証と明記します。チェックを付けたり、表現を和らげたり、ほかの項目に問題がなさそうだからといってこのセクションを省略したりしないでください。

対象	実行内容	合格条件
Web	Chrome DevTools > Performance で、インタラクション全体を記録する	16.7ms を超えるフレームがない
Web	375 / 768 / 1024 / 1440 でページを確認する	横スクロールがなく、コンテンツが切れていない
Web	OS の「視差効果を減らす」設定をオンにしてページを確認する	低下時の処理パスが実際に実行される
Web	このセッションで Web フォントが読み込まれなかった場合は、オンラインでページを確認する	フォールバックではなくフォントが読み込まれ、論旨が依拠する数値とウェイトが適用される
Compose	Layout Inspector > Component Tree > View Options > Show Recomposition Counts	スクロール中もカウントが安定している
Compose	ミドルレンジのデバイスで `androidx.benchmark.macro` Macrobenchmark を実行する	60fps ではフレーム時間が 16.67ms 未満、120fps では 8.33ms 未満
SwiftUI	Instruments > Animation Hitches	トランジション中にヒッチが発生しない
SwiftUI	「視差効果を減らす」をオンにし、Dynamic Type を 200% にする	何も切れず、動くだけの要素もない
macOS	すべてのインタラクティブ要素にポインターを合わせ、ビュー全体をキーボードで操作する	ホバー状態が反応し、フォーカスリングが表示され、ショートカットが割り当てられている

プレビューまたは開発サーバーがすでに起動しており、ユーザーが同意している場合は、ブラウザーを操作して Web の項目を確認するほうが、ユーザーに引き継ぐより望ましいです。監査のためだけに起動したり、そのために何かをインストールしたりしないでください。

2 つのグループは件数とともに分けて報告してください。「11 件を確認、2 件の問題を発見、8 件を引き継ぎ」は誠実な監査報告です。チェック項目を 1 つのリストにまとめるのは誠実ではありません。

レポートの最後には、必ず次の 2 行をそれぞれ単独の行として記載してください。

Modules loaded: motion-principles, framer-motion, design-audit
Modules not loaded: none

Modules not loaded には、load_skill の呼び出しで NOT LOADED と報告されたすべてのモジュールと、ロード表に記載されていたものの読み込みをリクエストされなかったすべてのモジュールを記載します。両方とも空の場合に限り、none と記載してください。呼び出し間でシェルの状態は保持されないため、このリストは最初の読み込みから最後の読み込みまで、自分で記録しておく必要があります。シェルには記憶されません。

確認済みグループでは、重要度の高い順に指摘事項を並べてください。重大 > 重要 > あれば望ましい。引き継ぎグループは並べ替えも絞り込みもせず、すべてそのまま記載してください。実行するのはユーザーだからです。

既存プロジェクトのプロトコル

すでにデザインやスタイルが設定されているプロジェクトで実行する場合：

引き続き、完全な BRAINSTORM（フェーズ 1）を実行します
フェーズ 1 でモードを確認します。ブランドを維持する、一部のみ変更する、または再デザインする、のいずれかです。モードによって、方針が置き換えてよい範囲が決まります。維持モードではすでに定義されたものは何も置き換えず、一部変更モードではユーザーが指定した領域のみ、再デザインモードではビジュアルレイヤー全体を置き換えます
フェーズ 4 では、既存のデザイントークンを置き換えるのは再デザインモードのみです。維持モードでは、MASTER.md は既存のトークンをそのまま採用し、新しいトークンを追加します。一部変更モードでは、既存のトークン名をすべて維持し、ユーザーが指定した領域のみ値を変更して、新しいトークンを追加します
機能とレイアウト構造は維持し、ビジュアルレイヤーのみを置き換えます

3 つのモードすべてにおいて、以下はユーザーの明示的な同意を得ずに変更してはいけません。同意は項目ごとに確認します。パブリックトークン名（このプロジェクト以外のコードからインポートされる可能性があります）、URL とルート、ナビゲーションラベル、フォームフィールド名、ロゴ、法的表記です。

トークンファイルを書き込む前に、既存のトークンと新しいトークンの差分（名前の変更、変更、追加、削除）を提示し、承認を待ちます。書き込み後、スタック固有のコマンドでビルドします。Web では tsc --noEmit またはプロジェクトのビルドスクリプト（npm run build または同等の pnpm / yarn コマンド）、Android では ./gradlew assembleDebug、Apple では xcodebuild -scheme <scheme> build を実行します。ここでビルドできない場合は、監査の引き継ぎ項目と同様に、正確なコマンドを添えて UNVERIFIED と明記して引き継ぎます。

モードは、デザイン作業における「作り直すか、強化するか？」への答えです。維持モードでは、ブランドを置き換えずに強化します。/genjutsu:cast は、1 つのエフェクトまたは 1 つのコンポーネントのエントリーポイントとして使い続けます。

注意信号 — このスキルに違反しそうなとき

考え	実際のところ
「ユーザーはすでに『ミニマルなダーク』と言っている。方針を立てるには十分だ」	2 つの単語では 5 つの領域を網羅できません。質問を続けましょう。
「ブレインストーミングの質問を 5 つまとめて尋ねよう」	1 つずつ尋ねます。「対象者」への回答によって、「雰囲気」の尋ね方が変わります。
「ユーザーが急いでいるようだし、コーディングに進もう」	プレッシャーへの対処プロトコルを使います。方針の誤りは数分ではなく、数日を無駄にします。
「しっくりくる色を選ぼう」	すべてのトークンは MASTER.md に基づきます。独断で決めてはいけません。
「サイト全体を一度に作ろう」	ページごとに進めます。検証もページごとに行います。
「方針ではバウンスなしとなっているけれど、このアニメーションはよさそうだ」	方針がルールです。変更するなら、まずユーザーと再検証します。
「ユーザーは満足しているようだし、監査は後回しにしよう」	監査は省略できません。フェーズ 5 は必ず実施します。軽い範囲なら短縮しますが、省略はしません。
「監査項目はすべて問題なさそうだから、チェックを付けよう」	チェックを付けるだけでは確認結果になりません。grep の結果、比率、ファイル名と行番号を報告するか、未確認と報告します。
「プロファイルできないから、その部分は省こう」	そうした場合は引き継ぎブロックが成果物です。省略すると合格したように受け取られます。
「『うん、そんな感じ』を承認と解釈しよう」	それは確認ではありません。どの部分がよいと思ったのか尋ねます。
「パレットを 16 進コードで列挙すれば、正確に伝わる」	正確でも、レビューできるとは限りません。セッションのプレビューモードで提示します。
「デザインシステムをどう見たいか、もう一度尋ねよう」	セッション中に尋ねるのは 1 回だけです。モードを伝えて進めます。
「プレビューページの見た目がよいから、そこからアプリを作ろう」	プレビューは使い捨てです。MASTER.md をもとに作成します。
「承認されたフォントをここではレンダリングできないから、システムフォントのほうが安全だ」	サンドボックスはサイトではありません。承認されたフォントを、近似したフォールバックの背後に読み込み、ここではレンダリングしていないことを伝えます。
「サイト全体の作業だから、bunshin に切り替えよう。明らかにこちらのほうがよい」	コストを添えて一度だけ提案し、承認された場合にのみ切り替えます。数百万トークンを消費します。

Markdown 対応

ログインしてコメント

基本情報

作者: athevon
リポジトリ: athevon/genjutsu
カテゴリ: デザイン・UI
インストール数: 1,354
GitHub スター: 698

問題を報告