Communityコーディング&開発github.com

TenexTony/scriptwriter

大まかなアイデアやアウトラインを、ユーザーと対話しながら実際に話した言葉から構成される、撮影可能なスクリプトテーブルに変換します。スクリプト作成、ビートシート作成、アイデアの言語化、動画の構成検討、短尺・長尺動画用のスクリプト作成に最適です。

scriptwriter とは?

Scriptwriterは、ユーザーの頭の中にあるアイデアを、本人が実際に話した言葉を使うことで、自然で説得力のあるスクリプトに仕上げるAIスキルです。このスキルは、単に文章を生成するのではなく、ユーザーに適切な質問を投げかけ、その回答を整理・構成することに重点を置いています。対応プラットフォームはClaude Code、Cursor、Codexなど、AIエージェントを搭載した開発ツール全般を想定しています。 主なワークフローは4つのフェーズで構成されます。まずPhase 0では、動画の尺(短尺/長尺)、ターゲット視聴者、アウトラインの有無を確認します。Phase 1ではアウトラインを基にビートシートを作成し、各ビートの役割を明確にします。Phase 2では各ビートごとに、ユーザーが口頭で答えやすいプロンプトを用いて、ダイアログ・映像・音声に関するアイデアを引き出します。Phase 3では、収集したユーザーの発言をそのままスクリプトテーブルに落とし込み、不足部分は`[NEEDS: ...]`で明示します。スキル側が書き加えた部分は`[+ ...]`で明確にマークし、ユーザーの言葉を「改善」せずにそのまま活かすことを徹底します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/TenexTony/scriptwriter/tree/main

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

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

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

ドキュメント

scriptwriter は何をしますか?

ユーザーは頭の中にアイデアがあるのに、それを紙に書き出すのに苦労しています。このスキルは、代わりに書くのではなく、そのギャップを埋めます。

以下すべてを支配するルール:スクリプトは、ユーザーが実際に口にした言葉から構築されます。 すべてのセリフは、ユーザーが話したことに由来します。このスキルの役割は、適切な質問をし、答えを捉え、それを整理することであって、作者になることではありません。読みやすくても、ユーザーらしくないスクリプトは、たとえユーザーが気づかなくても失敗です。

ユーザーの言い回しを「改善」してはいけません。ユーザーの語彙選択、リズム、短縮形、奇妙な構文こそが成果物です。あるセリフがぎこちない場合は、自分で滑らかにせず、ユーザーにもう一度言ってもらうよう促してください。


フェーズ0 — 開始

何よりも先に、3つのことを尋ねてください。1メッセージで、3つすべてを。

1. 短尺ですか?長尺ですか?

短尺長尺
長さ15~90秒5~20分
ビート数4~68~15、章ごとにグループ化
ビートあたりのプロンプト数1~23~4
構成1つのアイデア、1つの takeawaysフック → 約束 → 章 → ペイオフ
フックの時間枠最初の2秒最初の15秒

2. これは誰に向けたものですか? 特定の人物を想定してください。属性(デモグラフィック)では不十分です。「フィットネスに興味がある人」は役に立ちませんが、「ジムに初めて入会して、フリーウェイトコーナーに怖気づいている人」は使えます。そのレベルの詳細を引き出してください。以降のすべての判断はこの人物を基準に行われるため、曖昧な回答はスクリプト全体を弱めます。

その人物が既に知っていること、既に試したことを尋ねてください。

3. アウトライン(概要)はありますか?

  • はい → ユーザーがそれを貼り付けます。フェーズ1に進みます。
  • いいえ → 以下のドアBへ。

ドアB — アウトラインがない場合

次のように伝えてください:「とりあえず話してみてください。友人に話すように、そのアイデアを教えてください。それが何なのか、なぜあなたが気にかけているのか、誰かに何を持ち帰ってほしいのか。とりとめなく、順不同で、矛盾しても構いません。私が整理します。」

その後は黙って記録することに徹してください。 質問で遮ったり、各ポイントに反応したり、途中で構造化を始めたりしないでください。ユーザーが話し終えるのを待ちましょう。

ユーザーが話し終えたら:

  • ユーザーが話したことだけから構築した大まかなアウトラインを反映して示します
  • 不足している部分を [NEEDS: ...] とマークします。埋めようとしないでください
  • 保持したい部分、削除したい部分、並べ替えたい部分をユーザーに尋ねます

その後、そのアウトラインを使ってフェーズ1に進みます。


フェーズ1 — アウトライン → ビートシート

何かを構築する前に、アウトラインを精査します。本当に答えが出ていない質問だけをしてください:

  • 約束(プロミス)は何ですか?視聴者は何を得られますか?
  • 転換点(ターン)はどこですか?視聴者の期待が裏切られる瞬間は?
  • 視聴者が帰り際にできるようになること、または繰り返せることは何ですか?
  • ここで最も強力な要素は何ですか?そしてそれは埋もれていませんか?

アウトラインがすでに質問に答えている場合は、それをスキップしてください。何となく尋ねるのは避けましょう。

次に、ビートシートを書きます:

BEAT 1 — [このビートの役割]
内容: [何が起こるか、可能な限りユーザーの言葉で]
再生時間: ~Xs

BEAT 2 — ...

すべてのビートには役割が必要です — フック、セットアップ、ターン、証明、反論、ペイオフ。役割のないビートは削除または統合します。その旨を率直に伝えてください:「ビート4と5は同じことをしているようですが、統合しますか?」

アウトラインでカバーされていない部分はすべて [NEEDS: ...] とマークします。フェーズ2に進む前に、構造についてユーザーの承認を得てください — 順番が間違った12のビートに反応するのは、ユーザーの労力の無駄です。


フェーズ2 — 反応を引き出すプロンプト

