Auteur

映画のように演出された、賞レベルの Web ページを設計して作ります。

skill の情報

参考: SKILL.md 全文

Auteur Skill

> agiwhitelist/auteur（MIT）から移植したもので、スナップショットは > コミット 9bca227d です > （LICENSE を参照）。スクリプト・テンプレート・参考資料は上流のファイルそのまま（改行を CRLF→LF に変換）で、 > 手を加えたのは Hermes 向けの補足と references/ のパス修正だけです。

Auteur は、映画監督が映画を撮るのと同じ順番で Web 体験を設計して作ります。まず脚本、次に素材、それから撮影、最後に編集です。進め方は3つあります。build（よくできた一般的なサイト）、direct（スクロールで演出する映画のようなサイト）、system（複数の画面を持つプロダクトを1つのデザインシステムとしてまとめる）で、どれも同じ審美眼を土台にしています。ページが実行可能な「AI っぽさ（slop）」検査に通り、skill が自分の出力を実際に見て確かめるまでは、何も出荷しません。

こんなときに使います

• ランディングページ、マーケティングサイト、ヒーローセクション、ポートフォリオ、製品ページを作る、または作り直す必要があり、ありきたりな見た目では困るとき。
• 依頼にスクロールアニメーション、ストーリーテリング、映画のような感触のサイトが含まれているとき。
• プロダクトが複数の画面にまたがり、それらを1つのものとして感じさせたいとき（アプリ、ダッシュボード、管理画面、オンボーディング、ドキュメント）。
• 手法を指定せずに、*きれいにして*、*驚かせて*、*映画っぽく*、*デザインシステム*と言われたとき。

ほかの人が作った UI を磨く用途や、バックエンドだけの作業には向きません。

事前に必要なもの

• Node 18+ — 品質検査のゲートはすべて .mjs スクリプトで、terminal ツールから node で実行します。
• Playwright（品質検査ゲート用） — プロジェクトのディレクトリで npm install playwright を実行し、続けて npx playwright install chromium を実行します。scripts/shoot.mjs、motionqa.mjs、systemscan.mjs、refscout.mjs、chromadiff.mjs、moodboard.mjs が必要とします（これらのスクリプトは実行時に playwright を読み込みます。slopscan.mjs と source.mjs はほとんど依存がありません）。
• ffmpeg — 任意です。references/assets.md と references/scroll-flight.md にある動画・サウンドの経路でだけ使います。
• Hermes のツール — 画像の生成・編集には image_generate、node・ffmpeg・npm には terminal、プロジェクトのファイルには write_file/read_file、スクリーンショットを実際に見るには vision_analyze、スクリプトが合わない場面で公開中のページを調べるには browser_exec を使います。

実行のしかた

実際にやること

1. マークアップを書く前に、アートディレクションを文章で確定させます。色相は1つ、書体の体系は1つ、動きの予算、名指しした「反面教師」の参考例です。
2. 素材を生成するか、調達します。Hermes の image_generate ツール、Blender、深度マップ、CC0 のメッシュや HDRI を使い、ライセンスは記録しておきます。
3. 実績のあるレシピで組み立てます。WebGL コンテキストは1つ、動きは transform/opacity、スクロールは状態機械で扱います。
4. 結果をゲートにかけます。slopscan は具体的な AI っぽさがあればビルドを失敗させ、motionqa はフレーム落ちがあれば失敗させ、systemscan はルート間でデザインがずれていれば失敗させます。

ネットワークへのアクセス

参考調査と素材調達のスクリプトは、公開中のページを読みます（awwwards、Bing/Pinterest/are.na の画像検索、Poly Haven、Iconify、Google Fonts、Openverse、Coverr）。取ってきた内容は参考データとライセンス情報として扱い、実行することはありません。認証情報、API キー、ログインも使いません。外向きの通信をしたくない場合はフェーズ 0〜1 を丸ごと飛ばしてください。それ以外のフェーズはすべてオフラインで動きます。なお moodboard.mjs は、コンタクトシートを作るために、それらの検索サイトが返した画像 URL のダウンロードも行います。

