scroll-craft について
scroll-craftは、スクロールを軸にしたマーケティングページの企画と制作を支援するスキルです。デザイナーや制作者向けに、ヒアリングとユーザージャーニーから構成、素材生成、HTML実装、スクリーンショットによる検証までを導き、各セクションの表現に変化をつけます。
主な機能
- 01ヒアリングに基づくクリエイティブブリーフ
- 02ユーザージャーニーと感情曲線の設計
- 03ページ文法とスクロール表現の選択
- 04素材生成とHTMLページの構築
- 05各スクロール位置をスクリーンショットで検証
活用シーン
- 01ブランドブリーフからスクロール型サイトを企画
- 02ページ各セクションに異なる動きを設計
- 03既存のブランド素材を使ったページ制作
- 04スクロール位置ごとの完成ページ確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ nateherkai/ scroll-craft --skill scroll-craftインストール後、Claude Code で/scroll-craftを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
CHANGELOG.mdengine/scrollcraft.cssscrollcraft.jsreferences/approved-collection.mdassets.mddevice-diag.htmldevices.mdfeel.mdhero-depth.mdtaste.mdtemplate.htmluniqueness.mdverify.mdworldflight.mdworlds.mdscripts/doctor.mjsencode.shkie.mjsserve.mjsshoot.mjsworkspace.mjsworldflight-assert.mjstemplates/FINGERPRINTS.md詳細
scroll-craft
スクロールは、訪問者全員がすでに使い方を知っている唯一の入力方法です。このスキルでは、スクロールをタイムラインとして扱います。ホイールはスクラバー、ページはその上に本物のテキストが重なるフィルムとなり、各セクションがそれぞれ異なる動きをすることで、訪問者は次に何が起きるのか確かめるために読み進めます。
制作するもの: インタビューブリーフ、ページ文法、カスタマージャーニーマップ、ピークをひとつ仕込んだ感情曲線、スクロールスコア、シグネチャームーブひとつ、生成アセット、トークン駆動のデザイン基盤に沿った実際の HTML ページひとつ、そしてあらゆるスクロール位置で破綻しないことを示すスクリーンショット一式です。
これは何ではないか
「フライスルーを生成して、テキストを載せる」ことではありません。この方法では、ページ全体にひとつの演出を適用することになり、その方法で作られたサイトはひと目で見分けがつきます。粘土細工のジオラマ、中央揃えのコピー、同じ 01 / 06 カウンター、同じ「スクロールして探索」メッセージ。まったく同じ動きをするセクションが五つあれば、それは同じセクションを五回見せているだけです。
ここから四つのルールが導かれます。このスキルの骨子となるルールです。
- 多様性こそが成果です。 ページでは少なくとも四種類の演出ファミリーを使い、同じ演出を連続して使ってはいけません。references/devices.md をお読みください。
- ブランドが本当にイラスト調でない限り、世界観は写真表現にします。 柔らかなマット仕上げのローポリ粘土ジオラマを、デフォルトとして使うことは禁止です。references/worlds.md をお読みください。
- 途切れのない連鎖は避けます。 ひと続きのカメラ移動は、構築コストが最も高く、最も壊れやすい手法であり、シーン間のカットを隠すことだけを目的としています。代わりに演出を変えれば、訪問者はひとつのフィルムを見ているわけではないので、カットは何もしなくても目立たなくなります。ブリーフが文字どおり「途切れのないひとつの旅」である場合に限り、連鎖させてください。
- 世界観が異なっても、ページが異なるとは限りません。 演出キットによって変わるのはページの見た目です。構造はそれとは別の軸であり、意識的に決めなければ、どの制作物も同じ骨組みを引き継いでしまいます。最初の四つの制作物は、まさにそうなっていました。references/uniqueness.md をお読みください。
基本となるヒーローの方針
プレミアムなマーケティング用ヒーローでは、立体的なレイヤー構成が基本要件です。 アセットを依頼する前に、背景、被写体、前景、空気感を表す各プレーンが独立して動くように計画してください。美しい背景ひとつにテキストのフェードを加えただけでは、この方針を満たしません。奥行きは、目に見える分離、オクルージョン、動きの制御された差によって生み出す必要があります。その間も見出しの読みやすさを保ち、シーン全体で明確なストーリーを伝えてください。
ヒーローを計画したり、そのアセットを生成したりする前に、references/hero-depth.md をお読みください。クリーンプレート、正しいアルファ付きの切り抜き、共通の接地アンカー、プレーン間のタイポグラフィ、控えめなスクロール演出、モバイル向けのアートディレクション、ビジュアルの合格基準に加え、承認済みの Sonder の例も説明しています。選んだ文法に合う構成を使い、Sonder のシーンを繰り返したり、固定表示を認めない文法に固定表示を強制したりしないでください。静的またはよりシンプルな方向性が明示されている場合は、それを尊重し、動きを減らす場合も静的な構成の中で奥行きを保ってください。
承認済みコレクションの基準
プレミアムなマーケティングサイトを計画する前に、references/approved-collection.md をお読みください。承認済みの10サイトの再構築から得られた要点をまとめています。実際のブランド調査、レイヤー間の仕様、意味のあるポインター/スクロールによる奥行き、適切な写真表現または3Dレンダリング、独自性のあるナビゲーションと締めくくり、有用なインタラクション、モバイル向けのアートディレクション、最終パッケージによる裏付けを扱っています。これらは実行原則と具体例であり、再利用できるページの骨組みではありません。
ステップ0:ブリーフとクリエイティブ上の決定権
何かを生成する前に、まずブリーフを固めてください。 すでに提供されている回答や素材を再利用してください。ユーザーがクリエイティブの方向性を明示的に委ねた場合(たとえば、「判断は任せます」や「口出ししないようにしたい」など)は、Self-authored under explicit creative delegation ブリーフを作成して、そのまま進めてください。以下の8つの項目を網羅し、根拠と仮定を区別してください。ユーザーの発言を捏造したり、追加のヒアリングや承認のチェックポイントを強要したりしないでください。
それ以外の場合は、まだ決まっていない項目についてヒアリングしてください。実際に質問し、回答を記録してください。名前だけからブランド全体を推測しないでください。
このスキルは幅広く対応できるものであり、決まったスタイルを押しつけるものではありません。人間が意図と、所有している素材を提供します。ヒアリングを通じて、それらを適切な種類のページへと落とし込みます。ひと続きの世界、独立したシーン、印刷物の章立て、ライブな画面など、どれも実現できます。どれにするかはヒアリングで決めます。
簡潔に進めてください。8つの質問を、一度にまとめて聞きます。
- 3〜5語で表す雰囲気と、媒体を問わず最大3つの参考例。映画、アルバムのジャケット、店、雑誌、ゲームなど。「好きなサイト」ではありません。サイトを挙げると、ページが既存サイトのような見た目になってしまうからです。
- スクロールの流れを、セクションごとに、ユーザー自身の言葉で聞きます。 訪問者に最初に見てほしいもの、次に来るもの、最後に見せたいものは何ですか。あなたが提示したメニューではなく、ユーザー自身の順序で聞いてください。
- エネルギーの曲線。 どこで落ち着いた雰囲気にし、どこで強い印象を与えるべきですか。最初から最後までずっと騒がしいページも、ずっと静かなページと同じように単調です。
- スクロール中、各段階でどんな気持ちになってほしいですか。また、覚えていてほしい瞬間はどれですか? エネルギーは音量のようなものです。これは感情であり、両者は一致するとは限りません。騒がしいページでは、静かな行為が最も強い印象になることもあります。段階ごとの回答は感情の曲線になり、覚えていてほしい瞬間はピークになります。どちらも BRIEF.md に必須です。references/feel.md を参照してください。
- これまで見たどのサイトにもない、このサイトならではのことを1つ。 これがシグネチャーとなる仕掛けの種です。具体的な回答を求めてください。「印象に残ること」は回答になりません。
- プレミアム・ミニマルから、どの程度離れたいか。 uniqueness.md §5 にある選択肢を提示してください。ブルータリスト、マキシマリスト、遊び心のあるスタイル、レトロ、情報量の多いスタイル、エディトリアル、プレミアム・ミニマルです。回答によって決まるのは美的な系統であり、あなたの好みではありません。
- ひと続きの世界、それとも独立したシーン? ページ全体を、スクロールしながら飛び進むひとつの連続した場所のように感じさせたいですか(ワールドフライト。references/worldflight.md を参照)、それとも別々のシーン、章、カットのように見せたいですか? これは構造を決める最大の分岐であり、後からあなたが決めることではなく、ユーザーが決めることです。両方を率直に提示してください。どちらも既定の選択肢ではありません。
- すでに持っている素材は何ですか? 映像、写真、商品写真、ブランドキット、自分自身が映っているクリップなど。実素材は世界観の土台となり、生成コストを抑えます。回答によって、どの素材をグレーディングしてエンコードし、どの素材を生成するかが決まります。「何もない」でも問題ありません。その場合は、世界全体を生成します。
アクトの計画に着手する前に、回答を <workspace>/builds/<name>/BRIEF.md に書き込んでください。回答はマーケティング向けの文章に言い換えず、ユーザー自身の言葉で記録します。以降のすべての工程はこのファイルを参照します。
BRIEF.md には、最低限、以下を含める必要があります。
- 8つの項目すべて。ユーザーから回答があればそのまま記載し、方向性を委ねられた項目には、作成者が決めた内容であることを明記します。
- 感情の曲線。 アクトごとに1行で、感情と、それを画面上で引き起こす要素を書きます。アクトができる前に記入し、スコアが埋まるのに合わせて追記します。
- ピーク。 訪問者が友人に話すような一文で、覚えていてほしい瞬間を書き、それがどのアクトにあるかを示します。
- 「これは、___のサイトです」という完成した一文。 仕掛けの名前ではなく、体験を記入します。
- 作成者が意図的に設けた無音の箇所。検証時に、無意味なスクロールと区別できるようにします。
references/feel.md は、この4項目すべての仕様です。
人間に本当に連絡がつかず、実行が完全自律型の場合は、BRIEF.md を自分で作成します。ブランドのトーンで8つの質問すべてに答え、ファイルの先頭に
Self-authored, not interviewed と記し、最終レポートでもその旨を伝えます。委任を受けずに作成するブリーフは、あくまで代替手段です。上記の明示的な委任は通常サポートされるワークフローであり、人間に連絡がつかないことを条件としません。
ブートストラップ
作業の段階ではなく、環境設定です。インタビューへの回答を受け取った後、ステップ1の前に一度だけ実行します。
手作業で確認するのではなく、事前チェックを実行してください。 後になって誤解を招くエラーとして表面化する失敗要因を把握しています。特に、必要なフィルターがないことをコマンドの構文エラーとして報告する、機能を削った ffmpeg が原因のエラーを検出できます。
node <skill>/scripts/doctor.mjs
node、完全な ffmpeg ビルド、playwright と Chrome、API キー、解決されたワークスペースを報告します。必須項目のチェックに失敗した場合は、ゼロ以外のステータスで終了します。不足している項目を明確に伝え、黙って回避策を講じないでください。
ワークスペース
ビルドとフィンガープリントレジストリは同じディレクトリに置きます。ここは解決されるものであり、決めつけてはいけません。
node <skill>/scripts/workspace.mjs --ensure # prints it, creates it, seeds the registry
解決順序は次のとおりで、最初に見つかったものが使われます。
SCROLLCRAFT_HOME- cwd から上の階層へたどって最初に見つかる
.scrollcraft.json({ "workspace": "..." }) .gitを含む最も近い祖先ディレクトリである<project root>の<project root>/scrollcraft
そのため、ビルドフォルダーは <workspace>/builds/<name>/、レジストリは <workspace>/FINGERPRINTS.md です。レジストリは空の状態から始まります。同じものを繰り返さないためのゲートなので、最初のビルドでクリアするものはありません。
すでに別の場所にビルドを保存している場合は、プロジェクトルートに .scrollcraft.json を置いて保存先を指定すれば、ほかは何も変わりません。
その他
- アセットを生成する場合に限り、
KIE_AI_API_KEYが必要です。ユーザー自身の写真や映像を使ったビルドにはキーも費用も必要ありません。これは第一級の選択肢であり、代替手段ではありません。node <skill>/scripts/kie.mjs probeで残高を確認してください。静止画は数セント、5秒のクリップはそれより高くなります。クリップを2つ使う6幕のページでも、少額の費用で済みます。 - ブランドキットがあれば、それを使います(カラー、ロゴ、書体、既存の商品写真など)。このリポジトリ内にブランドのフォルダーがある場合は、何かを生成する前に読み、厳格なルールに従ってください。数値を創作することを禁じるブランドであれば、見栄えがよくても統計カウンターは使いません。
engine/scrollcraft.js と engine/scrollcraft.css をビルドフォルダーにコピーします。エンジンをプロジェクトごとに編集してはいけません。エンジンは仕組みそのものです。トークンでテーマを設定し、マークアップは自分で作成してください。
ステップ1:ブリーフでは、まずユーザーの体験を設計する
テーマはユーザーに決めてもらいます。選択肢として業界の一覧を捏造せず、平易な文章で自由に答えられる形で尋ねてください。作り物のメニューは回答を偏らせ、ユーザーに代わってビジネスを決めているように受け取られます。
ステップ0ですでに雰囲気、順序、エネルギー、範囲を確認しています。これらを再度尋ねてはいけません。無理なく既定値を設定できないことだけを尋ねます。
- これは何で、誰のためのものですか? ユーザー自身の言葉で1、2文。
- 最後に、訪問者に何を信じてもらう必要がありますか? ページが伝えるべき、ただひとつのメッセージです。機能の一覧ではありません。3つ挙げられた場合は、ひとつに絞ってもらいます。
- 訪問者に次に何をしてもらいますか? 行動はひとつです。そのラベルをひとつ決め、ページ全体で統一して使います。
- すでに何をお持ちですか? ロゴ、カラーパレット、写真、商品写真、映像、ブランド資料など。実物のアセットは、常に生成したものより優先です。
- アートディレクション:references/worlds.md にある世界観を選択肢として提示し、独自の方向性を選んでもよいことも伝えます。
次に、何よりも先にユーザー体験の流れを作成します。それぞれの場面で、訪問者の知識や感情がどう変化するかを示す4〜7個の展開を並べます。
1 Recognition they see their own morning
2 Tension the cost of it, named plainly
3 Turn the thing that changes
4 Substance why it holds up
5 Range what they can choose
6 Commitment the one action
展開が背骨です。セクションは展開に沿って構成し、どの展開にも役立たないセクションは、映像がどれほどよくできていても削除します。アセットを生成する前に、ユーザー体験の流れを確定してください。ユーザーの判断が必要な場合は、流れを提示します。クリエイティブな判断を明示的に委任されている場合は、選んだ流れを記録し、許可された範囲内で進めてください。
ステップ 2:文法、ゲート、そしてスコア
この順で行うことは 3 つあり、最初の 2 つはアクトの計画より先に行います。詳しくはreferences/uniqueness.mdを参照してください。
文法を選ぶ。 まず、定義済みの 8 つの文法とその制約を確認します。ナビゲーション、展開、終わり方、明示的な禁止事項によって異なる構造を表現できるなら、新しい文法を追加しても構いません。新しいラベルを付けるだけでは評価されません。最初の 4 つのビルドでは、いずれも映像的なワンショットを採用していました。もう一度それを選ぶ場合は、インタビューに基づくレポートで、ほかの 7 つが合わなかった理由を説明してください。ナビゲーション、ヒーロー、締めくくりはすべて文法によって決まります。これらを個別に決めるのではありません。
シグネチャームーブを考案する。 このサイトだけに存在する、独自のインタラクションを 1 つ実装します。キットの仕掛けのパラメーター変更ではなく、ページ内にコードを書いて実現してください。インタビューの質問 5 がその種になります。エンジンには手を加えません。
フィンガープリントゲートを実行する。 <workspace>/FINGERPRINTS.md のレジストリを確認します(Bootstrap のワークスペースを参照してください。パスを表示するには node <skill>/scripts/workspace.mjs を実行します)。計画中のビルドは、既存の各行と 6 つの次元のうち少なくとも 4 つで異なっている必要があります。次元は、文法、ナビゲーションの扱い、ヒーローの仕掛け、アクトの順序構成、締めくくりのパターン、シグネチャームーブです。各行との比較で 4 つ以上異なる必要があります。条件を満たさない場合は、ログではなく計画を変更してください。
スコア表より先に感情の曲線を書く。 各アクトにつき 1 行で、感情とその原因を書きます。曲線を先に、アクトを後にします。感情を決める前に仕掛けを選ぶと、仕掛けが理由を探すことになるためです。隣り合う 2 つのアクトが同じ感情を持つなら、一方は埋め草です。素材ができてから削るより、ここで削るほうが低コストです。同じ段階でピークを名付け、ページ上で最大の長さを割り当ててください。詳しい方法はreferences/feel.mdを参照してください。
次に、それぞれのビートに仕掛けを割り当てます。慎重に選び、表に記録してください。
| ビート | 仕掛け | これを選ぶ理由 |
|---|---|---|
| 認識 | scrub | 読者自身の手でカメラを動かすことが、始まりとして考えられる最も力強い方法です |
| 緊張 | pin + キネティック | フレームが静止するなか、コピーが 1 行ずつ組み上がります |
| 転換 | reveal | ワイプは状態の変化であり、このビートが表すものも状態の変化です |
| 実質 | scrub(マクロ) | 肉眼では捉えられないスケールの質感です |
| 幅 | pan | 横方向の移動は「選択肢」、縦方向の移動は「主張」として伝わります |
| 決断 | pin + ポインター | ページは動きを止め、反応し始めます |
この表は映像的なスコアです。1 つの文法には適した形ですが、ほかの 7 つの文法には適していません。行を埋める前に、選んだ文法の「活用する要素」と「禁止事項」の一覧を確認してください。
ビルド前のチェック項目:
- 文法の禁止事項を守っていること。
pinを禁じている文法では、どれほど効果的に見えても、ここでも使用は禁止です。 - 異なる仕掛けの系統が 4 つ以上あること。それより少ないと、ページにアイデアが 1 つしかありません。
- 同じ仕掛けの系統を連続して使わないこと。
scrubのアクトは最大 2 つまで。動画はページ上で最も重い要素であり、3 つ目になると意外性が失われます。- 隣接するアクトが同じ感情を持たないこと。同じなら、一方は埋め草です。
- 1 つのアクトがピークであり、目に見えてわかるほど最大の長さを持つこと。その直前のアクトは、ピークより静かである必要があります。
- すべてのアクトが、それぞれのスクロール範囲に見合う価値を持つこと。8~14 ビューポート高は、長めの映像的なページをペース配分する際の目安であり、ノルマではありません。短めのエディトリアル、ギャラリー、作業面の文法では、体験が完結しているなら短いままにしてください。長さの目標を満たすために、埋め草や空のピン留めを追加してはいけません。
- アクト数と全体の長さが、これまでの 4 つのビルドすべてが該当した「6~7 アクト、各 13.6~13.8vh」の範囲に収まらないこと。この範囲は、今やフィンガープリントの次元の 1 つです。
ステップ 3:アセットを生成する
パイプライン全体、プロンプトのひな形、モデルに関するメモはこちら:references/assets.md。
簡易版:
node <skill>/scripts/kie.mjs still "<style preamble>\n\n<scene>" out/01-hero.png --ar 16:9 [--ref brand-can.png]
node <skill>/scripts/kie.mjs shot "<camera move>" out/01-hero.png out/01.mp4 --dur 5
bash <skill>/scripts/encode.sh out/01.mp4 assets/01.mp4
bash <skill>/scripts/encode.sh out/01.mp4 assets/01-m.mp4 mobile
仕上がりが高品質に見えるか、生成物らしく見えるかを左右するポイントは4つです。
- ひとつのスタイル用プレアンブルを、すべてのプロンプトで一字一句変えずに使い回します。 これによって、別々に生成した6枚の画像に一貫した撮影の雰囲気を持たせます。一度書いたら、言い換えないでください。
- 使う前に、すべてのアセットを確認します。 PNGを開いて確認してください。生成は安価で、質の悪いフレームをそのまま公開するより、再生成するほうが安く済みます。
- 再生ではなく、シークしやすいようにエンコードします。
encode.shは、シーク時にひとつ前のキーフレームから読み進めるため、GOPを密に設定しています。通常のウェブ向けエンコードでは再生は完璧でも、シークはひどくなります。 - ヒーローをレイヤーに分けます。 シーンを複数の平面に切り分け、それぞれをわずかに異なる速度でスクロールさせ、製品を中景と前景の平面の間に配置します。動きの差で生まれる奥行きは、ページを高品質に見せる最も手軽な方法です。手順と注意点は、references/devices.md の
parallaxに記載されています。
ステップ 4:ページを構築する
実際のHTMLを書きます。実際の <h1>、実際の <p>、実際のリンク、実際の読み上げ順序を用意してください。エンジンはマークアップから data-sc-* 属性を読み取って動作します。DOMを生成することはありません。設定オブジェクトからページを構築するランタイムを使うと、それを基盤にしたサイトがどれも同じ見た目になってしまいます。
references/template.html から始めてください。デバイスのパターンはreferences/devices.mdに、スペーシング、タイポグラフィ、奥行き、色のルールはreferences/taste.mdに記載されています。マークアップを書く前に taste.md を読み、チェックリストを読み上げずに構築してください。
トークンを6つの値と2つのフォントで上書きして、テーマを設定します。
:root {
--sc-canvas: #0A0806; --sc-surface: #16110E;
--sc-ink: #F5EBDD; --sc-ink-soft: #A2968A;
--sc-accent: #FF5A3D; --sc-accent-ink: #15110F;
--sc-font-display: "Archivo", system-ui, sans-serif;
--sc-font-text: "Geist", system-ui, sans-serif;
}
Step 5: スクロールして検証する
approved-collection.md §7の最終ソースとデプロイのチェックを適用してください。 すべてのコンテキストでネイティブのポインターロック/キャプチャを無効にし、安全なヘッドレス自動化を使用してください。実際のピクセル、スマートフォンでの構成、中間状態を確認し、最終パッケージで役立つコントロール、ダウンロード、フォームの結果をテストしてください。
これは任意ではなく、「動くはず」で済ませてはいけません。スクロールページに単一の状態はありません。位置ごとに異なるフレームがあり、見落とした2つの位置の間に不具合が潜んでいます。手順の全容はreferences/verify.mdを参照してください。
cd <build project> && npm i playwright-core # once
node <skill>/scripts/serve.mjs --root . --port 4500 &
node <skill>/scripts/shoot.mjs --url http://localhost:4500 --out lab/shots
node <skill>/scripts/shoot.mjs --url http://localhost:4500 --out lab/mobile --width 390 --height 844
node <skill>/scripts/shoot.mjs --url http://localhost:4500 --out lab/reduced --reduced-motion
ハーネスは各アクトを6つの位置で確認し、スクラブ動画が実際に静止するまで待機してから、スクロールしても変化しない箇所、不透明度が最大にならないキュー、各行の下で最も明るいフレームにおける、合成後のページ上で測定したコントラストを報告します。コンタクトシートも作成します。
その後、ハーネスにはできない作業を行ってください。**sheet.pngを読んでください。**これでクリップが進むことは確認できますが、構成が適切か、動きが滑らかか、ページに意味があるかまでは判断できません。また、フォーカス順を確認するためにTabキーで移動してください。
続いて、印象のチェックを行います(references/feel.md §6)。ページを何も先入観のない状態でスクロールし、各アクトで感じたことを1語ずつ書き留めてから、BRIEF.mdを開いて意図したカーブと照らし合わせてください。食い違いがある場合、間違っているのはページであり、ブリーフではありません。ピークが最も大きな視覚的変化であり、スクロールの余地を最も多く確保していること、最後の画面が何もない状態にフェードするのではなく、きちんと収束することをシートで確認してください。
**また、緑のチェック結果ではカバーできないこと、つまり実機のスマートフォンについて明記してください。**ヘッドレスChromeでは、iPhoneの動画デコーダー、自動再生ポリシー、低電力モード、タッチスクロールを再現できません。実際のデバイスではヒーロークリップが静止したままなのに、ビルドが4回連続で緑の結果を出していたこともあります。モバイルは最後に確認する項目ではなく、最初から主要な対象です。縦向きスマートフォン用のクリップ、タッチ操作に合わせて調整したlerp、大きめのタップ対象はすべて制作段階で用意されています(assets.mdとverify.mdを参照)。モバイルの不具合が報告された場合は、原因を再現できないマシン上で推測するのではなく、最初のラウンドでサイトの隣にreferences/device-diag.htmlをデプロイし、デバイスから答えを得てください。iOSのクリップのライフサイクルに関する詳細なメモは、verify.mdの「The phone is a different machine」にあります。Wi-Fi経由でスマートフォンからページを開くには、サーバーを--lan付きで起動してください(デフォルトではこのマシンだけにバインドされます)。作業が終わったらサーバーを停止してください。--lanを使うと、--root以下のすべてが同じネットワーク上の誰からでも読み取り可能になります。
見つかった問題を修正して、もう一度撮影してください。実際に検証したことと、検証していないことを報告してください。
厳守事項
好みではなく、リリースを阻む要因です。どれも、ページを機械で作ったように見せてしまいます。
| 禁止事項 | 代わりに |
|---|---|
| デフォルトの世界観としての粘土ジオラマ/ローポリ/クレイアニメ | 写真表現にします。worlds.md を参照してください |
| 「スクロール」を促す表示、矢印、アニメーションするマウスアイコン | 何も置きません。ユーザーはヒーローを見ているので、わかっています |
01 / 06 のセクションカウンター | 削除します。ここでは順序は情報になりません |
| すべてのセクション見出しの上に付けるアイブロウ | 3セクションにつき最大1つにします。見出しだけで伝わります |
| 画面に表示されるあらゆる場所でのダッシュ記号 | ピリオド、カンマ、コロン、または括弧を使います |
| すべての場面で中央揃えのコピー | 配置を変えます。左寄せ、右寄せ、中央揃え、分割配置を使い分けます |
| 同じ演出を2回連続で使うこと | ステップ2で、ジャーニーを適切に設計します |
| ブリーフとクリエイティブ面の決定権が明確になる前に生成すること | ステップ0を実行します。実際の回答、または明示的に委任されたクリエイティブ上の判断を BRIEF.md に記録します |
| 設計されたピークがないページ、またはピークが3つ競合するページ | ピークは1つにします。アセット予算を割り当て、その前に静寂を設け、最も長いスクロール領域を与えます。feel.md §2 を参照してください |
| 余韻を残したまま終わる、フェードアウトする、または単にフッターになる結末 | 結末で解決感を与え、その状態を保ちます。最後に残る感覚こそ、ユーザーが持ち帰るものです |
| 感情曲線を作る前に場面を計画すること | まず曲線、その次に演出です。feel.md §1 を参照してください |
| オリジナルのシグネチャー演出なしでリリースすること | 独自の演出を考案します。スポットライトの色を変えたり、傾きを調整したりするだけでは該当しません。uniqueness.md §3 を参照してください |
| 既存のどの行と比べても、フィンガープリントの6項目中4項目を満たさないビルド | FINGERPRINTS.md ではなく、計画を変更します |
| オリジナルの動きを実現するためにエンジンを編集すること | --sc-p と独自の data-sc-* を使い、ページ内に独自の JS を記述します |
| 前回のビルドで使ったという理由で、ワンショットの映画的演出を選ぶこと | 8種類すべての演出文法から選び、残り7種類を選ばなかった理由を説明します |
| コントラストを調整するために画面全体を覆う暗いオーバーレイ | テキストがある場所だけにスクリーンを置きます |
| 生成画像に文字を埋め込むこと | 必ず本物のマークアップを使います。文字を選択でき、翻訳可能で、くっきり表示できます |
| カウンターで架空の統計値を使うこと | 実際の数値だけを使います。数値がなければカウンターも使いません |
transition: all、または width/height/top/left のアニメーション | transform と opacity を使い、ワイプには clip-path を使います |
| グラデーションテキスト、ネオングロー、オフセットもぼかしもない色付きのハロー状シャドウ | 強調にはウェイトとサイズを使い、オフセットとぼかしのあるシャドウを使います |
| 自動再生する音声、またはスクラブ動画でのあらゆる音声 | 音声トラックを削除します。encode.sh がすでに削除しています |
| ステップ5を実行せずにリリースすること | ステップ5を実行します |
出力
BRIEF.md を含むビルドフォルダーに加えて、以下の短いレポートを作成します。演出文法と、残り7種類を選ばなかった理由、シグネチャー演出、既存の各行に対するフィンガープリントゲートの結果、ジャーニー、感情曲線とピーク、感触チェックの差分(意図した曲線と実際に感じられた曲線、および変更内容)、スコア表(ビートごとの演出)、生成したもの、スクリーンショットで検証したもの、検証できなかったものを記載します。ブリーフを自分で作成し、インタビューを行わなかった場合はその旨も記載します。ローカル URL を記載します。簡潔にしてください。納品物はページです。
続いて、ビルドの行を <workspace>/FINGERPRINTS.md に追加します。
スキル自体の変更と、その変更のきっかけとなったビルドでの発見は、CHANGELOG.md に記録します。