Communitygithub.com

dennisyjlee/prototype-reel

実際の製品のように動作するコードベースのプロトタイプを作成し、フィードバックを得て共有し、ケーススタディ、デッキ、サイト用の洗練されたウォークスルービデオに変換します。フローのプロトタイプ作成、クリッカブルデモの作成、デザインからのプロダクトウォークスルーやリールの作成を求められたときに使用します。

prototype-reel とは?

このスキルは、静的なモックアップでは捉えきれない製品の実際の動作——タイミング、読み込み、トランジション、ジェスチャー、エッジケース、マルチステップフロー——を再現するコードベースのプロトタイプを作成します。まず実際のデザインとフローを読み込み、全画面・状態・遷移をリスト化した後、生のHTMLとDOMでプロトタイプを構築します。これは画像にホットスポットを張っただけのものではなく、実際のタップターゲットを持つ本物のUIです。プロトタイプが完成したら、フィードバック用に公開リンクを共有し、その後同じプロトタイプをフレーム単位でドライブしてウォークスルービデオをレンダリングします。デザインが変わっても再撮影ではなく再レンダリングで済むため、効率的な反復が可能です。スキルはClaude Code、Cursor、CodexなどのAIエージェントと連携し、提供される各種リファレンス(動作、忠実度、共有、ペーシング、モーショントークン、QA)に従って動作します。非交渉事項として、画像ではなくライブDOMを使用すること、UIの動きを上書きしないフィルム文法、すべてのデリバリ前にQAパスを実施することなどが定められています。レビュワーからの指摘は即座にルール化して記録することで、同じ指摘が繰り返されることを防ぎます。

対応~Claude Code~Codex CLI✓Cursor
npx skills add https://github.com/dennisyjlee/skills/tree/HEAD/skills/prototype-reel

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

プロトタイプリール

本物のようにプロトタイプを作り、それを動画でストーリーとして伝える。

静的なモックは画面の見た目を示します。しかし製品の感触——何が最初に読み込まれるか、親指がどこに着地するか、失敗したときに何が起こるか——は伝えられません。このスキルは、実際に構築しているもののように動作するプロトタイプを作成し、それを人々の前に出してフィードバックを得て、そして同じプロトタイプをフレーム単位でドライブしてウォークスルービデオをレンダリングします。スクリーンレコーディングではないので、デザインの変更は再撮影ではなく再レンダリングで対応します。

ここに書かれたルールは実際のレビューラウンドから生まれました。それぞれはレビュワーからの指摘として始まり、その指摘を二度と与えなくて済むようにデフォルトのルールになりました。

いつ使うか(そして使わないほうがいいか)

  • プロトタイプを作るのは、アイデアが動作に依存する場合:タイミング、読み込み、トランジション、ジェスチャー、エッジケース、またはマルチステップフロー。また、レビュワーが体験ではなく画像に反応し続ける場合にも使います。
  • 動画を作るのは、視聴者がクリックできない場合:ループするスライド、サイトのタイル、非同期のアップデート、ケーススタディ。動画はプロトタイプをスケールして共有する方法です。
  • スキップするのは、静的なフレームで答えが出るレイアウトやビジュアルの質問、およびワイヤーフレームの方が安価な非常に初期のアイデアの場合。方向性が決まったらプロトタイプを作りましょう。

ワークフロー