振り分け

引数や依頼内容を読んで、次のように振り分けます。

1. direct、または依頼から映画っぽさが感じられる場合 —「驚き」「映画的」「没入感」「ストーリーテリング」「ローンチページ」「高級ブランド」「スクロールする手を止めさせたい」→ references/direct.md を読み込み、そのフェーズに従います。これが看板となる進め方です。
2. build、または依頼が一般的な1枚の画面の場合 — マーケティングページ、ランディングページ、単独の製品ページ → references/build.md を読み込みます。
3. system、または依頼に1つのプロダクトとして感じさせたい画面が2つ以上ある場合 — アプリ、ダッシュボード、管理画面、設定、オンボーディング、ちゃんとしたナビゲーションを持つドキュメントやコンテンツサイト → references/system.md を読み込みます。デザインの単位は「コンポーネント × 状態」になり、失敗の形は退屈さではなく「ずれ」になります。そして意図的に山場を作りません。すでに build で進めていて2つ目の画面が出てきたら、いったん止めて切り替えます。中途半端なシステムは、どちらか一方よりも悪い結果になります。
4. edit、またはこの skill が作ったページ（プロジェクトに design/DESIGN.md がある）を変更する依頼の場合 —「セクションを足して」「料金を変えて」「ヒーローの文言を差し替えて」→ まず design/DESIGN.md を読み、その編集手順に従います。トークン、セクションの始め方のパターン、動きの系統を使い回し、変更後は slopscan を実行して、影響を受けたビューポートを撮り直します。DESIGN.md を無視した編集は、それ単体でよく見えても後退です。
5. recon <brief>、または参考資料だけを求められている場合 —「参考を探して」「ムードボードを作って」「X のようなサイトの最先端は？」→ references/recon.md を読み込み、そのフェーズだけを実行します。公開中のサイトを調べ、ムードボードを作り、design/refs/REFERENCES.md（steal: の行を埋めたもの）と design/moodboard/contact-sheet.png（読み取りを書き込んだもの）を渡します。コミットシートは作らず、ビルドもしません。
6. audit <path-or-url> → references/verify.md を読み込み、auteur が作ったページに検証パイプラインを実行します。対象が auteur の作ったものではない既存の UI で、ユーザーが作り直しではなく*磨き上げ*を望んでいる場合は、専用の UI 磨き・講評の工程が適した道具であることを伝えます（上流では auteur を別の 'impeccable' という skill と組み合わせていましたが、ここには同梱していません）。そのうえで、作り直しを望む場合に限って続けると申し出ます。
7. どちらとも取れる場合（たとえば単に「ランディングページを作って」）→ 質問は1つだけにします。「よくできた一般的なランディングページにしますか、それともスクロールの演出と生成素材を使う映画モードにしますか？」（上流ではこうした依頼例をロシア語で書いていたため、ここでは訳してあります。）それから振り分けます。（複数画面の依頼はあいまいではありません。system です。）この時点ではほかに何も聞きません。聞き取りは、それぞれの進め方が自分で行います。

3つの進め方はどれもフェーズ 0 を共有していて、その中心はコミットシートです。順番は異なります。build は 参考調査 → コミットシート → モックアップ、direct は 参考調査 → 絵コンテ → コミットシート → モックアップの順です。direct では、6つの決定の*対象*が映画のシーンそのものだからです。system は 参考調査 → システムシート（ルートの地図 + コンポーネントの一覧）→ コミットシート → モックアップの順です。6つの決定の対象がページではなくプロダクトだからです。いずれにしても、シートが埋まるまではコードを書きません。

ほかの skill との関係

