Communitygithub.com

デモリール計画

AIシステム、ツール、ワークフロー、またはビルドのショートデモリールを計画します。ビートシート、撮影・編集仕様書を生成し、60人のクリエイターによる66本の実際のリールからランク付けされたテクニックを使用します。

デモリール計画 とは?

このスキルは、AIシステムやツールが何かを行う様子を示すショートフォームのデモリール(Reel / TikTok / Short)を計画するためのものです。ユーザーが「私のシステムに関するリールを作るのを手伝って」とだけ言った場合でも、それをスクリーンツアー、チュートリアル、または「AIが何かをするのを見て」というデモとして捉え、ビートシート(拍子記)と撮影・編集仕様書を生成します。このスキルの根拠は、66本の実際のリールから収集された分析結果に基づいており、実際に効果のあったテクニック(ライブ感を出す、顔を見せる、摩擦を入れるなど)と効果の低かったテクニック(過度なグラフィック、偽のモック画面など)を明確に区別しています。主にClaude CodeやCodexなどのAIエージェント上で動作することを想定しており、出力はユーザーがすぐに撮影・編集に取り掛かれる具体的な指示を含みます。スキルはevidence.mdやexamples.mdなどの参考文献を参照し、各ルールのリフト(改善効果)を数値化して提示します。また、ユーザー独自のブランドルールやデータがある場合は、そちらを優先するように設計されています。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/MonsterDylan/claude-saved-to-skills/tree/HEAD/examples/ai-content-ideas/skills/demo-reel-plan

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

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

ドキュメント

デモリール計画 は何をしますか?

このスキルは、AIシステムやツールが何かを行う様子を示すリールを計画します。出力はビートシートと、ユーザーがそれに沿って撮影できる撮影・編集仕様書です。

その背後にある主な発見:このスキルの元になったコレクションでは、最も広く拡散したリールはデモをライブ感あふれるものにしていました。目に見える人、手で撮影された実際の画面、何かが少しうまくいかずに対処される様子。手の込んだプロダクション手法(すべての単語にグラフィック、デザインされたモック画面)は中央値以下でした。したがって、このスキルは実際の出来事を見せることを推奨し、洗練はオプションとして扱います。

すべてのルールの証拠は references/evidence.md にあります。例は references/examples.md にあります。リフトは、比較可能なリールの中央値からのプラスまたはマイナスのポイントで、0から100のスコアです。これは手作業で収集された66本のコレクションにおける相関関係であり、オプションをランク付けするものです。何かを保証するものではありません。

リフトが見られたルール

ミッドアクションで始める。 +20、7人のクリエイター。 導入ではなく、タスクが始まるところで開く。最初の言葉はコマンド、プロンプト、または最初のステップ。 [DboqOSvEj_b]

スクリーンデモ中に顔をフレーム内にキープする。 +16、8人のクリエイター。 小さなバブル、下部パネル、リアクションレイヤー。画面が完全に人を置き換えることは決してない。人間のいないデモは広告のように見える。 [Dd6izTYiln1, DboqOSvEj_b, DeHX34IxveJ]

デモ内に摩擦を入れる。 +12、6人のクリエイター。 スムーズにいかない瞬間が一つ:スロットが取られている、誰かがそれがAIかどうか尋ねる、ツールなしではタスクが失敗し、ツールを使うと成功する。摩擦はデモに中間点を与える。それを計画し、40%の位置に配置する。もしあれば、ビルド中の実際の摩擦を使う。 [DboqOSvEj_b, DdrUdGbkrT0, Dd6izTYiln1]

実際の画面をスマートフォンで撮影する。 +8、11人のクリエイター。 手持ちで、それを指して、結果にズームインする。それが存在し、動作していることを証明する。画面録画は、視聴者が読まなければならないテキストにのみ使用する。 [DbcPo0dMQ3d, DbYhDu_MADd, DXA4gi1DCOx]

ビデオ自体にテクニックを見せる。 +18、3人のクリエイター。証拠は薄い。該当する場合に使用する。 リールが編集、プロンプト、または構造を教える場合、リールはそれを目に見える形で使用する必要がある。 [De8SPjEAuV0, DambEp1igDW]

主張の時点でソースを表示する。 +13、3人のクリエイター。証拠は薄い。 リポジトリページ、見出し、README、あなたがそれを言うときに画面上に表示する。 [DfCXigRSyAo, Dd6izTYiln1]

