auteur について
Auteurは、一般的なページからシネマティックなスクロールサイト、複数画面の製品まで、Web体験の構築や再設計を支援するスキルです。コーディング前に方針を定め、視覚表現、モーション、画面間の一貫性を実行可能なチェックで検証します。
主な機能
- 01build・direct・systemの3モード
- 02マークアップ前のアートディレクション
- 03アセットの調達と生成のガイド
- 04視覚とモーションの実行可能な検査
- 05ルート間のデザイン一貫性検査
- 06一部フェーズのオフライン対応
活用シーン
- 01ランディングページや製品ページの構築
- 02シネマティックなスクロール体験の制作
- 03複数画面の製品デザインの統一
- 04Auteurで構築したページの監査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ agiwhitelist/ auteur --skill auteurインストール後、Claude Code で/auteurを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
.gitignoreLICENSEpackage-lock.jsonDESIGN.mdPRODUCT.mdpackage.jsonREADME.mdREADME.zh-CN.mdskills.sh.json.claude-plugin/marketplace.json.github/workflows/ci.ymlreference/build.mdambient-backgrounds.mddirect.mdrecon.mdmotion.mdassets.mdscroll-flight.mdsystem.mdtaste.mdverify.mdscroll-cinema.mdscripts/chromadiff.mjsmoodboard.mjsmotionqa.mjsshoot.mjsrefscout.mjssource.mjsslopscan.mjstemplates/CINEMA-QA.md詳細
Auteur は、映画監督が映画を作るようにウェブ体験を設計・構築します。まず脚本、次に素材、その後に撮影、最後に編集を行います。共通する美意識を土台に、3つのレジスターを備えています。build(優れた従来型のサイト)、direct(スクロール演出で展開する映画のようなサイト)、system(ひとつのデザインシステムとして構成された複数画面のプロダクト)です。実行可能なアンチスロップゲートをページが通過し、スキルが自身の出力を確認するまで、成果物は公開されません。
こんなときに使います
- ランディングページ、マーケティングサイト、ヒーローセクション、ポートフォリオ、プロダクトページを構築または再設計する必要があり、ありきたりな見た目が許されないとき。
- ブリーフで、スクロールアニメーション、ストーリーテリング、映画のように感じられるサイトが求められているとき。
- アプリ、ダッシュボード、管理画面、オンボーディング、ドキュメントなど、複数の画面にわたるプロダクトをひとつのものとして感じられるようにする必要があるとき。
- 具体的な手法を挙げずに、「美しくして」「驚きを与えて」「映画のように」「デザインシステム」と言われたとき。
他の人が構築した UI の仕上げや、バックエンドのみの作業には向きません。
実際に行うこと
- マークアップに着手する前に、アートディレクションを文章で確定します。ひとつの色相、ひとつのタイポグラフィシステム、モーション予算、明示したアンチリファレンスを決めます。
- 素材を生成または入手します。ローカルの画像・動画 CLI、Blender、深度マップ、CC0 のメッシュや HDRI を使い、ライセンスも記録します。
- 実証済みのレシピに基づいて構築します。WebGL コンテキストはひとつにし、トランスフォーム/不透明度のモーションとスクロール状態マシンを使います。
- 成果物をゲートで検査します。
slopscanは具体的なスロップがあればビルドを失敗させ、motionqaはフレーム落ちがあれば失敗させ、systemscanはルート間に差異があれば失敗させます。
ネットワークアクセス
調査・素材取得スクリプトは、公開中のページを読み込みます(awwwards、Bing/Pinterest/are.na の画像検索、Poly Haven、Iconify、Google Fonts、Openverse、Coverr)。取得したコンテンツは参照データおよびライセンス情報としてのみ扱い、実行することはありません。認証情報、API キー、ログイン情報も使用しません。外部へのリクエストを避けたい場合は、フェーズ 0〜1 をすべてスキップしてください。それ以外のすべてのフェーズはオフラインで動作します。
絶対に守ること
これらは、参照ファイルが読み込まれていない場合も含め、すべてのレジスター、すべてのフェーズで常に適用されます。「照合して拒否する」方針に従ってください。これらのいずれかを生成しようとしている場合は、そこで止めて要素を再構成します。
禁止事項(微調整ではなく書き換える)
| # | 禁止事項 | 代わりに |
|---|---|---|
| 1 | カード、コールアウト、アラートのアクセントとして色を付けた border-left/border-right を 1px より太くする | 全周の枠線、背景色の色味、先頭のアイコン、または何も使わない |
| 2 | グラデーション文字(background-clip: text + グラデーション) | 単色にする。強調にはウェイトまたはサイズを使う |
| 3 | デフォルトとしてのグラスモーフィズム(装飾目的の backdrop-filter カード) | まれに目的を持って使うか、単色のサーフェスにする |
| 4 | ヒーロー指標のテンプレート(大きな数字、小さなラベル、統計の行、グラデーションのアクセント) | 文章で根拠を示し、視覚的な表現は一つに絞る |
| 5 | 同一デザインのカードグリッド(同じサイズのアイコン+見出し+テキストを繰り返す) | サイズや構成に変化をつけるか、カード自体をなくす |
| 6 | すべてのセクションの上に置く小さな大文字のキッカーラベル | ブランドシステムとして意図的に使うキッカーは最大一つにし、セクションごとに導入の仕方を変える |
| 7 | 順序に意味がないのに、セクションを番号で構成する(01/02/03) | 実際の順序がある場合にのみ番号を使う |
| 8 | 最初に選ぶフォントとしての Inter または Space Grotesk | 対比軸の組み合わせから選ぶ(taste.md を参照)。この 2 つは 2024~2026 年の AI のデフォルトです |
| 9 | 紫から青へのグラデーション(両方の色相が 250~290) | ブランドカラーを明確に選ぶか、グラデーションを使わない |
| 10 | 「温かみ」を求めて本文の背景をクリーム色や暖色系ベージュにする(OKLCH L 0.84~0.97、C <0.06、色相 40~100) | 彩度のあるブランドカラーのサーフェス、彩度がほぼ 0 の真のオフホワイト、または暗めの色味を付けた中間色にする。温かみはアクセント、文字、画像で表現する |
| 11 | すべてのセクションに同じフェードイン/スライドアップの登場アニメーションを使う | 表示する内容に合った演出にし、イージング、距離、方向に変化をつける |
| 12 | transition: all | アニメーションさせるプロパティを列挙する |
| 13 | window.addEventListener('scroll', ...) | IntersectionObserver、GSAP ScrollTrigger、または CSS animation-timeline を使う |
| 14 | scale(0) から始まる登場アニメーション | scale(0.95) と不透明度から始める |
| 15 | 似通ったセルや空のセルで構成した Bento グリッド、白いカードを白い背景に並べた Bento グリッド | 各セルに実質的な視覚的変化がある場合に限り Bento を使い、そうでなければ別のレイアウトにする |
| 16 | コピーで使いがちな表現:「Revolutionize」「Seamless」「Effortless」「Unleash」「Elevate」、ダッシュを多用した文、また「BRAND. MOTION. SPATIAL.」のような装飾的な帯 | 平易な言葉で具体的に主張する |
| 17 | 1 ページに複数のマーキーを置く | 一つにするか、置かない |
| 18 | 「エレガントなセリフ体」として反射的に Instrument Serif/Playfair Display を選ぶ | AI の候補リストからではなく、ブランドに合ったセリフ体を選ぶ |
禁止事項を覆せるのは、明確な理由を添えた auteur-allow を書いた場合のみです(「検証」を参照)。意図を持って論拠のある選択をするのは表現ですが、デフォルトに従うのは粗雑な仕上がりです。
重要な数値(覚えておくこと。詳しい説明は参考ファイルを参照)
- 本文のコントラスト比は 4.5:1 以上(大きな文字は 3:1 以上)。プレースホルダーも対象です。色付きの白背景に薄いグレーの文字を置くのは、AI による可読性の問題で最もよくある失敗です。
- 本文の行の長さは 65~75ch。本文の流れに置くディスプレイ見出しの上限は clamp max ≤ 6rem です。ワードマークまたは文字を主役にした意図的なヒーローは例外とし、その旨をコミットシートに記載してください。ディスプレイ文字の letter-spacing は ≥ −0.04em にします。
- 表示時間:ボタン 100~160ms・ツールチップ 125~200ms・ドロップダウン 150~250ms・モーダル/ドロワー 200~500ms。300ms を超える UI には理由を記載する必要があります。
- 表示/終了のイージングには ease-out を使います。UI での
ease-inは禁止です。 - アニメーション対象は
transformとopacityのみです。スタッガーは 30~80ms にします。 - モーション予算:1 ページあたりスクロールトリガーのパターンは最大 3 ファミリーまで。主役となる圧倒的な見せ場は一つにし、補助的なシーンは強度を下げます。
- スクラブのスムージングは 0.3~0.8。ヒーロー動画は 2MB 以下。LCP < 2.5s。CLS < 0.1。
- フルスクリーンのパス(ブルーム、グレイン、被写界深度、フレーム全体のシェーダー)は、オブジェクト単位ではなくピクセル単位でコストがかかります。フレーム予算を圧迫するのはジオメトリではなく、これらの処理です。パフォーマンスの数値を根拠として示せるのは、本番ビルドを DPR 2 で測定した場合のみです。DPR 1 ではこうしたパスのコストは 4 分の 1 になり、開発サーバーではフレームの負荷がおよそ 2 倍になります。
prefers-reduced-motionは別のアートディレクション(動きをより穏やかにするもので、ゼロにはしません)とし、後付けにしないでください。- JavaScript を無効にしてもコンテンツを読めるようにしてください。表示演出はすでに見えているデフォルト状態を強化するものであり、表示を妨げてはなりません。
ルーティング
引数/概要を読み、振り分けます。
direct、または概要に映画的な雰囲気がある場合 — 「wow」、「cinematic」、「immersive」、「storytelling」、「launch page」、「premium brand」、「make people stop scrolling」 →reference/direct.mdを読み込み、そのフェーズに従います。これは最上位のレジスターです。build、または概要が従来型の単一の画面を対象としている場合 — マーケティングページ、ランディングページ、単一の製品ページ →reference/build.mdを読み込みます。system、または概要がひとつの製品として一貫して感じられる必要がある複数の画面を含む場合 — アプリ、ダッシュボード、管理画面、設定、オンボーディング、実際のナビゲーションを備えたドキュメントサイトやコンテンツサイト →reference/system.mdを読み込みます。デザインの単位はコンポーネント×状態になり、失敗の形は退屈さではなく一貫性の崩れになります。また、意図的にピークを設けません。すでにbuildで進めていて2つ目の画面が登場した場合は、停止して切り替えます。中途半端なシステムは、どちらよりも悪い結果になります。edit、またはこのスキルで作成したページの変更依頼(プロジェクトにdesign/DESIGN.mdが含まれる場合) — 「セクションを追加」「価格を変更」「ヒーローの文言を差し替え」 → まずdesign/DESIGN.mdを読み、編集プロトコルに従います。トークン、セクションの開始パターン、モーションファミリーを再利用し、変更後に slopscan を実行して影響を受けるビューポートを再撮影します。単独では見栄えが良くても、DESIGN.md を無視した編集は後退です。recon <brief>、または依頼が参考資料のみの場合 — 「найди референсы」、「собери мудборд」、「X のサイトの最新動向は?」 →reference/recon.mdを読み込み、そのフェーズだけを実行します。公開中のサイトを調査し、ムードボードを作成して、design/refs/REFERENCES.md(steal:の行を埋めたもの)とdesign/moodboard/contact-sheet.png(読み取り結果を埋めたもの)を提出します。コミットシートもビルドも不要です。audit <path-or-url>→reference/verify.mdを読み込み、アートディレクターが作成したページに検証パイプラインを実行します。対象がアートディレクターの作成ではない既存の UI で、ユーザーの希望が作り直しではなく磨き上げの場合は、/impeccableが適切なツールであることを伝え、作り直しを希望する場合にのみ続行を提案します。- 曖昧な場合(例:「сделай лендинг」だけの依頼)→ 質問は正確に1つだけします:「普通に優れたランディングページにしますか。それとも、スクロール演出とアセット生成を使う映画モードにしますか?」その後、振り分けます。(複数画面の概要は曖昧ではなく、
systemです。)この時点ではほかに質問しません。各レジスターで個別に要件を確認します。
3つのレジスターはすべてフェーズゼロを共有し、その中心となるのがコミットシートです。順序は異なります。build は recon → commit-sheet → mockup、direct は recon → storyboard → commit-sheet → mockup です。映画のシーンをもとに6つの決定を行うためです。system は recon → system-sheet(ルートマップ+コンポーネント一覧)→ commit-sheet → mockup です。6つの決定の対象はページではなく製品だからです。いずれの場合も、シートが完成するまでは何もコーディングしません。
コミットシート(コードを書く前に、どのレジスターでも作成)
スロップは、デフォルトに判断を委ねたときに生まれます。コミットシートは、最初の1行目を書く前に、7つの実質的な判断を紙に書き出すよう促します。templates/COMMIT-SHEET.md をプロジェクトにコピーし(例:design/COMMIT-SHEET.md)、7つすべての項目をデフォルト以外の内容で埋めてください。
- ピーク — 主要な「驚き」の瞬間(direct)、またはシグネチャー要素(build)を1つ。1文で書いてください。名前を挙げられないなら、まだ作り始める準備ができていません。
- カラー — OKLCH でのプライマリーカラー+コミットメントの段階(控えめ/しっかり/フルパレット/全面展開)+次の1行:「なぜラベンダーでも、クリームでも、カテゴリ特有の反射的な選択でもないのか」+背景の明度を数値で(平均Lの目標値)。「ダークは高級感がある」という考えがこのスキルの方向性を狂わせるためです。雰囲気はあとから確認できませんが、数値なら確認できます。
- 書体 — コントラストの軸に沿ったディスプレイ書体+本文書体の組み合わせ(セリフ+サンセリフ、幾何学的+ヒューマニスト、等幅+セリフなど)+次の1行:「なぜ Inter ではないのか」。
- グリッドの崩し方 — 対称グリッドのデフォルトを崩す、具体的な要素を1つ。重なり、非対称な分割、斜めの流れ、全面に広がる中断など、具体的に挙げてください。
- モーションの予算 — スクロールパターンの系統がいくつあるか(3以下)、およびその内容。
- 反射チェック — 次の内容を書き出してください:(a)このカテゴリで一般的な AI が行うこと(1次反射)、(b)(a)を避けようとする一般的な AI が行うこと(2次反射。例:フィンテック →「ターミナル風ダークモード」も、今ではありふれています)、(c)その両方からどう逸脱するか。recon を実行した場合、(a)は推測ではありません。
design/refs/REFERENCES.mdに5回登場したものが反射的な選択肢です。日付と根拠を添えてください。 - このスキル特有の癖を崩す — あえて採用しない
taste.md§2.5 の項目を最低2つ挙げ、それぞれ何に置き換えるかを書いてください。項目6a/6bはカテゴリ特有の反射です。こちらは、このスキルが持つ反射的な癖で、無関係なプロジェクト間でも繰り返され、個々のプロジェクトの中からは見えません。黒に近い背景、等幅のサービスラベル、ロゴ/ステータス/アクションのヘッダー、スクロール指示のフッター、アンバーまたは蛍光色のアクセント、ヒーローとしてのワードマーク、照明の代わりにグローを使うことなどです。9つのショーケース制作物を計測したところ、8つがダークで、3つは明度がほぼ同じ(差は0.002以内)でした。本当にこの場にふさわしい癖なら、残してもかまいません。その理由を書いてください。auteur-allowのように。
ゲート:すべての項目を、具体的でデフォルトではない回答で埋めてください。空欄、または「モダンで、すっきりした見た目」のようなありきたりな回答があれば、いったん止まって判断してください。この成果物は検証時にも再確認します。
各フェーズの概要
| フェーズ | build レジスター | direct レジスター | system レジスター | 読み込むリファレンス |
|---|---|---|---|---|
| 0 | recon → コミットシート → ヒーローモックアップのゲート | recon → 脚本(STORYBOARD.md)→ コミットシート → ヒーローモックアップのゲート | recon → SYSTEM-SHEET.md(ルート+コンポーネント一覧+状態)→ コミットシート → モックアップのゲート | recon.md、次に build.md / direct.md / system.md |
| 1 | — | アセット制作(生成 → 編集 → 最適化) | —(アイコン/フォントのソースは source.mjs を使用) | assets.md |
| 2 | ページを構築 | 映像を組み立てる(まずスムーズスクロール、次にヒーロー、上から順にシーンを作成) | トークン → シェル → トラフィック順に画面を作成 → すべての状態 | build.md / scroll-cinema.md / system.md + taste.md + motion.md |
| 3 | 検証 | 検証 + CINEMA-QA.md | 検証 + すべてのルートに対する systemscan | verify.md |
| 4 | スタイルを確定:design/DESIGN.md を記入 | 同じ | 同じ。ただし DESIGN.md はコンポーネントの契約書 | templates/DESIGN.md |
ヒーローモックアップのゲート(ほかのものを作る前に、使い捨ての静的画面を1つ作り、スクリーンショットを撮って承認する)は、アートディレクションを変更する最も低コストなタイミングです。詳細は各レジスターのリファレンスを参照してください。design/DESIGN.md は、以降の編集でもスタイルを一貫させるためのスタイル契約です(edit ルートでは、最初にこれを読み込みます)。
中間成果物が「完成したように見える」からといって、ゲートを省略してはいけません。ゲートが必要なのは、ただ完成したように見えるページこそ、ほかのあらゆる AI が納品するものだからです。
リファレンスファイル
reference/recon.md— フェーズ0の偵察、実行可能な2つの柱:scripts/refscout.mjsは受賞レベルのライブサイトをプロファイリングし(実際のスタック、固定されたシーン、スクロール予算、フォント、描画されたパレット、スクリーンショット — 表面ではなく仕組み)、scripts/moodboard.mjsは Bing / Pinterest / are.na から番号付きのコンタクトシートを構築します。これにより、アートディレクションは記憶ではなくライブの素材から決定されます。さらに: クエリの作り方、盗用ルール、偵察がコミットシートにどう反映されるか、そして「参照画像はアセットではない」という線引き。フェーズ0の冒頭で読み込みます。reference/taste.md— 完全なアンチスロップシステム: 置換案を伴う拡張禁止リスト、二次的なカテゴリ反射の表、カラー戦略の階層、タイポグラフィのペアリング、コピーのルール。あらゆる視覚的な意思決定のために読み込みます。reference/motion.md— モーションの流派: いつアニメーションさせるか、イージング/デュレーション/スプリングの数値、パフォーマンスのルール、モーション予算、サウンドの方針。アニメーションを書く前に読み込みます。reference/build.md— 標準的なレジスタのプロセス。build にルーティングされたときに読み込みます。reference/system.md— マルチスクリーンのレジスタ: ルートマップ、ゲートとしてのコンポーネント目録、状態マトリクス(empty/loading/error はエッジケースではありません)、密度のルール、ノーピークのルール、そしてscripts/systemscan.mjs— これはすべてのルートをクロールし、ブラウザが実際に描画したものを読み取り、宣言されたバリアント予算を超えたコントロール種別を失敗とし、状態(disabled、current、data-state行の内側)を別々に数えることで、状態マトリクスの実装がドリフトとして読まれることが決してないようにし、Tab キーを押して可視のフォーカス状態を持たないコントロールを検出し、レンダリングされたバリアントごとに1つのタイルを描画することで、ドリフトが数えられるだけでなく目に見えるようにします。system にルーティングされたときに読み込みます。reference/direct.md— 映画的なレジスタ: 脚本の契約、シーンシート、ドラマツルギー、アセンブリの順序。direct にルーティングされたときに読み込みます。reference/assets.md— メディアクルーとルーティング(画像には agy / codex / grok-4.5、動画には grok、スコアには MiniMax、ffmpeg)、§0.5 source-vs-generate(scripts/source.mjs: Poly Haven の CC0 glTF メッシュ、HDRI、PBR マテリアル、アイコン、フォント、CC 画像、ストック動画 — ライセンス台帳付き。なぜなら生成ではジオメトリや IBL を作れず、ストック動画がピークになってはならないからです)、一貫性のトリック(フレーム A をフレーム B に編集する)、最初→最後のフレームチェーンによるローカル動画、生成された要素/モックアップ、アンビエントスコア、デグラデーションのはしご、アセットのキャッシュ。direct フェーズ1の間に読み込みます。reference/scroll-cinema.md— 実用的なコードレシピ: スクロールでスクラブされる動画、キャンバスシーケンス、GSAP+Lenis の基盤、CSS スクロール駆動アニメーション、テキストの表示、2キーフレームの WebGL ディスプレイスメントトランジション、ビュートランジション、アンビエントオーディオ、そして映画的なトランジションライブラリ(ワイプ、カーテン、レターボックス、シャッター、深度パララックス)。アセンブリの間に読み込みます。reference/scroll-flight.md— 動画スクラブのティア: ドロップインのtemplates/scroll-flight-engine.jsを使い、スクロールで駆動されるフォトリアルな「世界を飛び抜ける」ヒーロー。スクロールでスクラブされる動画の正規のレシピ(スクラブ用エンコード-g 8、エンコード済みフレームのポスター、SSIM シームゲート、チェーンアーキテクチャ A/B、iOS/モバイルのデコード強化、クロスフェード対シームレスな継ぎ目)。ヒーローがリアルタイム WebGL ではなくフォトリアルなフッテージ/AI 動画であるべきときに読み込みます。reference/ambient-backgrounds.md— セカンダリセクションやよりシンプルなビルド向けの静かなテクスチャ(ヒーローではありません): 厳選された6つのエディトリアル/アナログエフェクト(紙の粒子、帳簿/設計図の罫線、地形の等高線、インクの潮、まばらな塵、1つのヒートヘイズシェーダー)+ モーションゼロの静的メッシュのデフォルト。統括ルール(最も静かな前景要素よりも弱く、1ページにつき1つのアンビエント)、CSS/SVG ファーストのスタック、そしてfeTurbulence静的のパフォーマンスルール。セクションが平坦であってはならないけれどもコピーと競合してはならないときに読み込みます。reference/verify.md— 受け入れパイプライン: slopscan → スクリーンショットのジャーニー → モーション/パフォーマンス/オーディオの QA(Tier-1 シーンでは、プロダクションビルドでの DPR 2 の FPS、ロングタスク、オーディオゲート、reduced-motion)→ 数値ルーブリック → 参照差分(方向性を定めた参照の隣に自分のフレームを並べ、scripts/chromadiff.mjsでモデルが自分自身では決して見ることのない色のドリフトを測定)→ QA のサインオフ。フェーズ3で読み込みます。
検証はビルドの一部です
コードがコンパイルできただけでは、ページは完成ではありません。次の条件を満たして初めて完成です。
node scripts/slopscan.mjs <src-dir>が終了コード 0 で終了していること(エラーは抑制せず修正してください。意図的な選択には/* auteur-allow: RULE_ID -- reason */を使用できますが、正当な理由が必要です)。node scripts/shoot.mjs <url>により、390/768/1440 の各幅でスクリーンショットの画面遷移を生成し、すべてのフレームを確認していること。テキストのはみ出し、空白の画面、表示の不具合、レイアウトの崩れは、grep ではなく目視で見つけてください。- 数値で評価する
reference/verify.mdの基準(コントラスト、LCP、CLS、モーション低減時の画面遷移、シーンの多様性)に合格していること。 - 直接登録の場合、(テンプレートから作成した)
CINEMA-QA.mdのすべての項目に PASS を記入していること。
いずれかのゲートに失敗した場合は、修正して再実行してください。結果は正直に報告してください。「slopscan は問題なし、21 枚のスクリーンショットを確認、LCP は 1.9 秒」のほうが、「見栄えがいいです」より適切です。
他のスキルとの連携
Auteur は構築を担当し、他の UI の磨き直しは行いません。ユーザーの既存インターフェースを改良する必要がある場合は、/impeccable を勧めてください。Auteur が作成したページを外部の視点で批評するには、構築したページに対して /impeccable critique を実行できます。Auteur の検証ゲートと Impeccable の批評は異なる点を評価するため、問題なく併用できます。
小型モデル向けの注意
このスキルを実行する小型モデルの場合は、表や数値に文字どおり従い、すべてのテンプレート項目に記入し、すべてのゲートコマンドを実行し、参照レシピの範囲を超えて独自の判断を加えないでください。レシピは検証済みですが、独自の判断は検証されていません。参照ファイルの内容が自分の直感と食い違う場合は、参照ファイルを優先してください。ファイルはプロジェクトルートからの相対パスで作成し、記憶を頼りに絶対パスを入力しないでください(スキル名の「auteur」は「author」と一文字違いであり、絶対パスの入力ミスはファイルをファイルシステムのあちこちに散らばらせてしまいます)。