MUST USE when source footage or a material folder is provided and material understanding or 03_analysis generation is needed. Trigger not only on explicit analysis requests ('分析して', '素材を見て') but also when the user points at footage and says things like 'この動画で', 'この素材で', or any request that requires understanding the provided media before planning or editing.
select-clips
MUST USE when 01_intent/creative_brief.yaml and 03_analysis artifacts exist and the user asks to choose clips, extract candidate segments, run triage, or build 04_plan/selects_candidates.yaml. Use before /blueprint whenever selects are missing, and re-run when the brief or analysis changes.
含まれるファイル(3)
- SKILL.md7.3 KB
- references/reject-patterns.md3.2 KB
- references/selection-criteria.md5.7 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
select-clips — 素材選定
いつ使うか(必ず発火する条件)
- ユーザーが「クリップを選んで」「候補を抽出して」「triage して」「selects を作って」と言ったとき
01_intent/creative_brief.yamlと03_analysis/assets.json/segments.jsonが揃っていて、04_plan/selects_candidates.yamlを作るときfull-pipelineの Step 4 として呼ばれたとき- brief 更新後、analysis 更新後、あるいは must_have / must_avoid の解釈をやり直す必要があるとき
このスキルを省略してはいけない。 brief と analysis があっても selects が無ければ、/blueprint は must-have tracing、reject 判断、coverage 判断を失う。
前提条件
schemas/selects-candidates.schema.jsonを守ることruntime/commands/triage.tsの prerequisite に合わせ、analysis artifacts が揃い、analysis gate がblockedでないこと01_intent/creative_brief.yamlが存在すること- 主 evidence は
03_analysis/assets.json,03_analysis/segments.json,transcripts,contact_sheets,filmstrips,quality_flags,peak_analysis - 先に
references/selection-criteria.mdとreferences/reject-patterns.mdを読み、判断基準を固定してから候補を書き始めること
やること(ステップ)
Step 1: brief を selection obligations に変換する
- brief の
message,audience,emotion_curve,must_have,must_avoidを読む - 各
must_have[i]について、どのsegment_id/candidateがそれを満たすかを先に特定する must_haveを満たす候補には、可能な限りevidenceにbrief.must_have[i]を入れて trace できる状態にするmust_avoid[i]に該当する素材は positive candidate に入れない。除外理由を残したい場合はrole: rejectにし、rejection_reasonとevidence: ["brief.must_avoid[i]"]を付ける- どの
must_haveにも対応できる素材が見つからない場合は、黙って埋めずにselection_notesへ欠落を書く。必要なら human clarification 前提で止める
Step 2: analysis artifacts から候補を集める
assets.jsonで asset landscape と asset-levelquality_flagsを確認するsegments.jsonで各 segment のsummary,transcript_excerpt,quality_flags,tags,peak_analysisを確認する- transcript-backed dialogue は transcript で line を再確認する
- must-have 該当や曖昧な segment は
contact_sheets/filmstripsで visual confirmation する message/audience/emotion_curveに寄与しない素材は無理に採らない
Step 3: reject を先に確定する
references/reject-patterns.mdを使い、must_avoid, 技術的 NG, privacy, duplicate を先にふるい落とすmust_avoidに該当する素材はrole: rejectを優先する。単なる不採用ではなく、「避けるべき理由がある」と operator に分かる形で残す- 技術的に致命的な素材、対象外人物や秘匿情報が映る素材、同一シーンの劣後テイクは positive candidate から外す
- 軽微な欠点は即 reject にせず、
risksやquality_flagsに残して候補として残してよい - 初見視聴者向けの hook / opening では、直前文脈がないと対象が分からない「両方」「双方」「どちらも」や、私的な前提説明へ依存する断片を単独採用しない。近接する antecedent を同じ候補窓に含めるか、別の自己完結した候補を優先する
- 個人的な話題自体を一律 reject しない。brief の audience が cold audience で、商品価値への接続より内輪の前提理解が先に必要な場合だけ omit / risk / reject を選ぶ
Step 4: peak-aware で in/out と trim_hint を決める
peak_analysisがある segment では、手書きで平坦な midpoint を置かず、peak evidence を優先するpeak_analysis.recommended_in_outがあり、peak_analysis.support_signals.fused_peak_score >= 0.70のときは、best_in_us/best_out_usを authored window の第一候補にする- それ以外では、
peak_analysis.peak_moments[]の中から最も強い payoff moment を 1 つ選び、その timestamp を基準にsrc_in_us/src_out_usを決める - 近接した同型 peak が複数ある場合は別 candidate を乱造せず、1 つの editorial moment としてまとめる
trim_hint.source_center_usは選んだ peak の timestamp に合わせるtrim_hint.interest_point_labelはpeak_moments[].descriptionを優先し、無ければtypeを使うtrim_hint.interest_point_confidenceは選んだ peak のconfidenceを使うtrim_hint.window_start_us/window_end_usは authoredsrc_in_us/src_out_usの範囲内に置く。runTriage()は clamp するが、無効値を前提にしないtrim_hint.preferred_duration_usは peak を含む「使いたい尺」を表す。アクション系は peak 前を長め、感情系やリアクション系は peak 後を長めに取るpeak_analysisが無い場合だけ、transcript / contact sheet / visual tags を根拠に in/out を決める
Step 5: 優先度付けと coverage を決める
references/selection-criteria.mdの順に、must-have充足 → reject除外 → 品質 → coverage → diversity で順位を付けるsemantic_rankは「なんとなく」ではなく、その時点の優先順位を反映して単調に振るeligible_beatsは schema 上 optional だが、runtime/compiler/score.tsとruntime/script/read.tsが参照するため、可能なら必ず付ける- hook / experience / closing に置ける候補が偏らないようにする
- 同じ
asset_idや同じ scene の近似候補ばかりに寄せない
Step 6: selects_candidates.yaml を書く
- 各 candidate の必須項目は
segment_id,asset_id,src_in_us,src_out_us,role,why_it_matches,risks,confidence selection_notesとeditorial_summaryに、must-have の充足状況、reject の方針、coverage 上の意図を短く残す- reject 候補を入れる場合は
role: rejectにしてrejection_reasonを必ず入れる candidate_idは optional。自信がなければ省略してよく、runtime/commands/triage.tsが canonicalize 時に deterministic に補完する
出力 artifact
04_plan/selects_candidates.yaml
注意事項
src_in_us < src_out_usを守る。schema だけではなく validator でも落ちるasset_idは03_analysis/assets.jsonに存在するものだけを使う- unsupported field を invent しない。特にこの repo の
schemas/selects-candidates.schema.jsonは peak-aware extension の一部をまだ許可していないため、reasoning に使った score をそのまま未定義 key で書かない trim_hintは optional だが、あると compiler の adaptive trim が働きやすい
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
Use when selects_candidates.yaml exists and the user asks to design structure, build an edit blueprint, or create 04_plan/edit_blueprint.yaml.
日本語の概要は準備中です。原文の説明を表示しています。
Use when edit_blueprint.yaml and selects_candidates.yaml are ready and the user asks to compile the rough cut, generate timeline.json, or apply a review patch.
日本語の概要は準備中です。原文の説明を表示しています。
MUST USE when the user asks to crop, reframe, trim, or improve composition of still photos, especially selected event photos, album photos, portraits, speakers, panels, workshops, or group photos. Use after photo selection or correction when the task is composition improvement rather than selecting images.
日本語の概要は準備中です。原文の説明を表示しています。
MUST USE when starting a new video project, when the user provides footage and asks to edit/create a video, or when 01_intent/creative_brief.yaml does not yet exist. This skill interviews the user to understand their intent before any editing begins. Never skip this step.
日本語の概要は準備中です。原文の説明を表示しています。
Use after changing prompts, skills, the compiler, or editorial policies — or when the user asks to measure edit quality, run regression evals, check agreement with approved edits, or says '評価して', '一致率を測って', 'eval を回して'. Compares agent output against human-approved golden projects.