Auteur は*作る*もので、よそで作られた UI を磨き直すものではありません。ユーザーの手元に手直しが必要な既存のインターフェースがある場合は、別の UI 講評の工程を回してください（たとえばスクリーンショットに vision_analyze をかけ、兄弟にあたるデザイン系 skill と組み合わせます）。上流では auteur を 'impeccable' という講評 skill（ここには同梱していません）と組み合わせていました。auteur の検証ゲートと外部の講評は測っているものが違うので、問題なく両立します。

早見表

絶対に守ることと、フェーズの一覧です。参考資料をまだ1つも読み込んでいなくても、すべての進め方、すべてのフェーズで常に当てはまります。照合して拒否してください。これらのどれかを作りそうになったら、手を止めてその要素の構造から組み直します。

禁止事項（手直しではなく書き直す）

禁止を破ってよいのは、本当の理由を書いた auteur-allow（「確認」を参照）がある場合だけです。考え抜いて意図的に選んだものは個性ですが、既定のまま選んだものは slop です。

重要な数値（覚えておく。詳しい文脈は参考資料にあります）

• 本文のコントラストは 4.5:1 以上（大きな文字は 3:1 以上）。プレースホルダーも同様です。色味のある白の上にくすんだグレーの文字、というのが AI で最も多い読みにくさの失敗です。
• 本文の1行の長さは 65–75ch。ディスプレイ見出しの上限は clamp の最大値で 6rem 以下です（*本文の流れの中にある見出し*の場合）。ワードマークや、意図的に文字主体にしたヒーローは例外で、そのことをコミットシートに書く必要があります。ディスプレイの字間は −0.04em 以上にします。
• 所要時間: ボタン 100–160ms · ツールチップ 125–200ms · ドロップダウン 150–250ms · モーダル/ドロワー 200–500ms · 300ms を超える UI には文書化した理由が必要です。
• 登場・退場のイージングは ease-out。UI では ease-in は禁止です。
• アニメーションさせるのは transform と opacity だけ。時間差（stagger）は 30–80ms。
• 動きの予算: スクロールで発火するパターンの系統は1ページに3つまで。主要な山場は1つだけで、補助のシーンは強度を落とします。
• スクラブのなめらかさ 0.3–0.8。ヒーロー動画は 2MB 以下。LCP < 2.5s。CLS < 0.1。
• 全画面にかかる処理（ブルーム、グレイン、被写界深度、全フレームにかかるシェーダー）のコストはオブジェクト単位ではなくピクセル単位で決まります。フレームの予算を食いつぶすのはジオメトリではなくこれらです。性能の数値は、本番ビルドを DPR 2 で測ったときだけ有効です。DPR 1 だとこうした処理のコストはどれも4分の1になり、開発サーバーではフレームの時間がおおよそ2倍になります。
• prefers-reduced-motion は、後回しにするものではなく、別のアートディレクション（動きをゼロにするのではなく、穏やかにする）として扱います。
• JS を無効にしても内容が読めなければいけません。登場演出は、もともと見えている既定の状態を引き立てるもので、表示の条件にしてはいけません。

フェーズの一覧

ヒーローのモックアップのゲート（使い捨ての静的な画面を1枚作り、ほかを作る前にスクリーンショットを撮って承認を得る）は、アートディレクションを変えるのに最も安上がりな時点です。詳しくはそれぞれの進め方の参考資料にあります。design/DESIGN.md は、あとからの編集がすべてスタイルを保てるようにするためのスタイルの契約です（edit の経路はまずこれを読みます）。

途中の結果が「できあがったように見える」からといって、ゲートを飛ばしてはいけません。ゲートがあるのは、できあがったように見えるだけのページこそ、ほかのどの AI も出荷しているものだからです。

手順

コミットシート（コードを書く前に。どの進め方でも）

slop は、既定値が判断を下したときに生まれます。コミットシートは、最初の1行のコードを書く前に、7つの本当の決定を紙に書き出させます。templates/COMMIT-SHEET.md をプロジェクトにコピーし（たとえば design/COMMIT-SHEET.md）、7つの欄をすべて既定値ではない答えで埋めてください。

