name: cut-story
description: このスキルは、動画の内容を機械的にカットする前に、動画が実際に何についてのものかを決定するために使用します（例：「bau die Story」「was soll ins Video」「was kann raus」「welche Themen bleiben」「kürz das auf 6 Minuten」「mach daraus ein kurzes Video」「wo ist der Hook」「sortier die Themen」「worum geht es hier eigentlich」「build the story」「decide what stays」「structure this」「cut this down to N minutes」「find the hook」「reorder the topics」）。これは project.json に「story」ブロックを書き込むコンテンツ選択パスです。文字起こしの後、ラフカットの前に実行します。
argument-hint: [project-slug] [target-minutes]
arguments: [project, target]
cut-story は何をしますか？
動画が何であるかを決定します。機械的なカットは発言順序を維持して締めるだけですが、このパスはどのトピックブロックを残すか、どの順序で配置するか、フックはどこかを決定します。25分の雑談を6分の動画に変えられる唯一の段階であり、視聴者が見るかどうかを最も左右する段階です。
引数：$project はプロジェクトスラッグ、$target は目標時間（分、オプション）。完全なリクエストテキストは $ARGUMENTS にあります。スラッグが指定されていない場合は、セッションフックの PIPELINE_STATE で指定されたプロジェクトを使用し、その旨を通知します。
以下の動詞名はビルドコントラクトに従います。python engine/ve.py --help の出力と異なる場合は、CLI が優先されます。CLI の名前を使用し、不一致がある場合はその旨を伝えてください。
前提条件
projects/$project/project.jsonが存在し、stageがtranscribed以降であること。transcript.pathが解決され、transcript.word_countが設定されていること。stageがまだintakeの場合は、停止して最初に文字起こしスキルを実行してください。
このパスを二回目に無言で実行しないでください。すでに story.blocks が存在する場合は、現在の決定内容を最初に表示し、修正するか置き換えるかをユーザーに尋ねてください。
ステップ1 - 読みやすいトランスクリプトを取得する
ワードレベルのJSONは読みづらい散文です。最初に平坦化します：
python engine/ve.py transcript flatten $project --numbered
これにより、単語が25語ごとにワードインデックスマーカーが付いた連続テキストとして出力されます。ワードインデックスは、story ブロックが保存するアンカーです。秒やタイムコードは決して保存しないでください。
ステップ2 - トランスクリプトが長い場合は transcript-analyst にディスパッチする
word_count > 2500（ドイツ語で約15分）の場合は、内蔵でトランスクリプトを読む代わりに transcript-analyst エージェントにディスパッチします。
理由：5000語のトランスクリプトは、セッションの残りのために必要なコンテキストを消費します。また、アナリストは約40行の要約を返します。自分で読むと偏りが生じます。すべての文を読んだ後では、すべてが重要に感じられます。新しいコンテキストの方がより厳しくカットでき、これは正しい動作です。
エージェントに以下を渡します：平坦化されたトランスクリプトのパス、目標時間、output.platform のプラットフォーム、そして $ARGUMENTS にあるユーザーの指示。エージェントは決定と根拠を含む候補ブロックを返します。最終的な判断は依然としてあなたが行います。エージェントの削除をレビューし、ユーザーが明示的に保持を要求した削除は覆してください。
2500語以下の場合は、自分でトランスクリプトを読んでください。
ステップ3 - 動画を一文で命名する
ブロックの決定を行う前に、視聴者が終了時に、開始時には信じていなかったことを一文で（ドイツ語で）書いてください。それをユーザーに表示します。
その文が書けない場合、素材にはまだ動画は含まれていません。そのことを率直に伝えて停止し、形のないものを組み立てるよりも、追加収録を勧めてください。これは実際に起こり得る結果であり、誠実に伝える方が、きれいな6分の無意味なものよりも有用です。
以降のすべての決定は、その一文に従います。
ステップ4 - トランスクリプトをブロック化する
ブロックとは、移動しても意味が保たれる単位です。30秒から3分、1つのポイントです。ブロックは連続したワード範囲であり、トランスクリプトを隙間や重複なくタイル状に区切ります。
ポーズでブロックを切らないでください。主題が変わるところで切ってください。ドイツ語では、話し手自身の標識語が信頼できます：also, jetzt zum Thema, das andere ist, kurz noch, um nochmal zurückzukommen, was viele nicht wissen。
ステップ5 - 削除バイアスで決定する
デフォルトの期待値：記録された単語の40〜60%を削除します。 素材の70%以上が残っている場合、決定は行われていません。戻って削除テストをより厳しく適用してください。
削除テスト（順に適用）：
- 信念テスト。 ブロックを削除します。視聴者が最終的に信じる内容は変わりますか？変わらない場合、削除します。これが主要なテストであり、残りはそのショートカットです。
- 第二の例テスト。 同じポイントの2つの例：より具体的な方を保持し、もう一方を削除します。話し手は教えるためではなく考えるために自分を繰り返します。
- 孤児テスト。 削除されたペイオフのための準備は、もはやノイズです。削除し、他の削除のたびに再確認してください。孤児は連鎖的に発生します。
- ウォームアップテスト。 ほぼすべての録音の最初の60〜90秒は、のどの慣らしです。デフォルトで削除し、その旨をユーザーに伝えてください。この単一のルールは、すべてのフィラーワード削除を組み合わせたよりも多くの動画を改善します。
- 要約テスト。 言ったことの口頭要約（「では、もう一度簡単にまとめると」）は、話す際の補助であり、構造ではありません。動画が真に教育的で長い場合を除き、削除します。
保持シグナル：強いものから順に：数字、名前、日付、話し手が認める具体的な間違い、具体的な実例。具体性は最も強い保持シグナルです。 抽象的な枠組みは安価であり、10秒で再録音できますが、具体的な逸話はそうはいきません。
最終的な長さに依存するブロックには、"decision": "maybe" を使用してください。maybe はブロックの20%未満に抑えてください。それを超えると、ニュアンスではなく優柔不断であり、ユーザーが本来あなたが行うべき作業を行うことになります。
$target が設定されている場合は、妥当性を確認してください。保持されたブロックのワードカウントの合計を、話し手の測定されたレート（word_count / ソース時間（分））で割ります。何かを書き込む前に推定値を報告してください。ドイツ語のトーキングヘッド音声は、約130〜160語/分です。
ステップ6 - フックを見つける
フックは、ほとんどの場合、録音の先頭にはありません。人々は、ウォームアップしてパフォーマンスをやめた後、遅れて本当のポイントに到達します。
最初に最後の3分の1を検索してください。 次のようなものを探します：説明されるまで間違って聞こえる主張、予想より大きいまたは小さい数字、認められた失敗、賭け金（「これに2週間かかった」）。15〜25秒を選んでください。1〜2文であり、段落ではありません。
story.hook として、word_range と、なぜ移動されたかを説明するドイツ語の note とともに書き込んでください。フックを前に移動することは、ほとんどの場合正しい唯一の並べ替えです。
ステップ7 - 順序付け、理由を明確にできる場合のみ並べ替える
並べ替えには、正当な理由が2つだけあります：
- フックを先頭に移動する。
- あるブロックが後のブロックの質問に答えるため、そのブロックの前に置く必要がある。
それ以外はすべて、録音順序を維持します。話された素材を並べ替えると、後方参照が壊れます。レンダリングまでその破綻に気づきません。その時点では3つの段階が実行されています。
参照整合性チェック（移動されたすべてのブロックに必須）。 移動されたブロックの最初の2文を読み、後方参照がないか確認します。ドイツ語では、これらは静かに壊れます：also, deswegen, deshalb, dadurch, dabei, wie gesagt, das, dieser/diese/dieses, außerdem, trotzdem, andererseits, wie eben erwähnt。移動されたブロックがこれらで始まる場合は、ブロックを1文後ろから開始するか、maybe とマークしてユーザーに繋ぎの台詞が必要だと伝えてください。移動して期待してはいけません。
ステップ8 - ストーリーブロックを書き込む
story.blocks[] と story.hook を projects/$project/project.json に、docs/edl-schema.md で定義されているスキーマに正確に従って書き込みます。id、word_range（半開区間、ワードインデックス）、label（ドイツ語）、decision（keep|drop|maybe）、order（出力順序。録音順序と異なる場合がある）、rationale。
交渉不可のルール：
- 何も削除されません。 削除されたブロックも
"decision": "drop"として配列に残ります。すべての決定は、1つのフィールドを反転させることで元に戻せる必要があります。ユーザーは一部の削除に同意しない可能性があり、パスを再実行せずに元に戻せる必要があります。 rationaleは1つのドイツ語の節であり、理由を説明し、内容を説明しません。 「trägt das kernargument（核となる主張を支える）」は有用です。「spricht über Frame-Snapping（フレームスナップについて話している）」はラベルであり、理由ではありません。orderは保持されたブロックに対して0から始まる密な番号です。 削除されたブロックは録音順のインデックスを取得します。これらは不活性ですが、競合してはいけません。stageを"story"に設定します。segments[]には触れないでください。それは cut-rough の領域です。
次に、ユーザーにコンパクトな表を表示します。順序、ラベル、決定、推定分数。その表が成果物であり、JSONではありません。
ステップ9 - 引き渡し
機械的なカットは保持されたブロック内でのみ実行されることを明示的に伝えます。これは正しいだけでなく、より効率的です。削除される素材に対してフィラーやリテイク検出を行うのは無駄な作業です。その後、cut-rough スキルを提供します。
障害モード
| 症状 | 原因 | 修正 |
|---|---|---|
| すべてが必須に見える | 長いトランスクリプトをインラインで読んだ | transcript-analyst にディスパッチする。新しいコンテキストはより厳しくカットする |
| 素材の85%を保持した | 編集上の決定が行われなかった | すべてのブロックに信念テストを再適用する |
| 並べ替え後に動画が不自然に跳ぶ | 後方参照が壊れている | 移動されたすべてのブロックに対してステップ7のチェックを実行する |
word_range に隙間や重複がある | ブロックがタイル状になっていない | ブロックは連続かつ半開区間でなければならない |
| ユーザーがほとんどの削除を拒否する | ステップ3で誤った文を使用した | ユーザーと一緒に一文のテーゼを書き直し、やり直す |