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-level quality_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 は authored src_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 が働きやすい