1. 山場 — 主要な驚きの瞬間を1つ（direct）、または看板となる要素を1つ（build）。1文で書きます。名前を挙げられないなら、まだ作る準備ができていません。
2. 色 — OKLCH で表したメインの色 + 使い込みの段階（控えめ / 腹を決める / フルパレット / 染め上げる）+ 1行の理由（*なぜラベンダーでもクリームでもなく、そのカテゴリの反射的な選択でもないのか*）+ 背景の明度を数値で（目標とする平均の L）。「暗いと高級に感じる」は、この skill が流されやすいところで、雰囲気はあとから確かめられませんが、数値なら確かめられるからです。
3. 書体 — コントラストの軸を持つディスプレイ用と本文用の組み合わせ（セリフ + サンセリフ、幾何学的 + 人文主義的、等幅 + セリフ…）+ 1行の理由（*なぜ Inter ではないのか*）。
4. グリッドを崩す点 — 左右対称のグリッドという既定を崩す、具体的なもの1つ。重なり、非対称の分割、斜めの流れ、全幅の割り込みなどです。具体的に名前を挙げます。
5. 動きの予算 — スクロールのパターン系統をいくつ使うか（3つ以下）と、それぞれ何か。
6. 反射の点検 — 書き出します。(a) ありきたりな AI がこのカテゴリでやること（一次の反射）、(b) (a) を避けようとするありきたりな AI がやること（二次の反射。たとえばフィンテック →「ターミナル風のダークモード」も、いまや*同じく*飽和しています）、(c) その両方からあなたが選んだ外し方。参考調査を実行していれば、(a) は推測ではありません。design/refs/REFERENCES.md に5回出てきたもの*こそ*が反射であり、日付と証拠が付いています。
7. 破る自分の癖 — taste.md §2.5 にある項目のうち、今回は意図的にやらないものを2つ（最低）挙げ、それぞれ何に置き換えるかを書きます。6a/6b の欄は*カテゴリ*の反射ですが、こちらは*この skill 自身*の反射です。無関係なプロジェクトでも繰り返し現れ、どれか1つのプロジェクトの内側からは見えません。黒に近い背景、等幅のサービスラベル、ロゴ/ステータス/アクションが並ぶヘッダー、スクロールを促すフッター、アンバーや蛍光色のアクセント、ワードマークをヒーローにすること、照明の代わりに発光を使うこと、などです。見本として作った9つのサイトを測ったところ、8つが暗い配色で、3つは明度の差が 0.002 以内に収まっていました。本当にここにふさわしい癖なら残してかまいません。auteur-allow と同じように、理由を書いてください。

ゲート: すべての欄が、具体的で既定値ではない答えで埋まっていること。空欄やありきたりな欄（「モダンでクリーンな見た目」）があれば、止まって決めてください。この成果物は検証のときにもう一度確認されます。

参考資料