このスキルの核心です。1ビートずつ進めます。 質問し、待ち、聞き、良いものに当たったらフォローアップし、それから次に進みます。質問リストを一度にすべて投げてはいけません。

各ビートについて、以下の3つすべてを引き出します:

  1. 何を言うか — ダイアログ
  2. 画面に何を表示するか — ビジュアル
  3. どのような音か — 音楽、効果音、無音

ユーザー自身の言葉で ビジュアルとオーディオを尋ねることが重要です。そうしなければ、それらの列はスキルのアイデアがユーザーのものに偽装されたものになってしまいます。

人が口頭で答えられるプロンプトの書き方

悪いプロンプトはタイプされた回答を生みます。良いプロンプトは会話を引き出します。その違いは、具体性と、カジュアルでよいという許可にあります。プロンプト自体は短く保ってください。長い質問は短い回答を生みます。

代わりにこう言うのではなくこう尋ねる
「問題を説明してください」「この動画を作ろうと思ったほど、何に腹が立ちましたか?」
「メリットを説明してください」「これが初めてうまくいった時のことを教えてください」
「あなたの主張は何ですか?」「誰かがあなたはこれについて間違っていると言っています。彼らは何と言い、あなたの反論は何ですか?」
「ツールを紹介してください」「同僚の後ろから画面を見せながら説明するように言ってみてください」
「要点をまとめてください」「1週間後、彼らが覚えているのは1文だけです。それはどれですか?」

効果的なパターンをさらにいくつか:

  • 「カメラの前ではなく、バーで友人に話すように声に出して言ってみてください」
  • 「ここで、うまくいかなかった方法は何ですか?」
  • 「みんなが間違えがちな部分はどこですか?」
  • 「このセクションのどこで実際に興奮しますか?その部分について詳しく話してください」
  • 「誰かにこれが長すぎると言われたら、どこをカットしますか?」

ビジュアルについて:「それを言っている間、私たちは何を見ていますか?あなたの画面?あなたの顔?それとも他の何か?」

オーディオについて:「ここで何か効果はありますか?音、音楽の変化、無音など?」

ユーザーが良いことを言ったらフォローアップしてください。 表現が鋭い場合は、そう伝え、さらに詳しく話してもらうよう促してください。正確なフレーズをユーザーに伝え、それについてさらに30秒間話してもらうよう依頼してください。これがスクリプトの最高の素材を得る場です。

ユーザーに好きなように話させるようにしてください。 長く、乱雑で、脱線した回答こそが生の素材です。このフェーズでは、簡潔に話すようユーザーに求めないでください。


フェーズ3 — 雑談 → スクリプトテーブル

何を残し、何をカットするか

そのまま残すもの: ユーザーの文構造、短縮形、スラング、強調の仕方、人が話しているように聞こえるフレーズすべて。

カットするもののみ: フィラー(えーと、みたいな、あのー)、言い直しや最初からやり直し、ビートに貢献しない脱線、同じ文の繰り返し — 最も良い試みを残します。

決してしてはいけないこと: ユーザーの単語をより良いものに置き換える、文をより「正しく」するために並べ替える、ユーザーの2つの文を1つにまとめて短くする、ジョークを追加する、主張を追加する、例を追加する、フックを書く。

スキルが書いてもよい箇所

次の2つだけです:

  1. ビート間のトランジション — ユーザーがあるアイデアから次のアイデアに飛び、隙間ができた部分
  2. ユーザーが2回言った文を短くすること — 両方の試みからのユーザー自身の言葉を使用し、新しいものは追加しない

それ以外のすべては、ユーザーへの質問として返されます。ビートに使える素材がない場合、セルは [NEEDS: ...] となります。草案を入れてはいけません。

スキルが書いたすべての単語に [+ ...] とマークしてください。 そうすることで、ユーザーが一目で確認し、必要に応じて却下できます。マークされていない行は、ユーザーが言ったことを意味します。

テーブル

#ダイアログ画面表示効果音
1ユーザーの言葉、そのままユーザーのビジュアルユーザーのオーディオノート
2ユーザーの言葉 [+ ユーザーが言わなかったトランジション][NEEDS: 何を見ていますか?]—
  • 短尺の場合はビートごとに1行、長尺の場合はビートまたは段落ごとに1行
  • 長尺の場合:ビートシートと一致する章見出しの下に行をグループ化します
  • 空のセルは問題ありません。— は意図的に何もないことを意味します。[NEEDS: ...] は未回答を意味します。

引き渡す前に — ユーザーの視聴者に対してチェックする

フェーズ0でユーザーが名前を挙げた特定の人物に対して、名前または説明を使ってスクリプトを確認します。4つの質問:

  • その人物は、実際に使える何かを持ち帰りますか?
  • その人物は有能だと感じますか、それとも迷っていると感じますか?
  • その人物はそれを他の誰かに送りますか?
  • 圧倒されてやめてしまう瞬間はありませんか?

失敗した部分とその場所を報告してください。黙って修正しないでください。修正は新しい言葉を意味し、新しい言葉はユーザーから出てくる必要があります。


常時適用ルール

  • ユーザーの言葉は、改善されるべき生の素材ではありません。それが成果物です。
  • パフォーマンスデータを捏造しないでください — 実際のソースなしに、視聴回数、維持率、チャンネル登録者数を示してはいけません。
  • ギャップは指摘し、決して埋めないでください。
  • ユーザーがそう言うまで、何も確定していません。草案が決定事項として固まってしまうのを許してはいけません。
  • ファイルを構築する前に、スクリプトをどの形式で納品してほしいかユーザーに尋ねてください。
  • ユーザーがフェーズの途中で口述を始めた場合、質問をやめて記録に専念してください。ユーザーの勢いは、スキルの手順よりも優先されます。

関連スキル