Implementation spec: governance, decision intelligence, theme system, and E2E bug fixes
Implements the 2026-04-02 transformation spec (Phases 1-8) and fixes all critical bugs found during 5-pipeline E2E testing. Governance & Decision Intelligence: - Pipeline-specific stage order in checkpoint (replaces global STAGES list) - Provider scoring engine (lib/scoring.py) with 7-dimension weighted ranking - Decision log artifact enforced at proposal/idea stage across all 10 pipelines - Delivery promise classifier prevents silent motion-to-still downgrades - Structured shot language in scene_plan schema (camera, lens, lighting, DOF) - Variation checker and slideshow risk scorer block samey output before render - Creative intake, capability extension, and creative-intake meta skills - Final self-review artifact with 5 mandatory checks before presenting output - Source media review contract for user-supplied footage Render & Theme System: - Remotion AnimatedBackground now derives colors from playbook (no more hardcoded dark blue fintech gradient on every video) - video_compose builds custom ThemeConfig from playbook YAML colors/fonts — custom playbooks flow through to Remotion automatically - Explainer component wires theme to all child components (charts, cards, etc.) - resolveAsset() handles absolute paths on Windows/Unix via file:// URIs - RENDERER_FAMILY_MAP synced with actual Remotion compositions Critical Bug Fixes: - Windows npx subprocess: run_command() resolves .cmd wrappers via shutil.which() - Silent renderer downgrade: Remotion failure now returns explicit error with options instead of silently falling back to FFmpeg - .env inline comment parsing strips trailing # comments from API keys - concat_path UnboundLocalError in video_compose finally block - audio_mixer and showcase_card capture=True kwarg bug - Selector estimate_cost() calls fixed (_select_tool -> _select_best_tool) - asset_manifest schema expanded with provider, license, subtype fields - screen-demo subtitle_gen moved from required to optional tools - Duration drift detection in post-render final review (>25% warns)
This commit is contained in:
calesthio
@@ -55,17 +55,71 @@ FLUX.2 supports up to 4 references (klein) or 8 references (pro/max/flex). Refer
|
||||
|
||||
Use the same `seed` parameter across generations with similar prompts. Produces similar compositions but is fragile to prompt changes — use as supplement, not primary strategy.
|
||||
|
||||
## Prompt Template
|
||||
## Prompt Construction — 3-Part Contextual Approach
|
||||
|
||||
**Do NOT copy the playbook's `image_prompt_prefix` verbatim into every prompt.** That's what makes all scenes look the same. Instead, build each prompt from 3 contextual layers:
|
||||
|
||||
### Part 1: Scene-Specific Style Direction (from shot_language + texture_keywords)
|
||||
|
||||
Use the scene's `shot_language` fields to set camera and lighting:
|
||||
```
|
||||
[SHOT SIZE from shot_language.shot_size, e.g., "medium close-up"].
|
||||
[LIGHTING from shot_language.lighting_key, e.g., "golden hour warm light"].
|
||||
[DEPTH from shot_language.depth_of_field, e.g., "shallow depth of field with bokeh"].
|
||||
[TEXTURE from scene.texture_keywords, e.g., "film grain, warm tones"].
|
||||
```
|
||||
|
||||
If the scene has no shot_language, fall back to the template below.
|
||||
|
||||
### Part 2: Playbook Consistency Anchor (adapted, not verbatim)
|
||||
|
||||
Extract the ESSENCE of the playbook's visual language — don't copy the prefix. For example:
|
||||
- Playbook says "Clean, minimal illustration with soft shadows, muted color palette" → Adapt to: "muted color palette, soft shadows"
|
||||
- Playbook says "Bold flat motion graphics, vibrant gradients" → Adapt to: "vibrant flat style"
|
||||
|
||||
The anchor keeps scenes visually coherent without making them identical.
|
||||
|
||||
### Part 3: Scene Description
|
||||
|
||||
The actual content of the scene. Be specific — replace generic words with concrete details.
|
||||
|
||||
**BAD:** "A person using a computer in a modern office"
|
||||
**GOOD:** "Software developer in a dimly lit home office, blue monitor glow reflecting off glasses, desk cluttered with energy drinks and sticky notes"
|
||||
|
||||
### Full Prompt Example (with shot_language)
|
||||
|
||||
```
|
||||
[STYLE PREFIX from playbook].
|
||||
[SCENE DESCRIPTION: subject, action, environment].
|
||||
Medium close-up, golden hour warm lighting, shallow depth of field.
|
||||
Muted earth tones, soft shadows.
|
||||
Beekeeper in white protective gear lifting a frame dripping with honey,
|
||||
late afternoon sun catching golden droplets, lavender field blurred
|
||||
in the background. Film grain, warm amber tones.
|
||||
16:9 aspect ratio.
|
||||
```
|
||||
|
||||
### Fallback Template (when no shot_language is available)
|
||||
|
||||
```
|
||||
[ADAPTED STYLE ANCHOR from playbook — 5-10 words, not the full prefix].
|
||||
[SCENE DESCRIPTION: specific subject, action, environment].
|
||||
[LIGHTING: golden hour / overcast / studio softbox / dramatic side-light].
|
||||
[COMPOSITION: wide shot / medium shot / close-up / overhead / isometric].
|
||||
[CAMERA: Shot on [camera] with [lens] at [aperture]] (for photorealistic only).
|
||||
16:9 aspect ratio.
|
||||
```
|
||||
|
||||
### Using lib/shot_prompt_builder.py
|
||||
|
||||
For programmatic prompt construction, use the shot prompt builder which automates the 3-part approach:
|
||||
|
||||
```python
|
||||
from lib.shot_prompt_builder import build_shot_prompt
|
||||
prompt = build_shot_prompt(scene, style_context=playbook_data)
|
||||
```
|
||||
|
||||
This converts the structured shot_language fields into natural-language prompts
|
||||
optimized for image/video generation providers.
|
||||
|
||||
### Style-Specific Prompt Patterns
|
||||
|
||||
| Style | Prompt Pattern |
|
||||
|
||||
@@ -0,0 +1,115 @@
|
||||
# Capability Extension Protocol
|
||||
|
||||
## When to Use
|
||||
|
||||
When you encounter a production need that no existing tool covers. The agent can extend the system — but with guardrails. This replaces the blanket "do NOT write ad-hoc Python scripts" rule with a structured protocol.
|
||||
|
||||
## Assessment First
|
||||
|
||||
Before writing anything, classify the gap:
|
||||
|
||||
| Gap Type | Example | Action |
|
||||
|----------|---------|--------|
|
||||
| **One-off transform** | Custom image crop, color adjustment, format conversion | Write a project-scoped Python script |
|
||||
| **Recurring visual need** | New illustration style, custom chart type | Generate a custom playbook or Remotion component |
|
||||
| **Missing provider** | User wants a specific API not in the registry | Create a minimal tool wrapper |
|
||||
| **Missing knowledge** | Agent doesn't know how to prompt a specific model | Use web search to learn, then document as a Layer 3 skill |
|
||||
|
||||
## Rules for Ad-Hoc Scripts
|
||||
|
||||
Scripts are allowed ONLY when:
|
||||
1. No existing tool covers the need (verified against registry via preflight)
|
||||
2. The script is idempotent (safe to re-run)
|
||||
3. The script produces a file artifact in the project workspace
|
||||
4. The script is logged in the decision log: `category: "capability_extension"`
|
||||
5. The user is informed: "I wrote a custom script for X because no existing tool handles Y"
|
||||
6. The script does NOT call external APIs without user approval
|
||||
|
||||
Scripts go in: `projects/<project-name>/scripts/`
|
||||
|
||||
### Script Template
|
||||
|
||||
```python
|
||||
"""<One-line description of what this script does>
|
||||
|
||||
Created by capability extension protocol because: <reason no existing tool covers this>
|
||||
Decision log entry: <decision_id>
|
||||
"""
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
def main(input_path: str, output_path: str) -> None:
|
||||
# Idempotent: check if output already exists
|
||||
out = Path(output_path)
|
||||
if out.exists():
|
||||
print(f"Output already exists: {out}")
|
||||
return
|
||||
|
||||
# ... transformation logic ...
|
||||
|
||||
print(f"Created: {out}")
|
||||
|
||||
if __name__ == "__main__":
|
||||
main(sys.argv[1], sys.argv[2])
|
||||
```
|
||||
|
||||
## Rules for Custom Playbooks
|
||||
|
||||
When the existing playbooks don't match the brief:
|
||||
1. Use `lib/playbook_generator.py` to create a new playbook
|
||||
2. Base it on the closest existing playbook if possible
|
||||
3. Validate against `schemas/styles/playbook.schema.json`
|
||||
4. Save to `styles/custom/<project-name>.yaml`
|
||||
5. Log as decision: `category: "playbook_selection"`, `subject: "custom playbook created"`
|
||||
|
||||
## Rules for New Skills (Technique Learning)
|
||||
|
||||
When the agent discovers technique knowledge during web research:
|
||||
1. Document it as a project-scoped skill: `projects/<project-name>/skills/<name>.md`
|
||||
2. Follow the Layer 3 skill format:
|
||||
- Provider name and version
|
||||
- Provider-specific prompting patterns
|
||||
- Optimal parameters for this use case
|
||||
- Quality tips and known failure modes
|
||||
- Source URLs for the information
|
||||
3. Reference it in the decision log
|
||||
4. Suggest promoting to `.agents/skills/` if it's generally useful
|
||||
|
||||
## Rules for Tool Wrappers
|
||||
|
||||
When a user needs a specific provider that isn't in the registry:
|
||||
1. The agent can create a minimal `BaseTool` subclass
|
||||
2. Save to `projects/<project-name>/tools/<name>.py`
|
||||
3. It MUST inherit from `BaseTool` and implement the full contract (input_schema, execute, capabilities, etc.)
|
||||
4. It MUST be registered before use
|
||||
5. Log as decision: `category: "capability_extension"`
|
||||
6. Requires user approval before first paid API call
|
||||
|
||||
## What Is Still Forbidden
|
||||
|
||||
- Bypassing the pipeline (all production still goes through stages)
|
||||
- Calling external APIs without user knowledge
|
||||
- Modifying existing tools in `tools/` (create wrappers, don't modify originals)
|
||||
- Skipping the decision log
|
||||
- Writing scripts that have side effects beyond their output file (no sending emails, no pushing to remote, no deleting files outside project workspace)
|
||||
|
||||
## Decision Log Entry Format
|
||||
|
||||
Every extension must be logged:
|
||||
|
||||
```json
|
||||
{
|
||||
"decision_id": "ext-001",
|
||||
"stage": "<current stage>",
|
||||
"category": "capability_extension",
|
||||
"subject": "Created custom <script|playbook|skill|tool> for <purpose>",
|
||||
"options_considered": [
|
||||
{"option_id": "existing-tool", "label": "<closest existing tool>", "rejected_because": "<why it doesn't work>"},
|
||||
{"option_id": "extension", "label": "<what was created>", "reason": "<why this approach>"}
|
||||
],
|
||||
"selected": "extension",
|
||||
"reason": "<concise justification>",
|
||||
"user_visible": true,
|
||||
"confidence": 0.8
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,64 @@
|
||||
# Creative Intake
|
||||
|
||||
Before the research stage, gather user intent through targeted questions.
|
||||
Do NOT start production on a vague brief.
|
||||
|
||||
## Required Questions (ask conversationally, not as a survey)
|
||||
|
||||
1. **Purpose**: What is this video FOR? (educate, sell, inspire, document, entertain)
|
||||
2. **Audience**: Who will watch it? (age, expertise, context — "my team" vs "YouTube public")
|
||||
3. **Platform**: Where will it live? (YouTube, internal Slack, social media, presentation, website)
|
||||
4. **Tone**: What should it FEEL like? (serious, playful, cinematic, raw, warm, provocative)
|
||||
5. **References**: Any videos you admire or want this to feel like?
|
||||
6. **Outcome**: What should the viewer DO or FEEL after watching?
|
||||
7. **Constraints**: Budget ceiling? Timeline? Must-include content?
|
||||
|
||||
## How to Ask
|
||||
|
||||
Don't dump all 7 questions at once. Start with purpose and audience,
|
||||
then let the conversation flow. Fill in gaps naturally.
|
||||
|
||||
If the user gives a detailed brief, skip questions they've already answered.
|
||||
|
||||
Identify what the user has already told you. If they said "I want a
|
||||
cinematic brand film for Instagram," you already have purpose (inspire/sell),
|
||||
platform (Instagram), and tone (cinematic). Ask what's missing.
|
||||
|
||||
## Handling Vague Briefs
|
||||
|
||||
When the user says something like "make me a video about X":
|
||||
|
||||
1. Acknowledge the topic — show you understood.
|
||||
2. Ask the single most important missing question first (usually purpose or audience).
|
||||
3. Based on their answer, ask the next most important gap.
|
||||
4. Stop asking when you have enough to start research. You don't need perfect answers — research will fill in details.
|
||||
|
||||
## Handling Detailed Briefs
|
||||
|
||||
When the user provides a multi-paragraph brief or a document:
|
||||
|
||||
1. Summarize what you understood (1-2 sentences).
|
||||
2. Call out any gaps: "I have a clear picture of the audience and tone, but I'd love to know — is there a specific outcome you're hoping for?"
|
||||
3. Confirm the platform and constraints if not stated.
|
||||
|
||||
## Output
|
||||
|
||||
Produce an `intake_brief` (informal, not schema-validated) that the
|
||||
research stage uses as its starting context. Include:
|
||||
|
||||
- Direct quotes from the user where their language reveals intent
|
||||
- Explicit answers to each of the 7 questions (mark any that were inferred vs stated)
|
||||
- Any reference videos/images the user mentioned
|
||||
- Constraints that must be honored (budget, timeline, must-include)
|
||||
|
||||
The intake_brief is passed as context to the research-director, not as a
|
||||
formal artifact. It exists to prevent the research stage from inventing
|
||||
intent that the user never expressed.
|
||||
|
||||
## What NOT To Do
|
||||
|
||||
- Do not present a numbered survey. This is a conversation, not a form.
|
||||
- Do not ask questions the user already answered in their initial message.
|
||||
- Do not delay production unnecessarily — if the brief is clear, move on.
|
||||
- Do not invent answers for questions the user didn't address. Mark them as "not specified" and let the research stage handle ambiguity.
|
||||
- Do not assume the user wants an explainer. Many users want cinematic, animation, or source-led work. Listen for signals.
|
||||
@@ -81,9 +81,9 @@ Based on the user's tier, present **3 ready-to-use prompts** they can copy right
|
||||
>
|
||||
> This will research the topic, write a script, find stock visuals, generate narration with Piper, and compose an animated video with transitions and captions — all free.
|
||||
|
||||
> **Also try:** "Create a 60-second data-driven video about coffee consumption around the world"
|
||||
> **Also try:** "I have a screen recording of a dashboard workflow — make it a polished product demo with captions and a voiceover" *(Screen Demo pipeline)*
|
||||
|
||||
> **Or:** "Make a short explainer about how the internet works, with narration and animated captions"
|
||||
> **Or:** "Turn this interview recording into 3 short clips for TikTok and YouTube Shorts" *(Clip Factory pipeline)*
|
||||
|
||||
**Starter-tier prompts (image gen available):**
|
||||
|
||||
@@ -91,19 +91,19 @@ Based on the user's tier, present **3 ready-to-use prompts** they can copy right
|
||||
>
|
||||
> I'll use FLUX to generate custom images for each scene — much more visually striking than stock.
|
||||
|
||||
> **Also try:** "Make a product launch teaser for a fictional smart water bottle called AquaPulse"
|
||||
> **Also try:** "Make a short documentary-style video about urban beekeeping — keep it grounded and textural, not flashy" *(Hybrid pipeline — source + generated support)*
|
||||
|
||||
> **Or:** "Build a 90-second explainer about the psychology of color in marketing"
|
||||
> **Or:** "Create a classroom-ready video teaching photosynthesis to 8th graders — simple, clear, and engaging" *(Explainer pipeline — teacher mode)*
|
||||
|
||||
**Full-tier prompts (video gen available):**
|
||||
|
||||
> **Try this:** "Create a cinematic 30-second trailer for a sci-fi concept: humanity receives a warning from 1000 years in the future"
|
||||
>
|
||||
> I'll generate actual motion video clips, compose a soundtrack, and deliver a finished cinematic trailer.
|
||||
> I'll generate actual motion video clips, compose a soundtrack, and deliver a finished cinematic trailer. *(Cinematic pipeline)*
|
||||
|
||||
> **Also try:** "Make a 60-second avatar spokesperson video announcing a company rebrand"
|
||||
> **Also try:** "Make a 60-second avatar spokesperson video announcing a company rebrand" *(Avatar Spokesperson pipeline)*
|
||||
|
||||
> **Or:** "Create a 90-second animated explainer about quantum computing for middle school students, with a fun narrator voice and custom soundtrack"
|
||||
> **Or:** "I recorded a founder update on my webcam — make it feel polished, confident, and premium without looking fake" *(Talking Head pipeline)*
|
||||
|
||||
**Rules for prompt suggestions:**
|
||||
- Present exactly 3 prompts.
|
||||
|
||||
+136
-3
@@ -107,10 +107,143 @@ Structure your review as:
|
||||
|
||||
| Stage | What matters most |
|
||||
|-------|-----------------|
|
||||
| research | Source diversity, claim verifiability, visual reference quality |
|
||||
| proposal | Delivery promise clarity, renderer family selection, music/voice plan, decision log started |
|
||||
| idea | Hook uniqueness, research depth, angle diversity |
|
||||
| script | Timing accuracy, narrative arc, enhancement cue density |
|
||||
| scene_plan | Full coverage, visual variety, asset feasibility |
|
||||
| scene_plan | Full coverage, visual variety, asset feasibility, slideshow risk score |
|
||||
| assets | File existence, style consistency, budget adherence |
|
||||
| edit | Timeline coverage, audio sync, subtitle presence |
|
||||
| compose | Playability, duration accuracy, audio quality |
|
||||
| edit | Timeline coverage, audio sync, subtitle presence, delivery promise compliance |
|
||||
| compose | Playability, duration accuracy, audio quality, pre-compose validation pass |
|
||||
| publish | SEO quality, metadata completeness, export packaging |
|
||||
|
||||
## Slideshow Risk Review
|
||||
|
||||
Run at **scene_plan** and **edit** stages. Use `lib/slideshow_risk.py` to compute the score.
|
||||
|
||||
### At scene_plan stage:
|
||||
1. Compute `score_slideshow_risk(scenes, renderer_family=renderer_family)`
|
||||
2. If verdict is **"fail"** (average ≥ 4.0): **CRITICAL** — scene plan must be revised before proceeding
|
||||
3. If verdict is **"revise"** (average ≥ 3.0): **SUGGESTION** — flag specific dimensions scoring ≥ 3.5
|
||||
4. If verdict is **"strong"** or **"acceptable"**: note in review summary, no finding needed
|
||||
|
||||
### At edit stage:
|
||||
1. Recompute with full edit_decisions: `score_slideshow_risk(scenes, edit_decisions, renderer_family)`
|
||||
2. Same thresholds apply — if the edit stage made things worse (higher score than scene_plan), flag it
|
||||
|
||||
### What to flag per dimension:
|
||||
| Dimension | What to say when score ≥ 3.0 |
|
||||
|-----------|------------------------------|
|
||||
| repetition | "X scenes use the same layout/shot size — vary the visual grammar" |
|
||||
| decorative_visuals | "X scenes have no stated purpose (no information_role or shot_intent)" |
|
||||
| weak_motion | "Camera movement exists but lacks narrative justification" |
|
||||
| weak_shot_intent | "X scenes are missing shot_intent — why does this frame exist?" |
|
||||
| typography_overreliance | "X% of scenes are text/stat cards — video feels like animated slides" |
|
||||
| unsupported_cinematic_claims | "Claiming cinematic but missing hero moments / lighting / movement" |
|
||||
|
||||
## Decision Log Review
|
||||
|
||||
Run at **every stage** after proposal. The decision log (`schemas/artifacts/decision_log.schema.json`) is a cumulative audit trail.
|
||||
|
||||
### Checks:
|
||||
1. **Existence**: Does the checkpoint reference a `decision_log_ref`? If not after proposal stage, flag as **SUGGESTION**.
|
||||
2. **Coverage**: Does every major choice have an entry? Key decisions that MUST be logged:
|
||||
- Provider selection (which image/video/audio tool and why)
|
||||
- Style/playbook selection
|
||||
- Music track selection
|
||||
- Voice selection
|
||||
- Renderer family selection
|
||||
- Any fallback or downgrade (e.g., motion → still)
|
||||
3. **Quality**: Each decision should have:
|
||||
- At least 2 `options_considered` (not just the one picked)
|
||||
- A `reason` that isn't boilerplate ("best option" is not a reason)
|
||||
- Correct `confidence` (0.0–1.0) — flag if everything is 1.0 (unrealistic)
|
||||
4. **User visibility**: Decisions marked `user_visible: true` should be ones the user would actually care about (not internal routing)
|
||||
|
||||
### Severity:
|
||||
- Missing decision log after proposal: **SUGGESTION** (first time), **CRITICAL** (if still missing at edit stage)
|
||||
- Decision with only 1 option considered: **SUGGESTION** — "Log rejected alternatives for auditability"
|
||||
- All decisions at confidence 1.0: **SUGGESTION** — "Unrealistic confidence — at least provider selection involves tradeoffs"
|
||||
|
||||
## Creative Differentiation Review
|
||||
|
||||
Run at **scene_plan** and **edit** stages. Prevents the "every video looks the same" failure mode.
|
||||
|
||||
### Checks:
|
||||
1. **Variation check** (scene_plan only): Use `lib/variation_checker.py` → `check_scene_variation(scenes)`.
|
||||
- If verdict is "poor" (score ≤ 2): **CRITICAL** — "Scene plan lacks variety: [list violations]"
|
||||
- If verdict is "fair" (score ≤ 3): **SUGGESTION** — note specific suggestions from the checker
|
||||
|
||||
2. **Playbook alignment**: Is the active playbook appropriate for this content?
|
||||
- Cinematic trailer using "clean-professional" theme → flag mismatch
|
||||
- Educational explainer using "anime-ghibli" theme without user request → flag
|
||||
|
||||
3. **Shot language completeness** (scene_plan):
|
||||
- Every scene should have at least `shot_size` and `shot_intent`
|
||||
- Hero moments should have full shot_language (all 6 fields)
|
||||
- Flag scenes with empty shot_language as **SUGGESTION**
|
||||
|
||||
4. **Renderer family match** (edit stage):
|
||||
- Does `renderer_family` in edit_decisions match what was set at proposal?
|
||||
- If changed without documented reason in decision log → **CRITICAL**
|
||||
|
||||
## Delivery Promise Review
|
||||
|
||||
Run at **edit** and **compose** stages. Uses `lib/delivery_promise.py`.
|
||||
|
||||
### At edit stage:
|
||||
1. Extract delivery promise from proposal packet or edit_decisions metadata
|
||||
2. Run `promise.validate_cuts(cuts)` against the resolved cut list
|
||||
3. If `valid` is False: **CRITICAL** — "Delivery promise violation: [violations]"
|
||||
4. Check `motion_ratio`: if a motion-led promise has < 50% motion cuts, flag even if technically valid
|
||||
|
||||
### At compose stage:
|
||||
1. The `_pre_compose_validation()` in video_compose.py enforces this automatically
|
||||
2. Review should verify the validation was not bypassed (check render report for warnings)
|
||||
3. If render succeeded despite low motion ratio on a motion-led promise, flag as **SUGGESTION**
|
||||
|
||||
## Source Understanding Review
|
||||
|
||||
Run at **research** and **proposal** stages when user-supplied media files exist.
|
||||
|
||||
### Checks:
|
||||
1. **Existence**: If user-supplied files were provided to the project, does a `source_media_review` artifact exist?
|
||||
- If user media exists but no `source_media_review`: **CRITICAL** — "User supplied media but the agent did not inspect it before planning. Run `lib/source_media_review.review_source_media()` before proceeding."
|
||||
2. **Actual inspection**: Does every file entry have `reviewed: true` and a non-empty `technical_probe`?
|
||||
- If `reviewed` is missing or `technical_probe` is empty: **CRITICAL** — "The source_media_review claims review but contains no probe data. The file was not actually inspected."
|
||||
3. **Planning reflection**: Do the `planning_implications` appear in the proposal's production plan?
|
||||
- If quality risks were identified (e.g. low resolution, mono audio) but the proposal doesn't mention them: **SUGGESTION** — "Source media has quality risks that the proposal does not address."
|
||||
4. **Content accuracy**: Does the plan rely on content that the source media does not actually contain?
|
||||
- E.g. plan assumes interview dialogue but transcript_summary shows no speech: **CRITICAL** — "Plan assumes dialogue but source media contains no speech."
|
||||
5. **No hallucinated content**: The agent must not infer unsupported content from filenames alone. If `content_summary` says "interview footage" but the probe only shows 3s of silent video, flag as **CRITICAL**.
|
||||
|
||||
### Severity:
|
||||
- Missing `source_media_review` when user files exist: **CRITICAL** at proposal stage
|
||||
- Unreviewed files (no probe): **CRITICAL**
|
||||
- Plan doesn't reflect quality risks: **SUGGESTION**
|
||||
- Plan assumes content not in source: **CRITICAL**
|
||||
|
||||
## Final Self-Review Review
|
||||
|
||||
Run at **compose** and **publish** stages. Ensures the agent reviewed the actual rendered output.
|
||||
|
||||
### At compose stage:
|
||||
1. **Existence**: Does a `final_review` artifact exist alongside the `render_report`?
|
||||
- If missing: **CRITICAL** — "Compose produced a render_report but no final_review. The agent must inspect the rendered output before presenting it."
|
||||
2. **Status check**: What is `final_review.status`?
|
||||
- `pass` → OK, proceed
|
||||
- `revise` → The agent should have fixed issues before presenting. If the pipeline continued anyway: **CRITICAL** — "Self-review found revise-worthy issues but the agent presented anyway."
|
||||
- `fail` → The pipeline MUST NOT proceed. If it did: **CRITICAL**
|
||||
3. **Check completeness**: All 5 required checks must have data:
|
||||
- `technical_probe` must show a valid container with plausible duration/resolution
|
||||
- `visual_spotcheck` must have `frames_sampled >= 4`
|
||||
- `audio_spotcheck` must report narration/music presence
|
||||
- `promise_preservation` must confirm `delivery_promise_honored`
|
||||
- `subtitle_check` must report presence/absence
|
||||
- Any check with missing data: **SUGGESTION** — "Self-review check [X] has incomplete data"
|
||||
4. **Promise preservation**: If `promise_preservation.silent_downgrade_detected` is true: **CRITICAL** — "Self-review detected silent downgrade from motion-led to still-led."
|
||||
|
||||
### At publish stage:
|
||||
1. Verify that `final_review` was passed through as a required artifact
|
||||
2. If `final_review.status` is not `pass`: **CRITICAL** — "Cannot publish with a non-passing self-review"
|
||||
3. If `final_review.issues_found` is non-empty and `recommended_action` is not `present_to_user`: **SUGGESTION** — "Self-review found issues; verify they were resolved before publishing"
|
||||
|
||||
@@ -9,7 +9,7 @@ This stage prepares the actual animated ingredients: narration, diagrams, math r
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Schema | `schemas/artifacts/asset_manifest.schema.json` | Artifact validation |
|
||||
| Prior artifacts | `state.artifacts["scene_plan"]["scene_plan"]`, `state.artifacts["script"]["script"]`, `state.artifacts["idea"]["brief"]` | Tool path and beat map |
|
||||
| Prior artifacts | `state.artifacts["scene_plan"]["scene_plan"]`, `state.artifacts["script"]["script"]`, `state.artifacts["proposal"]["proposal_packet"]` | Tool path and beat map |
|
||||
| Tools | `tts_selector`, `image_selector`, `video_selector`, `math_animate`, `diagram_gen`, `code_snippet`, `music_gen` — selectors auto-discover all available providers from the registry | Asset production options |
|
||||
| Playbook | Active style playbook | Visual consistency |
|
||||
|
||||
@@ -95,8 +95,38 @@ Recommended metadata keys:
|
||||
- missing capabilities are surfaced honestly,
|
||||
- every referenced file exists.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during asset generation:
|
||||
- Use `web_search` to verify visual accuracy of subjects (e.g. what does this building actually look like?)
|
||||
- Use `web_search` to find reference images before generating illustrations
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Visual accuracy matters. If the script mentions a specific place, person, or object,
|
||||
verify what it actually looks like before generating images. Don't rely on
|
||||
the AI model's training data — it may be wrong or outdated.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Using high-variance generation when a deterministic asset would work better.
|
||||
- Rebuilding the same title or label system repeatedly.
|
||||
- Hiding failed asset paths instead of reporting them.
|
||||
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
|
||||
@@ -164,7 +164,32 @@ Note: This approach is not yet proven in the OpenMontage pipeline.
|
||||
- **Always offer at least one free/local option** alongside paid approaches
|
||||
- **Never silently downgrade** — if the best approach needs a key the user doesn't have, say so explicitly
|
||||
|
||||
### Step 4: Design Concept Options
|
||||
### Step 3d: Mood Board (Before Concepts)
|
||||
|
||||
Before developing full concepts, present a quick mood board to catch direction mismatches early:
|
||||
|
||||
- **3-5 reference images** (animation style examples from web search — show what each approach LOOKS like)
|
||||
- **Color palette direction** (2-3 options, e.g. clean data-viz vs vibrant motion graphics vs sketchy hand-drawn)
|
||||
- **Tone references** ("Think: 3Blue1Brown meets Kurzgesagt" or "Think: Pixar short meets infographic")
|
||||
- **1-2 animation style samples** (if Manim: mathematical elegance; if Remotion: smooth data transitions; if AI video: cinematic motion)
|
||||
|
||||
Ask: **"Does this FEEL like what you're imagining? Any of these off-track?"**
|
||||
|
||||
This catches style misalignment before concept design. If the user expected hand-drawn and you're heading toward data-viz, better to know now.
|
||||
|
||||
### Step 4: Progressive Reveal and Concept Design
|
||||
|
||||
Don't dump the full proposal at once. Build understanding step by step:
|
||||
|
||||
1. **Research summary** (2-3 sentences): "Here's what I found..."
|
||||
→ User reacts, course-corrects if needed.
|
||||
2. **Mood board** (from Step 3d — already presented)
|
||||
→ User confirms animation style direction.
|
||||
3. **Concept options** (3+ approaches):
|
||||
→ Present below.
|
||||
4. **Invite mixing** (see Step 4c below).
|
||||
5. **Production plan for selected concept** (tools, cost, timeline):
|
||||
→ User approves budget and approach.
|
||||
|
||||
Build **at least 3 genuinely different concepts.** Start from the `angles_discovered` in the research brief and the animation mode analysis.
|
||||
|
||||
@@ -233,6 +258,13 @@ Present all concepts clearly to the user. For each concept, show:
|
||||
4. **Duration** — how long
|
||||
5. **Reuse strategy** — "5 scenes built from 2 templates" vs "8 unique scenes"
|
||||
|
||||
#### Step 5b: Invite Mixing
|
||||
|
||||
After presenting concepts, always say something like:
|
||||
> "You can also mix elements — for example, Concept A's hook with Concept C's animation approach, or Concept B's narrative with Concept A's visual style. What speaks to you?"
|
||||
|
||||
If the user mixes, create a new hybrid concept entry in the proposal_packet with clear attribution: "Hook from Concept A, animation approach from Concept C, narrative structure from Concept B."
|
||||
|
||||
Let the user select, combine, modify, or redirect.
|
||||
|
||||
Record the selection in `selected_concept` with rationale and any modifications.
|
||||
@@ -351,3 +383,22 @@ Validate the `proposal_packet` artifact against `schemas/artifacts/proposal_pack
|
||||
- **Ignoring mathematical accuracy**: If the research brief flagged technical accuracy constraints, the concept MUST respect them. A beautiful but wrong animation is a failure.
|
||||
- **Not distinguishing image_animation from clip_video**: These are fundamentally different. Image-based animation (Approach A) generates still images and uses Remotion for motion/crossfade. Clip-based video (Approach B) generates actual video clips with an AI video model. The user should understand this distinction clearly.
|
||||
- **Silent downgrades**: If the user picked image_animation but image generation fails, STOP and tell them. Never silently fall back to text cards or diagram stills.
|
||||
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
|
||||
@@ -9,7 +9,7 @@ Package the animation so the metadata, thumbnail concept, and platform framing r
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Schema | `schemas/artifacts/publish_log.schema.json` | Artifact validation |
|
||||
| Prior artifacts | `state.artifacts["compose"]["render_report"]`, `state.artifacts["idea"]["brief"]`, `state.artifacts["script"]["script"]` | Final outputs and topic framing |
|
||||
| Prior artifacts | `state.artifacts["compose"]["render_report"]`, `state.artifacts["proposal"]["proposal_packet"]`, `state.artifacts["research"]["research_brief"]`, `state.artifacts["script"]["script"]` | Final outputs and topic framing |
|
||||
| Playbook | Active style playbook | Visual naming consistency |
|
||||
|
||||
## Process
|
||||
|
||||
@@ -9,7 +9,7 @@ You are converting the script into a feasible animation plan. This is the stage
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Schema | `schemas/artifacts/scene_plan.schema.json` | Artifact validation |
|
||||
| Prior artifacts | `state.artifacts["script"]["script"]`, `state.artifacts["idea"]["brief"]` | Beat map and tool path |
|
||||
| Prior artifacts | `state.artifacts["script"]["script"]`, `state.artifacts["proposal"]["proposal_packet"]` | Beat map and tool path |
|
||||
| Playbook | Active style playbook | Palette, typography, motion consistency |
|
||||
|
||||
## Process
|
||||
|
||||
@@ -107,6 +107,17 @@ Before submitting the script, verify:
|
||||
- [ ] Mathematical accuracy is maintained (if applicable)
|
||||
- [ ] Later stages can map scenes cleanly from this script
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during script writing:
|
||||
- Use `web_search` to verify factual claims before committing them to the script
|
||||
- Use `web_search` to find reference images for visual accuracy
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Every factual claim in the script should be traceable to the `research_brief`.
|
||||
If you make a claim that isn't in the research, do additional research and
|
||||
add the source. Do not invent statistics, dates, or attributions.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- **Writing too many ideas into one section.** One beat = one visual idea.
|
||||
|
||||
@@ -93,9 +93,39 @@ When the EP has triggered a narration-over-graphics pivot (neither `talking_head
|
||||
- `pivot_reason`: why the no-avatar path was chosen
|
||||
- All other metadata keys remain the same.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during asset generation:
|
||||
- Use `web_search` to verify visual accuracy of subjects (e.g. what does this building actually look like?)
|
||||
- Use `web_search` to find reference images before generating illustrations
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Visual accuracy matters. If the script mentions a specific place, person, or object,
|
||||
verify what it actually looks like before generating images. Don't rely on
|
||||
the AI model's training data — it may be wrong or outdated.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Building decorative assets before the narration path is solved.
|
||||
- Mixing multiple avatar-generation strategies in one simple spokesperson video.
|
||||
- Marking the stage complete when the core presenter asset is still hypothetical.
|
||||
- (No-avatar path) Generating filler visuals with no connection to the narration — every image must reinforce the spoken point.
|
||||
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
|
||||
@@ -58,6 +58,17 @@ Recommended metadata keys:
|
||||
- CTA placement is clear,
|
||||
- text overlays are restrained.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during script writing:
|
||||
- Use `web_search` to verify factual claims before committing them to the script
|
||||
- Use `web_search` to find reference images for visual accuracy
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Every factual claim in the script should be traceable to the `research_brief`.
|
||||
If you make a claim that isn't in the research, do additional research and
|
||||
add the source. Do not invent statistics, dates, or attributions.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Overstuffing one scene because the script reads well on paper.
|
||||
|
||||
@@ -9,7 +9,7 @@ This stage prepares the usable media for the final cinematic edit: source select
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Schema | `schemas/artifacts/asset_manifest.schema.json` | Artifact validation |
|
||||
| Prior artifacts | `state.artifacts["scene_plan"]["scene_plan"]`, `state.artifacts["script"]["script"]`, `state.artifacts["idea"]["brief"]` | Scene intent and beat plan |
|
||||
| Prior artifacts | `state.artifacts["scene_plan"]["scene_plan"]`, `state.artifacts["script"]["script"]`, `state.artifacts["proposal"]["proposal_packet"]` | Scene intent and beat plan |
|
||||
| Tools | `subtitle_gen`, `audio_enhance`, `image_selector`, `video_selector`, `music_gen` — selectors auto-discover all available providers from the registry | Optional support asset creation |
|
||||
| Playbook | Active style playbook | Brand and typography consistency |
|
||||
|
||||
@@ -26,7 +26,7 @@ Start with:
|
||||
|
||||
These are the primary materials. Everything else is support.
|
||||
|
||||
If `brief.metadata.motion_required = true`, actual moving footage or generated video clips are mandatory. In that case:
|
||||
If `proposal_packet.metadata.motion_required = true`, actual moving footage or generated video clips are mandatory. In that case:
|
||||
|
||||
- stills may be used only as reference material or backing elements inside a larger motion composition,
|
||||
- stills may not replace the planned motion shots,
|
||||
@@ -92,6 +92,17 @@ Recommended metadata keys:
|
||||
- every referenced file exists.
|
||||
- if motion is required, the asset set contains actual video clips for the motion-led beats.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during asset generation:
|
||||
- Use `web_search` to verify visual accuracy of subjects (e.g. what does this building actually look like?)
|
||||
- Use `web_search` to find reference images before generating illustrations
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Visual accuracy matters. If the script mentions a specific place, person, or object,
|
||||
verify what it actually looks like before generating images. Don't rely on
|
||||
the AI model's training data — it may be wrong or outdated.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Generating extra shots before proving the source edit works.
|
||||
@@ -99,3 +110,22 @@ Recommended metadata keys:
|
||||
- Forgetting rights or provenance notes for supplied assets.
|
||||
- Quietly downgrading from video clips to still images because one provider or renderer failed.
|
||||
- Quietly switching providers or models after the user approved a generation path.
|
||||
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
|
||||
@@ -4,14 +4,14 @@
|
||||
|
||||
You are the **Executive Producer (EP)** for a cinematic video (trailers, brand films, montages, short dramatic edits). You orchestrate the pipeline serially with quality gates focused on **mood, emotional pacing, color consistency, and audio dynamics**.
|
||||
|
||||
**No pre-production stages.** Source footage or direction exists. The EP adds cross-stage gates that enforce emotional arc integrity and cinematic polish.
|
||||
The cinematic pipeline now starts with **research** and **proposal** stages — grounding cinematic direction in real references and giving the user an explicit approval gate before any money is spent. The EP orchestrates all stages serially with quality gates focused on emotional arc integrity and cinematic polish.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Pipeline | `pipeline_defs/cinematic.yaml` | Stage definitions |
|
||||
| Skills | All 7 director skills + `meta/reviewer` | Stage execution |
|
||||
| Skills | All 9 director skills + `meta/reviewer` | Stage execution |
|
||||
| Schemas | All artifact schemas | Validation |
|
||||
| Playbook | Active style playbook | Quality constraints |
|
||||
|
||||
@@ -21,18 +21,21 @@ You are the **Executive Producer (EP)** for a cinematic video (trailers, brand f
|
||||
EP_STATE:
|
||||
pipeline: cinematic
|
||||
playbook: <selected>
|
||||
target_duration_seconds: <from brief>
|
||||
target_duration_seconds: <from proposal_packet>
|
||||
budget_total_usd: <configured>
|
||||
budget_spent_usd: 0.0
|
||||
|
||||
# Cinematic-specific
|
||||
emotional_arc: null # from brief: build → reveal → landing
|
||||
emotional_arc: null # from proposal_packet: build → reveal → landing
|
||||
delivery_promise: null # from proposal_packet: motion_required, tone_mode, quality_floor
|
||||
renderer_family: null # from proposal_packet: locked at proposal stage
|
||||
color_grade_target: null # mood-driven color palette
|
||||
hero_moments: [] # key reveal/climax frames
|
||||
music_beat_map: null # audio-driven pacing reference
|
||||
|
||||
artifacts:
|
||||
idea: null
|
||||
research: null
|
||||
proposal: null
|
||||
script: null
|
||||
scene_plan: null
|
||||
assets: null
|
||||
@@ -46,7 +49,7 @@ EP_STATE:
|
||||
|
||||
## Execution Protocol
|
||||
|
||||
Same as standard EP: Initialize → Execute stages serially (idea → script → scene_plan → assets → edit → compose → publish) → Final QA.
|
||||
Same as standard EP: Initialize → Execute stages serially (research → proposal → script → scene_plan → assets → edit → compose → publish) → Final QA.
|
||||
|
||||
Each stage: PREPARE → SPAWN DIRECTOR → REVIEW → GATE DECISION (pass / revise / send-back).
|
||||
|
||||
@@ -74,13 +77,26 @@ The EP may not switch providers, models, or mediums without user approval once t
|
||||
|
||||
## EP-Specific Cross-Stage Checks
|
||||
|
||||
### After IDEA stage:
|
||||
### After RESEARCH stage:
|
||||
```
|
||||
CHECK: Emotional arc definition
|
||||
CHECK: Research grounding
|
||||
- Are visual references specific and relevant (not generic "cinematic" searches)?
|
||||
- Is sound/music direction substantive?
|
||||
- Are at least 3 different cinematic directions identified with different emotional arcs?
|
||||
- Is the motion commitment honest about available capabilities?
|
||||
```
|
||||
|
||||
### After PROPOSAL stage:
|
||||
```
|
||||
CHECK: Delivery promise
|
||||
- Is the emotional arc explicit (build → reveal → landing)?
|
||||
- Is source mode clear (supplied footage vs generated inserts)?
|
||||
- Does the brief explicitly say whether motion is required?
|
||||
- Is the target mood defined and achievable?
|
||||
- Does the proposal explicitly say whether motion is required?
|
||||
- Is the delivery_promise present with all required fields?
|
||||
- Is the renderer_family selected and locked?
|
||||
- Is the music plan resolved (source chosen or explicitly deferred)?
|
||||
- Is the cost estimate honest and per-item?
|
||||
- Has the user approved the proposal?
|
||||
```
|
||||
|
||||
### After SCRIPT stage:
|
||||
@@ -145,7 +161,8 @@ CHECK: Output validation
|
||||
|
||||
| Gate | After Stage | What's Checked | Fail Action |
|
||||
|------|-------------|---------------|-------------|
|
||||
| G1 | idea | Emotional arc, source mode | Revise |
|
||||
| G0 | research | Visual references, mood grounding | Revise |
|
||||
| G1 | proposal | Delivery promise, renderer family, music plan, user approval | Revise |
|
||||
| G2 | script | Beat escalation, duration | Revise |
|
||||
| G3 | scene_plan | Hero moments, visual consistency | Revise |
|
||||
| G4 | assets | Music alignment, source quality, budget | Revise |
|
||||
|
||||
@@ -0,0 +1,241 @@
|
||||
# Proposal Director — Cinematic Pipeline
|
||||
|
||||
## When to Use
|
||||
|
||||
You are the **Proposal Director** for a cinematic video (trailers, brand films, montages, dramatic edits). You sit between the Research Director and the Script Director. You receive a `research_brief` full of visual references, mood research, and cinematic direction options, and transform it into a concrete, reviewable proposal that the user approves before any money is spent.
|
||||
|
||||
**This is the approval gate.** Nothing downstream runs until the user says "go."
|
||||
|
||||
## Prerequisites
|
||||
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Schema | `schemas/artifacts/proposal_packet.schema.json` | Artifact validation |
|
||||
| Prior artifact | `research_brief` from Research Director | Visual references, mood research, cinematic directions |
|
||||
| Pipeline manifest | `pipeline_defs/cinematic.yaml` | Stage and tool definitions |
|
||||
| Tool registry | `support_envelope()` output | What's actually available right now |
|
||||
| Cost tracker | `tools/cost_tracker.py` | Cost estimation data |
|
||||
| Style playbooks | `styles/*.yaml` | Available visual styles |
|
||||
| User input | Subject, footage, preferences | Creative direction |
|
||||
|
||||
## Process
|
||||
|
||||
### Step 1: Absorb the Research
|
||||
|
||||
Read the `research_brief` thoroughly. Extract:
|
||||
|
||||
- **`research_summary`** — the researcher's strongest creative direction.
|
||||
- **`angles_discovered`** — these are your raw cinematic direction candidates.
|
||||
- **Visual references** — the real-world precedents that inform each direction.
|
||||
- **Audio direction** — music mood and sound design notes.
|
||||
- **Source reality** — what footage/stills the user actually has.
|
||||
- **Motion commitment** — whether motion is required.
|
||||
|
||||
### Step 2: Run Preflight
|
||||
|
||||
Before designing concepts, know what tools are available:
|
||||
|
||||
```bash
|
||||
python -c "from tools.tool_registry import registry; import json; registry.discover(); print(json.dumps(registry.support_envelope(), indent=2))"
|
||||
```
|
||||
|
||||
Record:
|
||||
- Video generation providers — **critical for cinematic**. If motion is required, these must be available.
|
||||
- Image generation providers — for support visuals and mood inserts
|
||||
- TTS providers — for narration (if applicable; many cinematic pieces are narration-free)
|
||||
- Music generation — check availability honestly
|
||||
- Enhancement tools — color_grade, audio_enhance are high-value for cinematic
|
||||
- **Remotion render engine** — check `video_compose.get_info()["render_engines"]["remotion"]`
|
||||
|
||||
**Motion-required enforcement:** If the research brief indicates `motion_required: true`, verify that video generation or source footage can actually deliver motion. If neither is available, **do not silently downgrade to still-led**. Instead, present the constraint honestly and let the user decide.
|
||||
|
||||
### Step 2c: Mood Board (Before Concepts)
|
||||
|
||||
Before developing full concepts, present a quick mood board to catch direction mismatches early. Cinematic work is especially susceptible to tone misalignment, so this step is critical:
|
||||
|
||||
- **3-5 reference images** (from web search — real film stills, not generic stock)
|
||||
- **Color palette direction** (2-3 palettes: e.g. desaturated cold vs warm golden vs high-contrast noir)
|
||||
- **Tone references** ("Think: Terrence Malick meets National Geographic" or "Think: David Fincher trailer pacing")
|
||||
- **1-2 music mood references** (genre + energy + emotional arc, e.g. "ambient synth building to orchestral crescendo")
|
||||
|
||||
Ask: **"Does this FEEL like what you're imagining? Any of these off-track?"**
|
||||
|
||||
This is cheaper than building 3 full cinematic directions and catches tone mismatches before they're embedded in concept design. If the user says "less moody, more energetic," you've saved a concept round.
|
||||
|
||||
### Step 3: Design Concept Directions
|
||||
|
||||
Build **at least 3 genuinely different cinematic directions.** Start from the `angles_discovered` in the research brief.
|
||||
|
||||
For each concept, specify all fields in `proposal_packet.concept_options`:
|
||||
|
||||
#### 3a: Title and Emotional Hook
|
||||
|
||||
Cinematic hooks are different from explainer hooks — they evoke **feeling**, not information gaps.
|
||||
|
||||
| Pattern | When to Use |
|
||||
|---------|-------------|
|
||||
| **Sensory** | "You hear it before you see it. A frequency that shouldn't exist." | When the mood is mystery/tension |
|
||||
| **Scale shift** | "In the time it takes to read this sentence, 4.7 million packets crossed the Atlantic." | When the concept involves scale |
|
||||
| **Intimate** | "She waters them at 6am. Before the city wakes. Before anyone watches." | When the mood is intimate/human |
|
||||
| **Provocation** | "They told us the message was noise. It wasn't." | When the concept involves a reveal |
|
||||
| **Contrast** | "Three blocks from Wall Street, on a rooftop covered in clover, 40,000 bees are building a city." | When the subject is surprising in context |
|
||||
|
||||
#### 3b: Emotional Arc
|
||||
|
||||
Every cinematic concept needs an explicit arc:
|
||||
|
||||
| Arc | Structure | Best For |
|
||||
|-----|-----------|----------|
|
||||
| `tension → reveal` | Build unease, then pay it off | Teasers, sci-fi, thriller |
|
||||
| `wonder → scale` | Start small, expand to massive | Nature, tech, cosmos |
|
||||
| `intimacy → payoff` | Close, personal, then earned moment | Documentary, human interest |
|
||||
| `urgency → resolution` | Fast pace to satisfying close | Product, action, launch |
|
||||
| `mystery → CTA` | Intrigue that leads to action | Brand films, campaigns |
|
||||
| `stillness → eruption` | Calm before powerful climax | Music videos, art films |
|
||||
|
||||
#### 3c: Delivery Promise
|
||||
|
||||
For cinematic, explicitly classify:
|
||||
|
||||
```yaml
|
||||
delivery_promise:
|
||||
promise_type: motion_led # or source_led, hybrid
|
||||
motion_required: true # false only if user approves still-led
|
||||
source_required: false # true if user has footage
|
||||
tone_mode: cinematic # cinematic, raw, intimate, epic
|
||||
quality_floor: presentable # draft, presentable, broadcast
|
||||
approved_fallback: null # animatic, still_led, or null (no fallback)
|
||||
```
|
||||
|
||||
**Rule:** `motion_led` forbids still-led fallback unless the user explicitly approves `animatic` as the fallback.
|
||||
|
||||
#### 3d: Visual Treatment
|
||||
|
||||
For each concept, define:
|
||||
- **Color palette** — specific hex references, not just "dark"
|
||||
- **Lighting approach** — high_key, low_key, natural, golden_hour, etc.
|
||||
- **Camera language** — dominant shot sizes, movements
|
||||
- **Texture** — film grain, clean digital, anamorphic, handheld
|
||||
- **Typography** — if title cards are used, their style and restraint level
|
||||
|
||||
#### 3e: Renderer Family Selection
|
||||
|
||||
Choose the renderer family and lock it in the proposal:
|
||||
|
||||
| Family | When | Composition |
|
||||
|--------|------|-------------|
|
||||
| `cinematic-trailer` | Trailers, teasers, brand films with generated/source video | CinematicRenderer |
|
||||
| `presenter` | Talking head with cinematic enhancement | TalkingHead |
|
||||
| `explainer-data` | Only if this is really an explainer that wants cinematic dressing | Explainer |
|
||||
|
||||
**Rule:** The renderer family is selected here and locked before scene planning. The compose stage cannot change it without logging a decision and surfacing the change to the user.
|
||||
|
||||
### Step 4: Progressive Reveal, Diversity Check, and Concept Selection
|
||||
|
||||
#### 4a: Progressive Reveal
|
||||
|
||||
Don't dump the full proposal at once. Build understanding step by step:
|
||||
|
||||
1. **Research summary** (2-3 sentences): "Here's what I found about the subject and its visual potential..."
|
||||
→ User reacts, course-corrects if needed.
|
||||
2. **Mood board** (from Step 2c — already presented)
|
||||
→ User confirms feel.
|
||||
3. **Concept directions** (3+ emotional/visual approaches):
|
||||
→ Present each concept's emotional hook, arc, and visual treatment.
|
||||
4. **Invite mixing** (see 4c below).
|
||||
5. **Production plan for selected direction** (tools, cost, renderer family):
|
||||
→ User approves budget and approach.
|
||||
|
||||
Each step is a chance for the user to course-correct before the next step builds on it.
|
||||
|
||||
#### 4b: Diversity Check
|
||||
|
||||
Before presenting concepts:
|
||||
- [ ] No two concepts share the same emotional arc
|
||||
- [ ] No two concepts use the same visual treatment
|
||||
- [ ] At least one concept takes a creative risk
|
||||
- [ ] Each concept's visual references are from different sources
|
||||
- [ ] Each concept is achievable with current capabilities (or states what's missing)
|
||||
|
||||
#### 4c: Invite Mixing
|
||||
|
||||
After presenting concepts, always say something like:
|
||||
> "You can also mix elements — for example, Concept A's emotional arc with Concept C's visual treatment and Concept B's music direction. What speaks to you?"
|
||||
|
||||
If the user mixes, create a new hybrid concept entry in the proposal_packet with clear attribution: "Emotional arc from Concept A, visual treatment from Concept C, music direction from Concept B."
|
||||
|
||||
Let the user select, combine, modify, or redirect entirely.
|
||||
|
||||
### Step 5: Music Plan (Mandatory for Cinematic)
|
||||
|
||||
Cinematic videos live and die by their audio. Surface the music situation before the user approves.
|
||||
|
||||
Check availability in this order:
|
||||
1. **User music library (`music_library/`)** — list available tracks
|
||||
2. **Music generation APIs** — report status, cost, and quality honestly
|
||||
3. **Bring-your-own path** — user can drop a track in `music_library/`
|
||||
|
||||
Present explicit options:
|
||||
```
|
||||
MUSIC PLAN
|
||||
├── Your music library: [N tracks / empty]
|
||||
├── AI generation: [provider] — [AVAILABLE/UNAVAILABLE] [cost]
|
||||
└── Bring your own: Drop a track in music_library/ before asset stage
|
||||
|
||||
Recommendation: [specific recommendation based on mood research]
|
||||
```
|
||||
|
||||
### Step 6: Build Production Plan
|
||||
|
||||
For the selected concept, design the stage-by-stage plan with specific providers, costs, and honest tradeoffs.
|
||||
|
||||
**Cinematic-specific tool priorities:**
|
||||
- **Color grade** — high priority. Cinematic output without grade looks flat.
|
||||
- **Audio enhance** — high priority. Audio dynamics matter more in mood-driven work.
|
||||
- **Video generation** — if motion-required, this is non-negotiable.
|
||||
- **Music** — must be resolved. No cinematic piece should have silence as a surprise.
|
||||
|
||||
### Step 7: Cost Estimate
|
||||
|
||||
Itemize all costs honestly. Cinematic tends to be more expensive than explainer (more generated clips, music, grade passes).
|
||||
|
||||
### Step 8: Present and Approve
|
||||
|
||||
Present concepts clearly. Invite the user to:
|
||||
- Select one as-is
|
||||
- Mix elements from multiple concepts
|
||||
- Request modifications
|
||||
- Redirect entirely
|
||||
|
||||
Set `approval.status: "pending"`. Pipeline does NOT proceed without approval.
|
||||
|
||||
### Step 9: Submit
|
||||
|
||||
Validate `proposal_packet` against schema and submit.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- **Calling it cinematic because of black bars**: Letterboxing is not cinematography. The treatment must include shot language, lighting, movement, and emotional arc.
|
||||
- **Hiding motion downgrade**: If motion-required content will actually be still images with Ken Burns, say so explicitly.
|
||||
- **Music as afterthought**: In cinematic work, music is 50% of the mood. Surface it early.
|
||||
- **Three versions of "dark and moody"**: Three concepts with the same emotional register but different titles are one concept. Diversity means different arcs, different moods, different risks.
|
||||
- **Ignoring source reality**: If the user has no footage and limited generation tools, the proposal must reflect that — not pretend the constraints don't exist.
|
||||
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
@@ -9,7 +9,7 @@ Package the cinematic piece and any cutdowns so the hero version stays clear and
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Schema | `schemas/artifacts/publish_log.schema.json` | Artifact validation |
|
||||
| Prior artifacts | `state.artifacts["compose"]["render_report"]`, `state.artifacts["idea"]["brief"]`, `state.artifacts["script"]["script"]` | Final outputs and beat map |
|
||||
| Prior artifacts | `state.artifacts["compose"]["render_report"]`, `state.artifacts["proposal"]["proposal_packet"]`, `state.artifacts["research"]["research_brief"]`, `state.artifacts["script"]["script"]` | Final outputs and beat map |
|
||||
| Playbook | Active style playbook | Tone and naming consistency |
|
||||
|
||||
## Process
|
||||
|
||||
@@ -0,0 +1,172 @@
|
||||
# Research Director — Cinematic Pipeline
|
||||
|
||||
## When to Use
|
||||
|
||||
You are the **Research Director** for a cinematic video (trailers, brand films, dramatic montages, mood-led edits). Your job is to deeply research the subject to ground the cinematic direction in real references, real moods, and real audience expectations — before any creative decisions or money is spent.
|
||||
|
||||
Unlike explainer research (which focuses on facts, data, and content gaps), cinematic research focuses on **visual references, emotional language, sound design direction, and motion precedents.** The goal is to arm the Proposal Director with enough material to present mood boards and concept directions that feel intentional, not generic.
|
||||
|
||||
**You do NOT make creative decisions.** You gather raw material. The Proposal Director will use your findings to craft concept directions.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Schema | `schemas/artifacts/research_brief.schema.json` | Artifact validation |
|
||||
| User input | Subject, mood hints, footage situation, references | Research scope |
|
||||
| Tools | Web search, web fetch | Research execution |
|
||||
|
||||
## Process
|
||||
|
||||
### Step 1: Classify the Brief
|
||||
|
||||
Before searching, extract from the user's request:
|
||||
|
||||
- **Subject**: What is this video about?
|
||||
- **Source reality**: Does the user have footage, stills, audio, or nothing?
|
||||
- **Motion requirement**: Is motion a hard requirement (trailer, teaser, hype reel) or can it be still-led?
|
||||
- **Mood hints**: Any emotional direction given? ("dark", "epic", "intimate", "raw", "hopeful")
|
||||
- **Platform**: Where will this live?
|
||||
- **Duration hint**: Short (15-30s), medium (30-90s), long (90s+)?
|
||||
|
||||
### Step 2: Visual Reference Mining
|
||||
|
||||
**Goal:** Find real cinematic precedents that match the mood and subject.
|
||||
|
||||
```
|
||||
SEARCH BATCH 1 — Visual References (run all in parallel)
|
||||
|
||||
Q1: "[subject] cinematic [mood hint]" site:youtube.com
|
||||
→ Find: Existing trailers, brand films, or mood pieces for this subject.
|
||||
|
||||
Q2: "[subject] [delivery shape] visual style" (breakdown OR making-of OR tutorial)
|
||||
→ Find: How professionals approach this type of visual storytelling.
|
||||
|
||||
Q3: "[mood hint] color palette cinematography" OR "[mood hint] color grading reference"
|
||||
→ Find: Color and grade references that match the intended mood.
|
||||
|
||||
Q4: "[subject] [mood hint]" (short film OR brand film OR trailer) award OR festival
|
||||
→ Find: Award-quality references — the ceiling of what this could look like.
|
||||
```
|
||||
|
||||
**For each reference, record:**
|
||||
- Title and URL
|
||||
- What works visually (framing, color, movement, texture)
|
||||
- What works emotionally (pacing, reveal structure, tension arc)
|
||||
- Relevance to the user's brief
|
||||
|
||||
### Step 3: Sound and Music Landscape
|
||||
|
||||
**Goal:** Understand the audio palette for this mood.
|
||||
|
||||
```
|
||||
SEARCH BATCH 2 — Audio References (run in parallel)
|
||||
|
||||
Q5: "[mood hint] [subject] soundtrack" OR "[mood hint] film score reference"
|
||||
→ Find: Music mood references.
|
||||
|
||||
Q6: "[mood hint] sound design" (cinematic OR film OR trailer)
|
||||
→ Find: Sound design approaches — ambient, textural, percussive, silent.
|
||||
```
|
||||
|
||||
**Record:**
|
||||
- Music mood direction (not specific tracks — the energy and texture)
|
||||
- Sound design notes (atmospheric, minimal, industrial, organic)
|
||||
- Whether dialogue or narration is expected or if the piece is music-driven
|
||||
|
||||
### Step 4: Subject-Specific Research
|
||||
|
||||
**Goal:** Gather factual or contextual depth that grounds the visual choices.
|
||||
|
||||
```
|
||||
SEARCH BATCH 3 — Subject Depth (run in parallel)
|
||||
|
||||
Q7: "[subject]" (story OR history OR origin OR significance)
|
||||
→ Find: Narrative depth that can inform visual decisions.
|
||||
|
||||
Q8: "[subject]" (visual OR texture OR detail OR close-up OR macro)
|
||||
→ Find: Texture and material references for the subject.
|
||||
|
||||
Q9: "[subject]" "[current year]" (trend OR development OR news)
|
||||
→ Find: Current relevance — is there a timeliness angle?
|
||||
```
|
||||
|
||||
### Step 5: Motion and Camera Language Research
|
||||
|
||||
**Goal:** Find specific cinematic techniques that suit this mood.
|
||||
|
||||
```
|
||||
SEARCH BATCH 4 — Technique Research (run in parallel)
|
||||
|
||||
Q10: "[mood hint] camera movement" (technique OR cinematography)
|
||||
→ Find: Which camera movements suit this mood (handheld for raw, steadicam for contemplative, whip pans for energy).
|
||||
|
||||
Q11: "[mood hint] editing rhythm" OR "[mood hint] pacing" (film OR trailer)
|
||||
→ Find: Editing tempo references.
|
||||
|
||||
Q12: "[delivery shape] structure" (beat sheet OR pacing OR breakdown)
|
||||
→ Find: Structural templates for this delivery type.
|
||||
```
|
||||
|
||||
### Step 6: Audience and Distribution Context
|
||||
|
||||
```
|
||||
SEARCH BATCH 5 — Audience (run in parallel)
|
||||
|
||||
Q13: "[subject] [platform]" (best OR viral OR most watched)
|
||||
→ Find: What performs well on the target platform for this subject.
|
||||
|
||||
Q14: "[subject]" site:reddit.com (mood OR aesthetic OR vibe)
|
||||
→ Find: How the community talks about and feels about this subject.
|
||||
```
|
||||
|
||||
### Step 7: Angle Synthesis
|
||||
|
||||
Using everything from Steps 2-6, identify at least 3 genuinely different cinematic directions:
|
||||
|
||||
For each direction, specify:
|
||||
|
||||
| Field | What | Quality Bar |
|
||||
|-------|------|-------------|
|
||||
| `name` | Short direction title (5-8 words) | Specific mood, not just the subject |
|
||||
| `hook` | One-sentence emotional pitch | Must evoke a feeling, not explain |
|
||||
| `type` | `mood_piece`, `tension_arc`, `reveal`, `intimate`, `epic`, `raw` | Categorize honestly |
|
||||
| `visual_references` | Which found references inform this direction | Specific URLs and descriptions |
|
||||
| `audio_direction` | Music mood, sound design approach | Informed by Step 3 findings |
|
||||
| `motion_commitment` | What motion is required and how it'll be achieved | Honest about capabilities |
|
||||
| `grounded_in` | Which research findings support this direction | Cross-reference your findings |
|
||||
|
||||
**Direction diversity checklist:**
|
||||
- [ ] At least one direction uses a different emotional arc than the others
|
||||
- [ ] At least one direction emphasizes texture/intimacy over spectacle
|
||||
- [ ] No two directions use the same primary camera approach
|
||||
- [ ] Each direction is grounded in different visual references
|
||||
|
||||
### Step 8: Source Bibliography
|
||||
|
||||
Compile all URLs used. Minimum 5 sources.
|
||||
|
||||
### Step 9: Assemble and Submit
|
||||
|
||||
Build the `research_brief` artifact per the schema. Include:
|
||||
|
||||
1. `research_summary` — one paragraph capturing the strongest creative direction found
|
||||
2. All sections from Steps 2-8
|
||||
|
||||
Validate against `schemas/artifacts/research_brief.schema.json` before submitting.
|
||||
|
||||
## Execution Constraints
|
||||
|
||||
| Constraint | Value | Why |
|
||||
|------------|-------|-----|
|
||||
| Max time on research | 3-5 minutes | Research is valuable but has diminishing returns |
|
||||
| Max searches | 20 | Prevent infinite rabbit holes |
|
||||
| Min searches | 8 | Ensure adequate coverage |
|
||||
| No paid tools | — | Research uses web search only — zero cost |
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- **Searching only for "cinematic"**: The word is overused. Search for the specific mood, texture, and subject instead.
|
||||
- **Ignoring the source reality**: If the user has no footage and no video generation, the research should account for still-led approaches — not ignore the constraint.
|
||||
- **Generic mood words**: "Dark and moody" is not a direction. "Low-key tungsten lighting with shallow depth of field, inspired by Fincher's title sequences" is a direction.
|
||||
- **Skipping audio research**: Cinematic videos live and die by their audio. The mood board is incomplete without sound direction.
|
||||
@@ -9,7 +9,7 @@ You are deciding how each cinematic beat will look and transition. This is where
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Schema | `schemas/artifacts/scene_plan.schema.json` | Artifact validation |
|
||||
| Prior artifacts | `state.artifacts["script"]["script"]`, `state.artifacts["idea"]["brief"]` | Beat map and source truth |
|
||||
| Prior artifacts | `state.artifacts["script"]["script"]`, `state.artifacts["proposal"]["proposal_packet"]` | Beat map and source truth |
|
||||
| Tools | `frame_sampler`, `scene_detect` | Source inspection and reframing checks |
|
||||
| Playbook | Active style playbook | Color and typography consistency |
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ This stage builds the beat map, selected lines, title-card copy, and reveal stru
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Schema | `schemas/artifacts/script.schema.json` | Artifact validation |
|
||||
| Prior artifact | `state.artifacts["idea"]["brief"]` | Emotional arc and source truth |
|
||||
| Prior artifact | `state.artifacts["proposal"]["proposal_packet"]` | Emotional arc and source truth |
|
||||
| Tools | `transcriber`, `scene_detect` | Optional dialogue mining and source review |
|
||||
|
||||
## Process
|
||||
@@ -62,6 +62,17 @@ Recommended metadata keys:
|
||||
- the reveal lands distinctly,
|
||||
- the landing gives the viewer a final feeling or action.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during script writing:
|
||||
- Use `web_search` to verify factual claims before committing them to the script
|
||||
- Use `web_search` to find reference images for visual accuracy
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Every factual claim in the script should be traceable to the `research_brief`.
|
||||
If you make a claim that isn't in the research, do additional research and
|
||||
add the source. Do not invent statistics, dates, or attributions.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Writing full explanatory paragraphs instead of beats.
|
||||
|
||||
@@ -25,6 +25,16 @@ Prefer reusable assets over per-clip reinvention:
|
||||
- one watermark / brand frame,
|
||||
- one CTA / end-tag treatment if needed.
|
||||
|
||||
### 1b. Hero Scene Sample (Mandatory)
|
||||
|
||||
Before batch asset generation:
|
||||
1. Identify the hero scene (the visual peak of the batch)
|
||||
2. Generate ONE sample visual asset for that scene
|
||||
3. Present it: "This is the visual direction for the most important clip. Does this match what you're imagining? I'll generate the rest in this style."
|
||||
4. Wait for approval before proceeding to batch generation
|
||||
|
||||
This prevents the most expensive mistake: generating 10+ assets in a direction the user doesn't like.
|
||||
|
||||
### 2. Generate Per-Clip Subtitles
|
||||
|
||||
Each approved clip needs its own subtitle asset, timed from clip start rather than source start. This timestamp rebasing is critical.
|
||||
@@ -60,9 +70,39 @@ Recommended metadata keys:
|
||||
- shared assets are referenced consistently,
|
||||
- the asset count stays practical for the batch size.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during asset generation:
|
||||
- Use `web_search` to verify visual accuracy of subjects (e.g. what does this building actually look like?)
|
||||
- Use `web_search` to find reference images before generating illustrations
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Visual accuracy matters. If the script mentions a specific place, person, or object,
|
||||
verify what it actually looks like before generating images. Don't rely on
|
||||
the AI model's training data — it may be wrong or outdated.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Forgetting to rebase subtitle timing per clip.
|
||||
- Overdesigning hook assets so the batch becomes inconsistent.
|
||||
- Normalizing some clips and not others.
|
||||
- Treating a 10-clip batch like 10 unrelated projects.
|
||||
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
|
||||
@@ -82,6 +82,17 @@ Each candidate should record:
|
||||
- the set covers the source deliberately instead of clustering in one section,
|
||||
- low-quality candidates are rejected honestly.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during script writing:
|
||||
- Use `web_search` to verify factual claims before committing them to the script
|
||||
- Use `web_search` to find reference images for visual accuracy
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Every factual claim in the script should be traceable to the `research_brief`.
|
||||
If you make a claim that isn't in the research, do additional research and
|
||||
add the source. Do not invent statistics, dates, or attributions.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Trusting first-pass candidate timestamps without transcript-level review.
|
||||
|
||||
@@ -11,7 +11,7 @@ This is where plans become real files. A missing or low-quality asset will torpe
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Schema | `schemas/artifacts/asset_manifest.schema.json` | Artifact validation |
|
||||
| Prior artifacts | `state.artifacts["scene_plan"]["scene_plan"]`, `state.artifacts["script"]["script"]`, `state.artifacts["idea"]["brief"]` | What to produce |
|
||||
| Prior artifacts | `state.artifacts["scene_plan"]["scene_plan"]`, `state.artifacts["script"]["script"]`, `state.artifacts["proposal"]["proposal_packet"]` | What to produce |
|
||||
| Playbook | Active style playbook | Image prompts, diagram style, audio preferences |
|
||||
| Tools | `tts_selector`, `image_selector`, `video_selector`, `diagram_gen`, `code_snippet`, `music_gen` — selectors auto-discover all available providers from the registry | Generation capabilities |
|
||||
| Cost tracker | `tools/cost_tracker.py` | Budget governance |
|
||||
@@ -188,6 +188,17 @@ If any dimension scores below 3, fix before proceeding.
|
||||
|
||||
Validate the asset_manifest against the schema and persist via checkpoint.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during asset generation:
|
||||
- Use `web_search` to verify visual accuracy of subjects (e.g. what does this building actually look like?)
|
||||
- Use `web_search` to find reference images before generating illustrations
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Visual accuracy matters. If the script mentions a specific place, person, or object,
|
||||
verify what it actually looks like before generating images. Don't rely on
|
||||
the AI model's training data — it may be wrong or outdated.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- **Generating before checking budget**: Always estimate total cost first. A 60-second video with 15 images can burn $3+ quickly.
|
||||
@@ -195,3 +206,22 @@ Validate the asset_manifest against the schema and persist via checkpoint.
|
||||
- **Ignoring narration timing**: If TTS produces 12s of audio for a 10s section, the edit phase will struggle. Check durations.
|
||||
- **Missing pronunciation guide**: "PostgreSQL" or "Kubernetes" will be mispronounced without explicit guidance.
|
||||
- **One retry then give up**: If an image doesn't match, refine the prompt specifically — don't just retry the same prompt.
|
||||
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
|
||||
@@ -58,6 +58,21 @@ This directly affects what you can promise in the production plan. **Do not prop
|
||||
|
||||
**Setup offers:** If critical tools are UNAVAILABLE but fixable with a simple configuration, read each tool's `install_instructions` from the registry and offer the user setup help before designing around the limitation. See AGENT_GUIDE.md "Provider Menu" protocol for the approach. Group related tools that share the same env var dependency.
|
||||
|
||||
### Step 2c: Mood Board (Before Concepts)
|
||||
|
||||
Before developing full concepts, present a quick mood board to catch direction mismatches early:
|
||||
|
||||
- **3-5 reference images** (from web search, stock, or quick generations)
|
||||
- **Color palette direction** (2-3 options derived from playbook candidates)
|
||||
- **Tone references** ("Think: Kurzgesagt meets Vice" or "Think: Apple product video meets TED-Ed")
|
||||
- **1-2 music mood references** (genre + energy level, not specific tracks)
|
||||
|
||||
Ask: **"Does this FEEL like what you're imagining? Any of these off-track?"**
|
||||
|
||||
This is cheaper than generating 3 full concepts and catches direction mismatches before they become expensive. If the user says "too corporate" or "more playful," you've saved an entire concept round.
|
||||
|
||||
If the user confirms the direction, proceed. If they redirect, adjust your concept design to match.
|
||||
|
||||
### Step 3: Design Concept Options
|
||||
|
||||
Build **at least 3 genuinely different concepts.** Start from the `angles_discovered` in the research brief, but elevate them into full production concepts.
|
||||
@@ -137,32 +152,89 @@ Set realistic duration based on platform and content depth:
|
||||
| YouTube | 60-180s | 150-450 words |
|
||||
| LinkedIn | 60-120s | 150-300 words |
|
||||
|
||||
#### 3e: Concept Diversity Check
|
||||
#### 3e: When to Break the Patterns
|
||||
|
||||
Before finalizing, verify diversity:
|
||||
The hook patterns and narrative structures above are starting points, not templates. Here are signs you should invent something new:
|
||||
|
||||
**Signs your concepts are cosmetically diverse but conceptually identical:**
|
||||
- All three hooks create the same type of curiosity gap
|
||||
- Swapping the hooks between concepts would barely change anything
|
||||
- All three would produce roughly the same script if you wrote them blind
|
||||
- The visual approaches are "dark vs light vs colorful" but the content structure is identical
|
||||
|
||||
**Anti-formula rule:** Write the hook in your own words first. Then check if a pattern helps sharpen it. If you start FROM the pattern, you'll produce pattern-shaped content instead of research-shaped content.
|
||||
|
||||
**When to deviate from the 6 hook templates:**
|
||||
- The research reveals a unique framing that doesn't fit any template
|
||||
- The audience is sophisticated enough that template hooks feel condescending
|
||||
- The topic's best angle is emotional rather than informational
|
||||
- You found a specific quote, anecdote, or event that IS the hook
|
||||
|
||||
#### 3f: Concept Diversity Gate
|
||||
|
||||
This is two checks, not one:
|
||||
|
||||
**Structural diversity (necessary but not sufficient):**
|
||||
- [ ] No two concepts use the same narrative structure
|
||||
- [ ] No two concepts use the same hook pattern
|
||||
- [ ] At least one concept targets a different audience segment
|
||||
- [ ] At least one concept leverages the most surprising data point
|
||||
- [ ] At least one concept addresses the biggest content gap found
|
||||
- [ ] Each concept's `grounded_in` references different research findings
|
||||
|
||||
### Step 4: Present Concepts and Get Selection
|
||||
**Conceptual diversity (the actual test):**
|
||||
- [ ] Each concept offers a genuinely different INSIGHT, not just a different title for the same insight
|
||||
- [ ] At least one concept takes a creative risk (unusual structure, unexpected angle, provocative framing)
|
||||
- [ ] If you removed the titles and hooks, the concepts would still be distinguishable by their content structure
|
||||
- [ ] The concepts are NOT interchangeable — each serves a different audience need or curiosity
|
||||
|
||||
Present all concepts clearly to the user. For each concept, show:
|
||||
If your concepts fail the conceptual diversity test, go back to the research brief. The problem is usually that you're working from one angle and varying the surface, instead of working from different angles entirely.
|
||||
|
||||
#### 3g: Playbook Violation Budget
|
||||
|
||||
Up to 20% of scenes in the final video may intentionally deviate from the playbook for creative impact. When presenting concepts, note which moments might benefit from visual surprise (a color shift, a different typography treatment, an unexpected transition). These deviations must be logged as `playbook_override` decisions in the decision log.
|
||||
|
||||
#### 3h: Voice Selection
|
||||
|
||||
Surface the voice/TTS decision at proposal time:
|
||||
- What voice provider and voice ID will be used
|
||||
- Why this voice fits the concept's tone
|
||||
- Cost implications
|
||||
- Whether voice variation is appropriate for hero moments
|
||||
|
||||
### Step 4: Progressive Reveal and Concept Selection
|
||||
|
||||
Don't dump the full proposal at once. Build understanding step by step:
|
||||
|
||||
**4a. Research summary** (2-3 sentences): "Here's what I found..."
|
||||
→ User reacts, course-corrects if needed.
|
||||
|
||||
**4b. Mood board** (from Step 2c — already presented)
|
||||
→ User confirms feel.
|
||||
|
||||
**4c. Concept options** (3+ directions):
|
||||
|
||||
For each concept, show:
|
||||
1. **Title** and **hook** — the creative pitch
|
||||
2. **Why this works** — the research backing, in one sentence
|
||||
3. **What it'll look like** — visual approach in plain language
|
||||
4. **Duration** — how long the video will be
|
||||
|
||||
**4d. Invite Mixing:**
|
||||
|
||||
After presenting concepts, always say something like:
|
||||
> "You can also mix elements — for example, Concept A's hook with Concept C's visual approach. What speaks to you?"
|
||||
|
||||
If the user mixes, create a new hybrid concept entry in the proposal_packet with clear attribution: "Hook from Concept A, visual approach from Concept C, narrative structure from Concept B."
|
||||
|
||||
Let the user:
|
||||
- Select one as-is
|
||||
- Combine elements from multiple concepts
|
||||
- Combine elements from multiple concepts (hybrid)
|
||||
- Request modifications
|
||||
- Describe a completely different direction (in which case, use the research to strengthen it)
|
||||
|
||||
**4e. Production plan for selected concept** (tools, cost, timeline):
|
||||
→ User approves budget and approach.
|
||||
|
||||
Each step is a chance for the user to course-correct before the next step builds on it. This prevents the "I approved a proposal and then the video wasn't what I expected" failure mode.
|
||||
|
||||
Record the selection in `selected_concept` with rationale and any modifications.
|
||||
|
||||
### Step 5: Build the Production Plan
|
||||
@@ -378,3 +450,22 @@ TOTAL: $0.64 of $2.00 budget
|
||||
- Premium (Remotion): Best available TTS + 4 AI images + 4 Remotion animated scenes = $0.48
|
||||
- Standard: Mid-tier TTS + images = $0.40
|
||||
- Free: Local TTS + Remotion component scenes only = $0.00 (no images, pure motion graphics)
|
||||
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
|
||||
@@ -11,7 +11,7 @@ This is where a great video reaches its audience. Without proper metadata and pa
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Schema | `schemas/artifacts/publish_log.schema.json` | Artifact validation |
|
||||
| Prior artifacts | `state.artifacts["compose"]["render_report"]`, `state.artifacts["idea"]["brief"]` | Video file and original brief |
|
||||
| Prior artifacts | `state.artifacts["compose"]["render_report"]`, `state.artifacts["proposal"]["proposal_packet"]`, `state.artifacts["research"]["research_brief"]` | Video file and original proposal |
|
||||
| Playbook | Active style playbook | Visual style for thumbnail |
|
||||
|
||||
## Process
|
||||
@@ -19,14 +19,14 @@ This is where a great video reaches its audience. Without proper metadata and pa
|
||||
### Step 1: Gather Context
|
||||
|
||||
Collect everything needed for metadata:
|
||||
- **Brief**: title, hook, key points, target platform, tone
|
||||
- **Proposal packet**: title, hook, key points, target platform, tone
|
||||
- **Render report**: output path, duration, resolution
|
||||
- **Script**: section summaries for description/chapters
|
||||
|
||||
### Step 2: Generate SEO Metadata
|
||||
|
||||
**Title** (max 60 characters for YouTube):
|
||||
- Include the primary keyword from the brief
|
||||
- Include the primary keyword from the proposal packet
|
||||
- Lead with a hook or number
|
||||
- Avoid clickbait but be compelling
|
||||
- Examples: "Vector Databases Explained in 60 Seconds" > "About Vector Databases"
|
||||
@@ -39,7 +39,7 @@ Collect everything needed for metadata:
|
||||
- Links: relevant resources mentioned in the video
|
||||
|
||||
**Tags/Keywords** (platform-dependent):
|
||||
- 5-10 specific tags derived from brief's key_points
|
||||
- 5-10 specific tags derived from proposal packet's key_points
|
||||
- Mix broad and specific: "machine learning" + "vector database tutorial"
|
||||
- Include the topic, format ("explainer"), and related terms
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ This is where words become visuals. A great script with a bad scene plan produce
|
||||
| Layer | Resource | Purpose |
|
||||
|-------|----------|---------|
|
||||
| Schema | `schemas/artifacts/scene_plan.schema.json` | Artifact validation |
|
||||
| Prior artifacts | `state.artifacts["script"]["script"]`, `state.artifacts["idea"]["brief"]` | Script sections and creative brief |
|
||||
| Prior artifacts | `state.artifacts["script"]["script"]`, `state.artifacts["proposal"]["proposal_packet"]` | Script sections and proposal packet |
|
||||
| Playbook | Active style playbook | Visual language, transitions, motion rules |
|
||||
| Layer 3 | `.agents/skills/flux-best-practices/`, `.agents/skills/beautiful-mermaid/`, `.agents/skills/manim-composer/` | Image gen, diagram, animation knowledge |
|
||||
|
||||
|
||||
@@ -185,6 +185,17 @@ If any dimension scores below 3, revise before submitting.
|
||||
|
||||
Call `handle_explainer_script(state, {"script": script_json})` to validate and persist.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during script writing:
|
||||
- Use `web_search` to verify factual claims before committing them to the script
|
||||
- Use `web_search` to find reference images for visual accuracy
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Every factual claim in the script should be traceable to the `research_brief`.
|
||||
If you make a claim that isn't in the research, do additional research and
|
||||
add the source. Do not invent statistics, dates, or attributions.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- **Writing too many words**: The #1 failure. TTS pacing is fixed. If you write 250 words for a 60-second video, either the audio will be rushed or the video will be 100 seconds. Count your words.
|
||||
|
||||
@@ -63,8 +63,38 @@ Recommended metadata keys:
|
||||
- source and generated assets are clearly separated,
|
||||
- every referenced file exists.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during asset generation:
|
||||
- Use `web_search` to verify visual accuracy of subjects (e.g. what does this building actually look like?)
|
||||
- Use `web_search` to find reference images before generating illustrations
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Visual accuracy matters. If the script mentions a specific place, person, or object,
|
||||
verify what it actually looks like before generating images. Don't rely on
|
||||
the AI model's training data — it may be wrong or outdated.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Overbuilding support assets before the anchor cut is proven.
|
||||
- Losing track of which assets are generated versus supplied.
|
||||
- Creating inconsistent overlay systems across one project.
|
||||
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
|
||||
@@ -52,6 +52,17 @@ Recommended metadata keys:
|
||||
- the script does not depend on fake or unavailable assets without saying so,
|
||||
- the structure can produce the intended deliverables.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during script writing:
|
||||
- Use `web_search` to verify factual claims before committing them to the script
|
||||
- Use `web_search` to find reference images for visual accuracy
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Every factual claim in the script should be traceable to the `research_brief`.
|
||||
If you make a claim that isn't in the research, do additional research and
|
||||
add the source. Do not invent statistics, dates, or attributions.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Rewriting strong source dialogue into weaker narration.
|
||||
|
||||
@@ -19,6 +19,16 @@ This stage produces the localized asset kit: translated subtitle files, dubbed a
|
||||
|
||||
Create the subtitle or caption package for each language. This gives a reviewable fallback even if dubbed-audio generation or lip sync is blocked.
|
||||
|
||||
### 1b. Hero Scene Sample (Mandatory)
|
||||
|
||||
Before batch asset generation:
|
||||
1. Identify the hero scene (the visual peak of the video)
|
||||
2. Generate ONE sample dubbed audio clip for that scene in the target language
|
||||
3. Present it: "This is the voice direction for the most important scene. Does this match what you're imagining? I'll generate the rest in this style."
|
||||
4. Wait for approval before proceeding to batch generation
|
||||
|
||||
This prevents the most expensive mistake: generating 10+ dubbed assets in a direction the user doesn't like.
|
||||
|
||||
### 2. Generate Dubbed Audio Per Language
|
||||
|
||||
Use the approved translated script package, not raw machine output. Record which voice or synthesis path was used for each language.
|
||||
@@ -45,8 +55,38 @@ Recommended metadata keys:
|
||||
- lip-sync remains explicitly optional,
|
||||
- every referenced file exists.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during asset generation:
|
||||
- Use `web_search` to verify visual accuracy of subjects (e.g. what does this building actually look like?)
|
||||
- Use `web_search` to find reference images before generating illustrations
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Visual accuracy matters. If the script mentions a specific place, person, or object,
|
||||
verify what it actually looks like before generating images. Don't rely on
|
||||
the AI model's training data — it may be wrong or outdated.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Generating dubbed audio before finalizing translation review.
|
||||
- Treating lip sync as mandatory for every language.
|
||||
- Failing to record which language asset maps to which voice and subtitle set.
|
||||
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
|
||||
@@ -47,6 +47,17 @@ Recommended metadata keys:
|
||||
- glossary terms are preserved,
|
||||
- the script package can be reviewed before audio generation.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during script writing:
|
||||
- Use `web_search` to verify factual claims before committing them to the script
|
||||
- Use `web_search` to find reference images for visual accuracy
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Every factual claim in the script should be traceable to the `research_brief`.
|
||||
If you make a claim that isn't in the research, do additional research and
|
||||
add the source. Do not invent statistics, dates, or attributions.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Generating audio from an unreviewed transcript.
|
||||
|
||||
@@ -24,6 +24,16 @@ Highest priority:
|
||||
- speaker attribution assets if multiple speakers appear,
|
||||
- quote-card templates for quote-led outputs.
|
||||
|
||||
### 1b. Hero Scene Sample (Mandatory)
|
||||
|
||||
Before batch asset generation:
|
||||
1. Identify the hero clip (the most important or impactful clip in the batch)
|
||||
2. Generate ONE sample asset for that clip (subtitle style, speaker card, or quote card)
|
||||
3. Present it: "This is the visual direction for the most important clip. Does this match what you're imagining? I'll generate the rest in this style."
|
||||
4. Wait for approval before proceeding to batch generation
|
||||
|
||||
This prevents the most expensive mistake: generating 10+ assets in a direction the user doesn't like.
|
||||
|
||||
### 2. Treat Topic Graphics As Optional
|
||||
|
||||
Generated graphics should support the batch, not dominate it. Use them only when:
|
||||
@@ -58,8 +68,38 @@ Recommended metadata keys:
|
||||
- quote-card text remains mobile-readable,
|
||||
- optional generated art stays within budget and style constraints.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during asset generation:
|
||||
- Use `web_search` to verify visual accuracy of subjects (e.g. what does this building actually look like?)
|
||||
- Use `web_search` to find reference images before generating illustrations
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Visual accuracy matters. If the script mentions a specific place, person, or object,
|
||||
verify what it actually looks like before generating images. Don't rely on
|
||||
the AI model's training data — it may be wrong or outdated.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Spending budget on optional art before subtitles and attribution assets are complete.
|
||||
- Creating inconsistent speaker cards across the same episode.
|
||||
- Overproducing topic graphics for long-form companion videos.
|
||||
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
|
||||
@@ -63,6 +63,17 @@ Use `sections[]` for the structured production-facing segments and put the riche
|
||||
- weak clips are rejected instead of padded,
|
||||
- chapter markers cover the long-form conversation cleanly.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during script writing:
|
||||
- Use `web_search` to verify factual claims before committing them to the script
|
||||
- Use `web_search` to find reference images for visual accuracy
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Every factual claim in the script should be traceable to the `research_brief`.
|
||||
If you make a claim that isn't in the research, do additional research and
|
||||
add the source. Do not invent statistics, dates, or attributions.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Treating diarization errors as minor when they change who said the quote.
|
||||
|
||||
@@ -25,6 +25,16 @@ Screen demos do not need a large asset pile. They need the right few assets:
|
||||
- optional: one intro card, one outro card, sparse diagram overlays
|
||||
- optional only if preflight allows it: generated narration for silent recordings
|
||||
|
||||
### 1b. Hero Scene Sample (Mandatory)
|
||||
|
||||
Before batch asset generation:
|
||||
1. Identify the hero scene (the most important step or interaction in the demo)
|
||||
2. Generate ONE sample asset for that scene (subtitle style, highlight overlay, or intro card)
|
||||
3. Present it: "This is the visual direction for the most important step. Does this match what you're imagining? I'll generate the rest in this style."
|
||||
4. Wait for approval before proceeding to batch generation
|
||||
|
||||
This prevents the most expensive mistake: generating 10+ assets in a direction the user doesn't like.
|
||||
|
||||
### 2. Generate Subtitles First
|
||||
|
||||
Rules:
|
||||
@@ -101,9 +111,39 @@ Use `asset_manifest.metadata` for details like:
|
||||
- [ ] Callout colors have sufficient contrast
|
||||
- [ ] Blur masks fully cover the sensitive content
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during asset generation:
|
||||
- Use `web_search` to verify visual accuracy of subjects (e.g. what does this building actually look like?)
|
||||
- Use `web_search` to find reference images before generating illustrations
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Visual accuracy matters. If the script mentions a specific place, person, or object,
|
||||
verify what it actually looks like before generating images. Don't rely on
|
||||
the AI model's training data — it may be wrong or outdated.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Generating too many one-off overlay files instead of a reusable kit.
|
||||
- Using subtitles that sit directly on top of terminal output or bottom navigation.
|
||||
- Assuming silent recordings will magically gain narration without checking TTS.
|
||||
- Spending image generation budget on visuals the raw screen already provides.
|
||||
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
|
||||
@@ -108,6 +108,17 @@ Recommended `script.metadata` fields:
|
||||
| **Technical accuracy** | Are all software names, commands, and UI elements named correctly? |
|
||||
| **Word economy** | Is narration concise and procedural? |
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during script writing:
|
||||
- Use `web_search` to verify factual claims before committing them to the script
|
||||
- Use `web_search` to find reference images for visual accuracy
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Every factual claim in the script should be traceable to the `research_brief`.
|
||||
If you make a claim that isn't in the research, do additional research and
|
||||
add the source. Do not invent statistics, dates, or attributions.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Narrating the cursor instead of the outcome.
|
||||
|
||||
@@ -16,6 +16,16 @@ You have a scene plan and script. Your job is to generate the supporting assets
|
||||
|
||||
## Process
|
||||
|
||||
### Step 0: Hero Scene Sample (Mandatory)
|
||||
|
||||
Before batch asset generation:
|
||||
1. Identify the hero scene (the visual peak of the video)
|
||||
2. Generate ONE sample asset for that scene (subtitle style, overlay, or background)
|
||||
3. Present it: "This is the visual direction for the most important scene. Does this match what you're imagining? I'll generate the rest in this style."
|
||||
4. Wait for approval before proceeding to batch generation
|
||||
|
||||
This prevents the most expensive mistake: generating 10+ assets in a direction the user doesn't like.
|
||||
|
||||
### Step 1: Generate Subtitles
|
||||
|
||||
Use the transcription data from the script stage to create:
|
||||
@@ -167,3 +177,32 @@ Document all generated assets with paths, types, and tool references:
|
||||
### Step 7: Submit
|
||||
|
||||
Validate the asset_manifest against the schema and persist via checkpoint.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during asset generation:
|
||||
- Use `web_search` to verify visual accuracy of subjects (e.g. what does this building actually look like?)
|
||||
- Use `web_search` to find reference images before generating illustrations
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Visual accuracy matters. If the script mentions a specific place, person, or object,
|
||||
verify what it actually looks like before generating images. Don't rely on
|
||||
the AI model's training data — it may be wrong or outdated.
|
||||
|
||||
## When You Do Not Know How
|
||||
|
||||
If you encounter a generation technique, provider behavior, or prompting pattern you are unsure about:
|
||||
|
||||
1. **Search the web** for current best practices — models and APIs change frequently, and the agent's training data may be stale
|
||||
2. **Check `.agents/skills/`** for existing Layer 3 knowledge (provider-specific prompting guides, API patterns)
|
||||
3. **If neither helps**, write a project-scoped skill at `projects/<project-name>/skills/<name>.md` documenting what you learned
|
||||
4. **Reference source URLs** in the skill so the knowledge is traceable
|
||||
5. **Log it** in the decision log: `category: "capability_extension"`, `subject: "learned technique: <name>"`
|
||||
|
||||
This is especially important for:
|
||||
- **Video generation prompting** — models respond to specific vocabularies that change with each version
|
||||
- **Image model parameters** — optimal settings for FLUX, DALL-E, Imagen differ and evolve
|
||||
- **Audio provider quirks** — voice cloning, music generation, and TTS each have model-specific best practices
|
||||
- **Remotion component patterns** — new composition techniques emerge as the framework evolves
|
||||
|
||||
Do not rely on stale knowledge. When in doubt, search first.
|
||||
|
||||
@@ -54,3 +54,14 @@ Assemble the structured script with:
|
||||
### Step 6: Submit
|
||||
|
||||
Validate the script against the schema and persist via checkpoint.
|
||||
|
||||
### Mid-Production Fact Verification
|
||||
|
||||
If you encounter uncertainty during script writing:
|
||||
- Use `web_search` to verify factual claims before committing them to the script
|
||||
- Use `web_search` to find reference images for visual accuracy
|
||||
- Log verification in the decision log: `category="visual_accuracy_check"`
|
||||
|
||||
Every factual claim in the script should be traceable to the `research_brief`.
|
||||
If you make a claim that isn't in the research, do additional research and
|
||||
add the source. Do not invent statistics, dates, or attributions.
|
||||
|
||||
Reference in New Issue
Block a user