デモスクリプトスキル

実際の製品を探索し、ユーザーと共同で構造化されたデモ動画スクリプトを作成します。

存在理由

優れたデモ動画には優れたスクリプトが必要です。質の低いデモは、内容が散漫になったり、重要な部分を飛ばしたり、進行が速すぎたりします。このスキルは、/record-demo が自動実行できる、正確でレビュー可能なスクリプトを生成します。

ワークフロー

ステージ 1: ブリーフィング

ユーザーからコンテキストを収集します:

必須:

デモする製品/機能
ターゲットURL（ステージング/本番）
オーディエンス（見込み客、既存ユーザー、開発者、社内チーム）

任意（指定がない場合は質問）:

表示する具体的なフロー（例：「手順と期待される結果を含むテストケースを作成」）
トーン（プロフェッショナル、カジュアル、技術的、マーケティング向け）
目標時間（30秒、1分、3分、5分）
強調する重要なポイント
避ける/スキップするもの

指定がない場合のデフォルト:

オーディエンス: 製品を評価中の見込みユーザー
トーン: プロフェッショナルで親しみやすい
時間: 1〜2分
解像度: 1920x1080

ステージ 2: 製品探索

Playwrightブラウザツールを使用して、実際の製品UIを探索してください。

これは重要です — UIがどのように見えるかを推測しないでください。実際にナビゲートしてください:

ブラウザでターゲットURLを開く
関連する各ページ/画面のスクリーンショットを撮る
実際のボタンラベル、メニュー項目、フォームフィールドを確認する
ナビゲーションフローを理解する
実際のセレクタでUI要素を特定する

探索フローの例:
  → アプリのURLに移動
  → ダッシュボードのスクリーンショット
  → ターゲット機能をクリック
  → 各状態変化のスクリーンショット
  → すべてのインタラクティブ要素の正確なセレクタを記録
  → ローディング状態、アニメーション、モーダルを確認

なぜ先に探索するのか？

実際のセレクタ名を使用する（推測して録画時に失敗するのを防ぐ）
画面に表示されているものと一致する正確なナレーションが可能
自然なフローを発見できる（ユーザーが言い忘れたステップがあるかもしれない）
潜在的な問題（認証壁、読み込みの遅さ、空の状態）をキャッチできる

認証:

アプリにログインが必要な場合、ユーザーに認証情報または事前認証済みセッションを依頼する
または、テストデータがあるステージング環境を使用する
注意: 録画フェーズのためにクッキー/セッションを保存する

ステージ 3: スクリプト作成

metadata と scenes 配列を含む、JSON形式の構造化スクリプトを生成します。

完全なJSONスキーマ、アクションリファレンス、ハイライトスタイルについては、references/script-format.md を参照してください。

ステージ 4: レビューと反復

スクリプトを人間が読みやすい形式（生のJSONではなく）でユーザーに提示します。次のようにフォーマットしてください:

🎬 デモスクリプト: "Creating Your First Test Case"
時間: ~90秒 | オーディエンス: 見込みユーザー

━━━ シーン 1: オープニング — ダッシュボード概要 ━━━
  → /dashboard に移動
  🎙️ "OneTestへようこそ。最初のテストケースを作成しましょう。"
  ⏸️ 2秒待機

━━━ シーン 2: テストケースに移動 ━━━
  → クリック: サイドバー "Test Cases"
  🎙️ "サイドバーから「テストケース」セクションを開きます。"
  ✨ ハイライト: サイドバーアイテム（パルス）
  ⏸️ 1.5秒待機

━━━ シーン 3: 新しいテストケースを作成 ━━━
  → クリック: "作成" ボタン
  🎙️ "「作成」をクリックして新しいテストケースを始めます。"
  ✨ ハイライト: 作成ボタン（グロー）
  ⏸️ 2秒待機

  → タイトルに入力: "有効な認証情報でログイン"
  🎙️ "わかりやすいタイトルを付けます。"
  ⏸️ 1秒待機

  → 説明に入力: "ユーザーがログインできることを確認..."
  🎙️ "このテストケースが何を検証するか、明確な説明を追加します。"
  ⏸️ 1.5秒待機

━━━ シーン 4: クロージング ━━━
  → 2秒待機（最終画面で静止）
  🎙️ "以上です。最初のテストケースの準備ができました。"
  ⏸️ 1.5秒待機

推定合計時間: ~90秒

ユーザーと反復:

「シーンを追加/削除しますか？」
「ペーシングは速くしますか、遅くしますか？」
「ナレーションテキストを変更しますか？」
「順序を並べ替えますか？」

ステージ 5: 保存と引き渡し

承認後:

スクリプトJSONを workspace/<date>/demo-script-<name>.json に保存
読みやすいバージョンを workspace/<date>/demo-script-<name>.md に保存
ユーザーに伝える: 「スクリプトの準備ができました！録画するには /record-demo を実行するか、今すぐ録画を開始できます。」

スクリプトアクションリファレンス

10のサポートアクション: navigate、click、type、select、scroll、hover、wait、screenshot、drag、keyboard

5つのハイライトスタイル: pulse、glow、arrow、dim-others、zoom（CSS/JSで注入）

フィールドと例を含む完全なリファレンスは references/script-format.md を参照してください。

ナレーションガイドライン

良いナレーション:

短い文（15語未満）
現在形、能動態（「作成ボタンをクリック」であって「作成ボタンをクリックします」ではない）
何が起こっているかとその理由の両方を説明する（「チームが何をテストすべきかわかるように説明を追加します」）
明らかなことはナレーションしない（「カーソルを…に動かしています」 — 不要）
ポーズをナレーションの長さに合わせる（長いナレーション = 長いポーズ）

ペーシングルール:

最初のシーン: 長めのポーズ（視聴者が画面に慣れるため）
中間シーン: 適度なポーズ
最後のシーン: 最終状態で2〜3秒間静止
入力後: 短いポーズで視聴者が読めるようにする
ページ遷移後: 読み込み完了 + 1秒待って視聴者が画面をざっと見られるようにする

オーディエンス別のトーン:

見込み客: メリットに焦点を当て、簡潔にし、専門用語を避ける
開発者: 技術用語を使用し、設定を表示し、APIに言及してもよい
社内向け: よりカジュアルに、チームの慣習を参照してもよい

優れたデモのためのヒント

データから始める — 空のアプリでデモをしない。テストデータが存在することを確認する。
ハッピーパスを見せる — エッジケースはドキュメントに任せ、デモでは扱わない。
1機能につき1動画 — 90秒の集中した動画 > 10分のツアー。
結果で終わる — メニューではなく、作成/完了したものを表示する。
現実的に名前を付ける — 「有効な認証情報でログイン」 > 「テスト1」。
UIをきれいにする — 不要なタブを閉じ、開発者ツールを非表示にし、クリーンなブラウザプロファイルを使用する。

デモスクリプト