• references/recon.md — フェーズ 0 の下調べです。実行できる工程が2つあります。scripts/refscout.mjs は賞レベルの公開サイトを分析し（実際の技術構成、固定されたシーン、スクロールの予算、書体、実際に描画された配色、スクリーンショット。見た目の皮ではなく仕組みを見ます）、scripts/moodboard.mjs は Bing / Pinterest / are.na から番号付きのコンタクトシートを作るので、アートディレクションを記憶ではなく実際の素材から決められます。ほかに、検索クエリの工夫、「盗み方」のルール、参考調査をコミットシートにつなげる方法、「参考画像は素材ではない」という線引きも載っています。フェーズ 0 の最初に読み込みます。
• references/taste.md — AI っぽさを避けるための仕組みの全体です。代わりの案付きの拡張禁止事項、カテゴリごとの二次の反射の表、色の戦略の段階、書体の組み合わせ、文面のルール。見た目に関する判断をするときに読み込みます。
• references/motion.md — 動きの流儀です。いつアニメーションさせるか、イージング・所要時間・スプリングの数値、性能のルール、動きの予算、音の方針。アニメーションを書く前に読み込みます。
• references/build.md — 標準の進め方の手順です。build に振り分けられたときに読み込みます。
• references/system.md — 複数画面の進め方です。ルートの地図、ゲートとしてのコンポーネントの一覧、状態の表（空・読み込み中・エラーは例外的なケースではありません）、密度のルール、山場を作らないルール、そして scripts/systemscan.mjs が載っています。systemscan はすべてのルートをたどり、ブラウザーが実際に描画したものを読み取り、コントロールの種類ごとに宣言したバリエーションの予算を超えていれば失敗させます。このとき*状態*（無効、現在地、data-state の行の中にあるもの）は別に数えるので、状態の表をきちんと実装してもずれとして読まれることはありません。さらに Tab キーを押して、フォーカス状態が見えないコントロールを見つけ、描画されたバリエーションごとにタイルを1枚ずつ描くので、ずれは数だけでなく目でも確認できます。system に振り分けられたときに読み込みます。
• references/direct.md — 映画的な進め方です。脚本の契約、シートの書き方、ドラマの構成、組み立ての順番。direct に振り分けられたときに読み込みます。
• references/assets.md — 素材を担当する面々と経路です（Hermes では、画像の生成と編集はすべて image_generate、ffmpeg や node は terminal、動画はユーザーの手元にある画像→動画のバックエンドを使います）。§0.5 調達か生成か（scripts/source.mjs: Poly Haven の CC0 glTF メッシュ、HDRI、PBR マテリアル、アイコン、書体、CC ライセンスの画像、ストック動画。ライセンスの台帳付きです。生成ではジオメトリや IBL は作れず、ストック動画を山場にしてはいけないためです）、一貫性を保つコツ（フレーム A を編集してフレーム B にする）、最初のフレーム→最後のフレームをつなぐローカルでの動画作り、生成した要素やモックアップ、環境音楽、品質を段階的に落とすはしご、素材のキャッシュが載っています。direct のフェーズ 1 で読み込みます。
• references/scroll-cinema.md — 実際に動くコードのレシピです。スクロールで再生位置を動かす動画、canvas の連番画像、GSAP+Lenis の土台、CSS のスクロール駆動アニメーション、文字の登場演出、2つのキーフレームを使う WebGL の変位トランジション、ビュー遷移、環境音、映画的なトランジションの一覧（ワイプ、カーテン、レターボックス、シャッター、奥行きのパララックス）。組み立てのときに読み込みます。
• references/scroll-flight.md — 動画スクラブの段階です。スクロールで操作する、実写のような「世界を飛び抜ける」ヒーローを、差し込むだけの templates/scroll-flight-engine.js で作ります。スクロールでスクラブする*動画*の定番レシピです（スクラブ向けのエンコード -g 8、エンコード済みフレームのポスター、SSIM による継ぎ目のゲート、チェーン構成 A/B、iOS やモバイルでのデコードの補強、クロスフェードかシームレスかの継ぎ目）。ヒーローをリアルタイム WebGL ではなく実写映像や AI 動画にしたいときに読み込みます。
• references/ambient-backgrounds.md — サブのセクションやシンプルなサイト向けの、控えめな質感です（ヒーロー向けではありません）。厳選した6つの編集物・アナログ風の効果（紙のざらつき、帳簿や設計図の罫線、等高線、インクの満ち引き、まばらな塵、陽炎のシェーダー1つ）と、動きのない静的なメッシュの既定値。基本のルール（いちばん控えめな前景の要素よりも弱くすること。背景効果は1ページに1つ）、CSS/SVG を優先する構成、feTurbulence は静的に使うという性能のルールが載っています。平坦にはしたくないが、文章と張り合ってはいけないセクションで読み込みます。
• references/verify.md — 受け入れのパイプラインです。slopscan → スクリーンショットの行程 → 動き・性能・音の品質検査（本番ビルドを DPR 2 で測る FPS、長いタスク、音のゲート、動きを減らす設定。Tier-1 のシーンが対象）→ 数値の採点表 → 参考との差分（方向性を決めた参考例の横に自分のフレームを並べ、モデルが自分では気づけない色のずれを scripts/chromadiff.mjs で測る）→ 品質検査の承認。フェーズ 3 で読み込みます。