以下の順序で行ってください。レンダリングに飛びつかないこと。

  1. コンテキストを読み込む。 実際のデザイン(デザインファイル、スクリーンショット、デザイントークン)、フロー、およびゴールを入手します。視聴者が見たりクリックした後に何を理解すべきかを尋ねます。references/fidelity.mdを読んでください。
  2. 最初に状態と動作をリスト化する。 コードの前に、すべての画面、状態、および遷移を書き出します:ローディング、空、エラー、成功、戻る、トースト、エッジケース。それぞれ一行。相手にリストを確認してもらいます。
  3. ライブHTMLを構築する。 kit/shell.htmlから始めます。画面を、ホットスポット付きのスクリーンショットではなく、実際のタップターゲットを持つ実際のDOMとして再構築します。references/behavior.mdを読んでください。
  4. 自分でクリックスルーする。 デスクトップとモバイルの両方で、ヘッドレスブラウザを使ってすべてのパスを実行します。各状態をスクリーンショットします。コンソールエラーはゼロ。共有する前に修正します。
  5. フィードバックのために共有する。 キャプションとタップヒントをオンにしたリンクを公開します(references/sharing.md)。すべての指摘をreferences/feedback-log.mdの形式で記録します:指摘、それが生み出すルール。
  6. ショットリストを書く。 ビートごとに一行:時間 | 画面表示 | アクション | ショット | ストーリーポイント。各ビートにショット名を付けます(establishing、insert、cut on action、match cut、payoff;references/pacing.md、フィルム文法を参照)。ビートごとに一つのアイデア。ビデオ作成前に承認を得ます。
  7. プレビューしてからレンダリングする。 一時停止したクロックでプロトタイプをドライブし、フレームをキャプチャします。最初に低解像度のプレビュー(15fps、半分のサイズ)を送ります。タイミングが承認された後にのみフル品質でレンダリングします。references/pacing.mdおよびreferences/motion-tokens.mdを読んでください。
  8. QAしてから納品する。 references/qa.mdのすべてのチェックを実行し、納品メッセージで何をチェックしたかを伝えます。修正は指摘された項目のみに影響します。

非交渉事項

  • 画像にホットスポットを付けたものではなく、ライブDOMを使用すること。画像は写真、ロゴ、メディアのみに使用。
  • テキストはデザインのトークン(ファミリー、サイズ、行高、トラッキング)を使用し、手動で値を設定しないこと。レンダリングする環境にフォントがインストールされていることを確認する。
  • トーストとオーバーレイはコンテンツの上に配置すること。ページを押し下げてはいけない。
  • 作品ごとに一つのイージングファミリー。エントランスにはイーズアウト、UIにイーズインは使わない、0からのスケールはしない。UIにバウンスは使わない、ただしペイオフの瞬間は除く(motion-tokens.mdを参照。Playはペイオフのために使う)。
  • 新しい画面に着地した後、何かが動き出す前にホールドすること:ライトな画面で約0.9秒、デフォルトで1.4秒、テキストの多い画面で約2.4秒。
  • タップはそのコンテキストとともにフレーミングすること:ボタン単体ではなく、行やグループに押し込む。
  • フィルム言語はUIの動作を決して上書きしない。すべての要素は独自のレイヤーでアニメーションする。
  • タップマーカーはタップ時のみ表示。スクロール時に指は表示しない。
  • スライドのループは20秒以内に収めること。ただし、ストーリーがさらに必要で相手が同意した場合はこの限りではない。解説クリップは教える瞬間だけループする。
  • フルレンダリングの前に低解像度プレビューを行うこと。
  • QAパスなしでの納品は禁止。
  • レビュワーが指摘をくれたら、それをルールにして書き留めること。

ファイル

  • references/behavior.md:プロトタイプを実際の製品のように動作させる方法
  • references/fidelity.md:元のデザインに完全に一致させる方法
  • references/sharing.md:フィードバックのために設定する方法
  • references/pacing.md:ウォークスルービデオのプレゼンテーションペーシング
  • references/motion-tokens.md:イージング、継続時間、モーションパターン
  • references/qa.md:すべての納品が合格すべきチェック
  • references/feedback-log.md:指摘がルールになる方法と実際の例
  • kit/shell.html:ニュートラルなプロトタイプシェル(ツールバー、デスクトップ/モバイル、デバイスフレーム、キャプション、タップヒント)
  • kit/proto.css、kit/proto.js:トランジション、シート、トースト、スケルトン、カーソル

関連スキル