Design Intent

design-intent — 意図ヒアリング

いつ使うか（必ず発火する条件）

• ユーザーが素材を渡して「編集して」「動画を作って」「粗編集して」と言ったとき
• 新しいプロジェクトを開始するとき（01_intent/creative_brief.yaml が存在しない）
• full-pipeline の Step 2 として呼ばれたとき
• 「意図を決めて」「creative brief を作って」と明示的に言われたとき

このスキルを省略してはいけない。 brief なしに triage や blueprint に進むと、エージェントの判断基準がなくなり品質が下がる。

前提条件

• schemas/creative-brief.schema.json と schemas/unresolved-blockers.schema.json を守ること
• 可能なら 03_analysis/assets.json と 03_analysis/segments.json を読み、素材理解を反映すること
• runtime/commands/intent.ts の dialogue flow に沿うこと:
  1. purpose capture → 2. constraint capture → 3. autonomy capture → 4. blocker extraction → 5. readback confirmation

やること（ステップ）

Step 1: 素材を把握する

• 03_analysis/assets.json があれば読んで、素材の本数・尺・内容を把握する
• segments.json の peak_analysis や display_name があれば、どんなシーンがあるかを理解する
• 素材がまだ分析されていなければ、先に analyze-footage スキルを実行する

Step 2: ユーザーにヒアリングする（省略不可）

references/interview-questions.md を参照し、以下の Phase に沿って質問する。

Phase 1: 目的と背景（プロデューサー視点）— 必須

• 何のための映像か
• 誰に見せるか
• 見た人にどうなってほしいか
• 期限や制約

Phase 2: 素材の理解（ディレクター視点）— 素材がある場合は必須

• 一番見せたいシーン
• 使いたくない素材（NG カット）
• 時系列は重要か
• BGM のイメージ

Phase 3: トーンと演出（演出家視点）

• 全体の雰囲気
• 感情のカーブ
• テロップの要否
• 避けたい演出

Phase 4: 自律性の確認（コラボレーション設計）— 必須

• エージェントに任せてよい判断
• 必ず確認してほしい判断

Phase 5: マーケティング視点（該当する場合のみ）

• 配信プラットフォーム
• アスペクト比

Phase 6: 複数納品物の分離（複数尺・複数比率の場合は必須）

• 長尺と短尺、横型と縦型で audio_policy、CTA、字幕量、冒頭 hook を個別に確認する
• 「BGMなし」など1本への判断を、別尺・別プラットフォームへ暗黙に継承しない
• runtime、delivery、audio、CTA のいずれかが異なる納品物は、原則として納品物ごとの brief を作る。共通 brief を使う場合も variant ごとの差分を明記する

質問のルール:

• 1回の質問は最大3つまで。質問攻めにしない
• ユーザーの最初の説明で明らかな項目はスキップしてよい
• 曖昧な回答は深掘りする（「いい感じに」→「具体的には？」）
• ユーザーの言葉をそのまま brief に使う

Step 3: creative_brief.yaml を作成する

references/creative-brief-schema-guide.md を参照し、ユーザーの回答をフィールドにマッピングする。

必須フィールド:

• project.title, project.strategy, project.runtime_target_sec
• message.primary
• audience.primary
• emotion_curve, must_have, must_avoid
• autonomy.mode, autonomy.may_decide, autonomy.must_ask
• resolved_assumptions
• 短尺SNSでは audio_policy を必ず明示する。CTAが目的に含まれる場合は、表示文言と期待アクションを must_have に明記する

Step 4: unresolved_blockers.yaml を作成する

• ヒアリングで解決できなかった疑問を blocker として記録
• 各 blocker: id, question, status, why_it_matters, allowed_temporary_assumption
• status: blocker は compile gate を止める hard blocker

Step 5: 読み返し確認（省略不可）

• 作成した brief をユーザーに読み返す
• 「この内容で進めてよいですか？」と確認する
• 修正があれば反映する

出力 artifact

• 01_intent/creative_brief.yaml
• 01_intent/unresolved_blockers.yaml

注意事項

• unresolved_blockers.yaml の status: blocker は compile gate を止める
• allowed_temporary_assumption は null か文字列で必ず埋める
• content_hint は VLM の認識精度に直結するので、ユーザーの説明から必ず抽出する
• profile (keepsake, commercial 等) から duration_mode が自動推定される
• brief を埋める前にユーザーに聞く。推測で埋めない。