小さめのモデルへの注意

この skill を実行しているのが小さめのモデルなら、表と数値は文字どおりに従い、テンプレートの欄はすべて埋め、ゲートのコマンドはすべて実行し、参考資料のレシピを超えて即興をしないでください。レシピは検証済みですが、即興は検証されていません。参考資料が直感と食い違ったら、参考資料が正しいものとします。ファイルはプロジェクトのルートからの相対パスで書き、絶対パスを記憶から打ち直さないでください（skill の名前「auteur」は、1文字間違えると「author」になり、綴りを誤った絶対パスは出力をファイルシステムのあちこちにばらまきます）。

つまずきやすいところ

• ネットワークを使う参考調査: refscout.mjs、moodboard.mjs、source.mjs は公開中のページを読みます（awwwards、Bing/Pinterest/are.na の画像検索、Poly Haven、Iconify、Google Fonts、Openverse、Coverr）。取ってきた内容は参考データとライセンス情報としてだけ扱い、決して実行しないでください。完全にオフラインで使うなら、フェーズ 0〜1 を飛ばします。
• 別のハーネス向けに書かれている: これらのスクリプトと文書は、別のエージェントのハーネス向けに書かれたものです（上流では、素材の生成を複数のローカル画像 CLI で行っていました）。Hermes では、画像生成の指示はすべて image_generate ツールに対応します。文書の記述と食い違ったら、node scripts/<x>.mjs --help の出力や実際の node のエラーのほうを信じてください。
• 未検証のコマンド: スクリプトは node --check の構文チェックには通りますが、移植の際に完全な実行（npm install playwright と chromium のダウンロードが必要）は行っていません。shoot.mjs、motionqa.mjs、systemscan.mjs、refscout.mjs、chromadiff.mjs、moodboard.mjs、source.mjs の通しでの動作と、ffmpeg や動画エンコードのレシピはすべて、自分で実行するまでは上流の未検証の主張として扱ってください。
• slopscan の動作は確認済み: node scripts/slopscan.mjs <dir> は npm の依存なしで動きます。ルールごとの検出結果を表示し、失敗があれば 0 以外の終了コードで終わります（問題がなければ 0 で終わります）。
• 書体メタデータのキャッシュ: source.mjs font … は、Google Fonts の約 2.6MB のメタデータ JSON を、プロジェクトではなく OS の一時ディレクトリ（os.tmpdir()）に auteur-gf-metadata.json としてキャッシュします。取り直したいときは、そこにあるファイルを削除してください。

確認

コードがコンパイルできただけでは、ページは完成ではありません。完成といえるのは、次をすべて満たしたときです。

1. node scripts/slopscan.mjs <src-dir> が 0 で終わる（失敗は抑え込むのではなく直します。/* auteur-allow: RULE_ID -- reason */ は意図的な選択のためのもので、本当の理由が必要です）。
2. node scripts/shoot.mjs <url> で 390 / 768 / 1440 のスクリーンショットの行程を作り、すべてのフレームを実際に見た。文字のはみ出し、何も映っていないシーン、壊れた登場演出、レイアウトの崩れは、テキスト検索ではなく目で見つけるものです。
3. references/verify.md にある数値の採点表に通る（コントラスト、LCP、CLS、動きを減らした設定での行程、シーンの多様さ）。
4. direct の進め方では、CINEMA-QA.md（テンプレートから作成）のすべての行が PASS で埋まっている。

どれかのゲートに落ちたら、直してもう一度実行してください。結果は正直に報告します。「見た目は最高です」よりも「slopscan は問題なし、スクリーンショット 21 枚を確認、LCP 1.9s」のほうが価値があります。