デフォルト(全員がこれを行い、どちらにもリフトなし)

  • 最初のフレームは完成したものの動作を示す(19人のクリエイター)。
  • 顔と画面がフレームを共有する場合:画面またはグラフィックを上に、顔を下に、キャプションを継ぎ目に(17人のクリエイター)。
  • 単語ごとのキャプション、1~3単語、1つのアクセントカラー(16人のクリエイター)。
  • ステップ数を言い、各ステップを画面上にラベル付けする(18人のクリエイター)。
  • 「ここがトリックだ」や「クレイジーな部分」というマークされた後半のビートを、お願いの前に配置する(8人のクリエイター、+4)。
  • 早い段階でそれが本物であることを証明する:クリックして開く、ファイルを開く(9人のクリエイター、+4)。
  • 最後の話し言葉として1つのコメントキーワードを、キーワードを画面上に表示する(32人のクリエイター)。コメントを増やし(0.16%に対して2.73%)、リーチは変わらない。

注意事項(これらは中央値を下回った)

  • 話す名詞ごとに、1~3秒ごとに新しいビジュアル。 -23、15人のクリエイター。最も一般的な手の込んだ編集で、最も弱い結果。映像が伝えられない情報を伝える場合にのみグラフィックを使用する。リールにグラフィックを敷き詰めないこと。
  • 実際の製品の代わりにデザインされたモック画面。 -25、5人のクリエイター。たとえ見た目が悪くても、実際のものを見せること。
  • お願いのために顔にカットバックする。 -25、8人のクリエイター。製品を画面に表示し続け、キーワードをラベルとして固定する。顔がすでにフレーム内にある場合は、そのショットにとどまること。
  • システムをエリアごとに巡回する。 -16、6人のクリエイター。ツアーはリストである。うまくいったものは、カウントされた主張で開き、エージェントが10秒でクリック可能であることを証明し、リール中盤に気にかける第二の理由を追加した。計画がツアーである場合、代わりに追跡するタスクを与える:システムを移動する1つのジョブ。
  • お願いの直前に成果物を表示する。 -16、6人のクリエイター。無料のものを表示する場合は、視聴者がそれを欲しがるであろう時点で、より早く表示すること。

長さ

短さだけのためにカットしないこと。上位3分の1のティーチリールの中央値は63秒、下位3分の1は42秒だった。60秒を超えるリールは45秒以下のリールよりも高いスコアを得た(56.5対43.5)。デモがライブであり続ける限り実行し、無音部分をカットし、内容はカットしない。ハードカットの数はどちらにもパターンを示さなかった。

生成するもの

# <作業タイトル>
約束: 1文、視聴者が何が起こるのを見るか
長さ:  秒単位の目標、理由付き
証明:  画面上の何がこれが本物であるかを示すか

## ビート
| 時間 | ビート | 発言 | 画面上 | ショット |
(ミッドアクションで開く、0:10までに本物であることを証明する、40%付近で摩擦、ペイオフ、後半のビート、お願い)

## 撮影リスト
何を撮影するか、どのように(スマートフォンで画面、フェイスバブル、画面録画)、最も撮影しやすい順序で

## 編集仕様
レイアウト、キャプション、場所を得る価値のある数少ないグラフィックとその理由、意図的に生のままにしておくもの

## お願い
最後の話し言葉と画面上のラベル

## 撮影前
画面に表示してはいけないもの:個人データ、クライアントまたは顧客名、トークン、キー、ファイルパス

## 使用した証拠
この計画で決定を変えたルールのみ、各1行、最大8行

実際のシステムのデモは実際のデータを示す。画面に何が表示されるか(サイドバーの名前、ターミナルのトークン、回答の内容)を確認し、それをフレームの外に保つ方法を述べること。これは見落としやすく、間違えるとコストがかかる。

証拠セクションは短く保つこと。ユーザーは、計画が自分がしていたであろうこととなぜ異なるのかを知る必要があり、このファイルの再陳述は不要である。

ユーザーがキャプション、プレゼント企画の概要、または配信メッセージも希望する場合、それらは別の仕事である。1行でその旨を述べ、それらを提供すること。そうすることで計画は計画のまま保たれる。

誰かが今日撮影できるようにビートを書くこと。ユーザーの実際のシステムと実際の数値を使用すること。何かがユーザーの画面でどのように見えるかわからない場合は、質問するか、その仮定をマークすること。摩擦の瞬間が存在しない場合は、正直な候補を1つ提案し、それが現実のものである必要があることを述べること。

ユーザー自身のルールとデータとの適合性

ユーザーが独自のブランドルール、編集標準、または自身のアカウントからのパフォーマンスデータを持っている場合、それらがこのコレクションよりも優先される。なぜなら、彼らのオーディエンスはこれら60人のクリエイターと同じではないからである。ここのルールが彼らのルールと矛盾する場合、1行でその旨を述べ、選択させてください。黙ってどちらかを適用しないこと。

関連スキル