RoosterEdit

RoosterEdit is a video studio for agents. It does not replace Remotion, HyperFrames, or FFmpeg; it decides what to make, organizes the assets, writes the plan, drives the chosen engine, reviews the result, and delivers the package.

The most important rule: do not render before the plan and the preview are approved, unless the user explicitly asks for no stops. Rendering is the cheapest part of the pipeline and the most expensive mistake to undo.

Running the CLI

This skill ships its CLI at scripts/rooster.mjs relative to the skill's base directory. Run it from the user's project directory, resolving the script against the skill base. In the examples below, <skill> means that base directory:

node "<skill>/scripts/rooster.mjs" doctor --json

Do not create a scripts/ directory in the user's project just to satisfy the command. The workspace (rooster/) belongs to the project; the CLI belongs to the skill. If the shell's working directory is the skill directory, the CLI will create the workspace in the wrong place.

Where to install the skill

When the user asks you to install RoosterEdit, ask first whether the install should be local to the project (recommended) or global. Use the skill folder the current harness actually reads; do not assume OpenCode.

Local: the harness's project-level skill folder plus rooster-edit (for example .opencode/skills, .claude/skills, or .agents/skills). Recommended because the version stays with the project and cannot surprise other work.
Global: the harness's global skill folder plus rooster-edit (for example ~/.config/opencode/skills or ~/.claude/skills). Use it only when the user wants RoosterEdit in every project on the machine.

If you cannot determine the harness's folders, inspect its skill discovery paths or ask the user. Wait for the answer before cloning. This choice is about where the skill lives, not where the video workspace lives (./rooster).

Reporting

End-of-task replies are short by default: 5-10 lines or one compact table. Include only what the user needs to act:

what was done or found;
the paths or links to the result;
what is missing or blocked, if anything;
one clear next question.

Do not repeat the brief, paste logs, list every command, or explain the whole skill unless the user asks. Put details in workspace files or link the reference docs. A plan, QA report, or delivery package can be longer only because the user must review its contents.

Installation and workspace setup are separate steps. After installing and running doctor, do not start onboarding or write a guide. Summarize the environment in a few lines and ask whether the user wants to configure the workspace now. Wait for a yes before creating rooster/ or a channel.

Progress updates

Use a compact step marker in status updates and at every approval gate. Keep one 8-step tracker for the project:

Environment and workspace
Brief and intake
Assets and transcript
Edit plan
Storyboard and timeline
Engine build
Preview and QA
Render and delivery

Examples:

Etapa 3/8 — Transcrição concluída. 42 trechos, 10:12 de duração.
Etapa 4/8 — Plano pronto em edit/plan.html. Posso seguir com a timeline?
Etapa 6/8 — Build concluído. Posso abrir o preview e rodar o QA?
Etapa 8/8 — Preview aprovado. Posso renderizar o final?

Skip steps that do not apply and say why. Do not print the full checklist on every message; show the current step, what changed, and the next gate. Do not combine timeline and final render in one approval: preview and QA sit between them.

Subagent-first execution

The main agent is the director, not the worker. It talks to the user, owns the brief and the decisions, runs the approval gates, and looks at the final frames. The noisy work goes to a stage subagent: transcript analysis, research, script drafts, plan drafts, style and storyboard, build and fixes, QA sweeps, render and packaging. Each subagent has its own context, which is discarded when the stage ends, so raw material never accumulates in the main thread.

Delegate by default whenever the harness has a subagent tool. Keep the stage inline when it is one cheap command, when it is the conversation itself (intake, approvals), or when it is the final visual judgment.

Stage	Subagent	Main agent receives
Brief	`producer`	one-paragraph brief + open questions
Research	`researcher`	5 findings + sources + license flags
Transcript	`transcript-analyst`	duration, topics, 10–20 beats, flags
Script	`scriptwriter`	hook + beat summary
Plan	`editor`	plan summary + risks
Style/storyboard	`art-director`	tokens + scene count + asset needs
Timeline	`editor`	duration math + markers
Audio	`audio-director`	voice/music/mix decisions
Build	`engineer`	status + artifact paths + blocker
QA	`qa`	verdict + top issues + frame paths
Render	`engineer`	final path + probe stats

Spawn with a short prompt: role file path, project path, one task sentence, input paths, constraints. Pass paths, never the brief, transcript, logs, or plan contents. If the input is the conversation itself, write the answers to work/intake.md first. Ask for the handoff described in references/subagents.md and nothing else. Use the harness's general-purpose or worker agent for stages that write files or run commands; a read-only or research type is fine for research. This is a capability, not a tool name: if the harness cannot start a fresh agent with file and command access, or a spawn fails twice, run the stage inline and keep the file boundaries.

The handoff is the only thing that enters the main context:

status: ok | needs-decision | blocked
artifacts: paths that exist
summary: <= 5 lines
decisions: what the main agent must confirm
blockers: what stops the stage
next: next stage or exact question

The main agent may read the brief, script, style, review.md, and handoffs, and may view plan.html and 3–5 frames. It must not read the raw transcript, full plan JSON, generated code, build/render logs, or a contact sheet of dozens of frames. If a detail is missing, send a follow-up to the same subagent instead of opening the raw file.

Nothing here is a dependency. The artifacts and gates are the same when a stage runs inline; you lose the context isolation, not the workflow.

Approval gates never move to a subagent. The subagent proposes; the user and the main agent decide.

First run after installation

If the workspace does not exist yet, do a short onboarding before creating any project.

First ask: "Quer configurar o workspace agora?" (or "Shall we set up the workspace now?"). Explain in one line that this creates rooster/ and the first channel. If the answer is no, stop and create nothing.

If the answer is yes:

Use ./rooster by default. Do not ask "where does the workspace live" unless the user wants a custom path.
Ask one question: "O que esse canal vai produzir? Uma frase basta." Use the answer and the conversation to infer the channel name, language, format, source, profile, assets, engine, autonomy, and voice. Do not ask all twelve channel fields, and do not ask for a duration.
Show the inferred defaults in one compact line and ask "Está bom ou quer ajustar algo?" Ask a follow-up only when a field is genuinely ambiguous, such as the platform or whether the source is real footage.
On confirmation, run init, then channel new <id> ... with the answers. Show a short summary and stop.

Duration is not a channel default: it belongs to each project and is chosen when the video is created. The full twelve-field setup is an opt-in advanced path. If the user asks to customize everything, ask in groups of at most three, never all at once.

A channel is the stable group for a brand, audience, or operation (for example "EN Tech" or "PT Criador"). It owns the creative defaults: language, format, profile, assets policy, engine, autonomy, and voice. Every project belongs to a channel and can override any of those defaults. Duration is per project, not a channel default.

Do not start a video in the same turn unless the user explicitly asks. Read references/onboarding.md for the exact questions, defaults, and commands. Read references/assets.md before downloading or generating any asset.

Fast path: the 6-step video workflow

When the user wants the simplest route from raw footage to a finished video, follow the same six steps as the reference workflow, adapted to the RoosterEdit workspace:

Prepare the machine — FFmpeg, Node.js LTS, Python 3, HyperFrames, and Whisper (or HyperFrames' Parakeet/whisper.cpp). Ask before installing anything.
Create or resolve the project — rooster new ...; raw media goes in assets/source/.
Write the style guide — art-director writes style.md and resolves the profile. Run styleproof <slug> and approve the three sample frames before planning.
Transcribe and plan — transcript-analyst writes edit/transcript.json, edit/digest.md, and edit/analysis.json; editor writes edit/plan.json from the analysis and style.md. Show plan.html with transcript context and wait for approval.
Create the visual elements — engineer builds letreiros, graphics, lists, zooms, b-roll, lower thirds, music, and SFX when the channel style calls for them. A cut-only draft is not a finished video unless the user explicitly asked for a clean cut.
Assemble, review, export — engineer runs build to generate the HyperFrames or Remotion project from the approved plan; use --sample 3 before the full build. qa inspects preview/index.html and the frames, then engineer renders to renders/; export writes an EDL/FCPXML handoff when the user wants DaVinci or Premiere.

Read references/video-pipeline.md for the exact commands and the mapping from the reference video's folders to ours. The rest of this skill is the broader studio mode; the fast path is the default for single-video jobs.

Operating principles

Direct before generating. A clear brief, script, and shot list save more time than any prompt tweak. Spend the first part of the work understanding the video.
Inspect, don't assume. Read the files, probe the media, look at frames, and check the tools. Never claim a render or an asset exists because the code looks right.
Keep the edit editable. Prefer named scenes, variables, and readable components over one-off scripts. The user should be able to change a color, a line, or a clip without rewriting the project.
Review with eyes. Use the browser preview, screenshots, or rendered stills to judge composition, pacing, and captions. Code review alone is not enough.
Respect provenance. Record where every asset came from and its license. A beautiful video with an unlicensed track is a liability.
Degrade gracefully. The harness may not have subagents, a browser, Node, FFmpeg, or TTS. Offer the best path available and say what is missing.
Delegate the heavy stages. The main agent directs; stage subagents do the noisy work and return a short handoff. Transcripts, build logs, generated code, and QA sweeps should not pass through the main context. Read references/subagents.md.
Report short. End every task with the result, the paths, and one next question. Do not narrate the whole process or dump commands unless the user asks.
Finish the creative layer. Cuts alone are not a video. Plan overlays, b-roll, music, SFX, or captions unless the user explicitly asked for a clean cut.
Ask when uncertain. If a choice changes the cut, the look, the audio, or the cost, ask at the current Etapa X/8. Do not guess silently.
Protect the context. Video work is token-heavy. Redirect engine logs to files, read only the tail, use digest instead of the full transcript, and inspect a few key frames instead of every frame. Read references/token-discipline.md.

Step 0 - Find the workspace

Look for a rooster/ directory in the current project first, then use ROOSTER_WORKSPACE if it is set. The default is ./rooster; only ask for a custom path when the user wants one.

If neither exists and the user has already asked to make a video, creating the workspace is implied; run:

node "<skill>/scripts/rooster.mjs" init

If the user just installed the skill or is only exploring, do not create it silently: follow "First run after installation" and ask first.

The workspace is where channels, projects, profiles, and the asset library live. Keep it out of the skill directory; the skill is reusable, the workspace belongs to the user's video project.

If the workspace exists but has no channel, create one before creating a project. Every project belongs to a channel; a default channel covers one-off videos.

If the user is only asking a question or exploring an idea, answer it without creating a workspace. A question is not a request to build.

Step 1 — Check capabilities

Run:

node "<skill>/scripts/rooster.mjs" doctor --json

This reports Node, npm, Python, FFmpeg, FFprobe, Git, GPU, detected engines, TTS providers, yt-dlp, Whisper, and the HyperFrames CLI. The harness itself knows whether subagents and a browser are available; combine that knowledge with the CLI output. For costs, read docs/COSTS.md; never call a paid provider without explicit permission.

Read references/harness.md when something is missing. The short version:

No Node: use FFmpeg directly for cuts and audio, but you cannot run HyperFrames or Remotion.
No FFmpeg: you can still plan, script, and storyboard, but you cannot probe or render locally.
No browser: render stills or frames and inspect them as images.
No TTS: use the user's voice, captions only, or a local TTS tool if present.
No yt-dlp: ask the user for the file, or install it only with permission.
No subagents: do the work inline, in sequence, and keep raw output in files. Do not pretend work is running in parallel.

Step 2 — Intake

Ask only the questions that change the output. Read references/intake.md for the full set and defaults. The essential dimensions are:

Dimension	Values
Source	`live` (real footage), `generated` (code/AI), `hybrid`
Voice	`user`, `tts`, `none`
Style	`user`, `profile`, `ai`, `reference`
Autonomy	`auto`, `guided`, `manual`
Platform / aspect	YouTube 16:9, Shorts/Reels/TikTok 9:16, square 1:1, custom
Length	Short (<60s), mid (1–5 min), long (>5 min)
Engine	`auto`, `hyperframes`, `remotion`, `ffmpeg`

Do not interrogate the user with all of them at once. Infer sensible defaults from the brief and confirm the ones that are expensive to change later (aspect ratio, duration, voice, engine).

Step 3 - Resolve the channel and profile

A project belongs to a channel and uses a profile (how it looks and sounds).

channel  = production standard: content, language, format, profile, assets, engine, voice
profile  = visual identity: colors, type, motion, captions, audio, components
project  = channel + profile + overrides + duration + assets + timeline + engine

Read references/profiles.md for the schemas and resolution order. The short version:

Project overrides in project.json.
Channel defaults in channels/<id>/channel.json and channel-scoped profiles.
Workspace profiles in rooster/profiles.
Global profiles in ~/.rooster/profiles.
Built-ins shipped with the skill in templates/profiles.

The project can override anything it inherits from the channel. There is no separate category concept: the channel's content field describes what it produces, and the project's brief and plan define the structure of each video.

If the user has no channel, create one first. If they have no profile, offer three paths: use a built-in, create one from their brand assets, or derive one from a reference. If they have a profile from another project, reuse it instead of recreating it.

After the profile resolves, run styleproof <slug> and show the three frames. Do not plan or build until the look is approved.

Step 4 — Plan before building

Produce, in order:

brief.md, script.md/script.json, and style.md — the goal, the words, and the look.
storyboard/storyboard.json and edit/timeline.json — the scene plan and the edit decision list.
edit/plan.json — the fast-path plan the user approves before the build.

Read references/workflow.md for the full pipeline and the approval gates. For the fast path, the plan lives at edit/plan.json and must be approved before any engine project is created; read references/edit-plan.md for the schema and heuristics. Run plan <slug> --show to write edit/plan.md and edit/plan.html, display the HTML artifact in the harness's preview pane or browser when available, then ask for approval. Delegate the draft to editor; review the HTML with the user instead of building the JSON by hand in the main thread. For advanced layers (captions, motion, audio, reframe, delivery, color, b-roll, charts, TTS, multicam), read references/professional-elements.md and load only the feature you need.

If the user asked for auto, log the decisions and keep moving; if they asked for guided, stop at the gates that matter (brief, script, style/storyboard, rough cut, final).

A useful plan answers these questions before any engine code is written:

What is the hook in the first three seconds?
How many scenes, and how long is each one?
What is on screen while the voice speaks?
Where are the captions, and what is the safe area?
What does the viewer see when there is no voice?
What is the exact output format?

Step 5 — Ingest assets

When the user says they will provide their own footage, do not ask "where is the file?" first. Create the project if needed, run open <slug> to show and open assets/source/, and tell them to put the files there. If they give a path instead, ingest it.

Put user files in assets/source, generated media in assets/generated, and licensed stock in assets/licensed. When the user provides a video link (YouTube, Vimeo, etc.) as source material, use yt-dlp to fetch it into assets/source/<slug>/ together with its info JSON, thumbnail, subtitles, and chapters. Read references/link-ingest.md before downloading: only fetch content the user owns or is authorized to use, keep cookies out of the repository, and never bypass DRM or paywalls.

Build assets/manifest.json with:

stable id, path, type, hash;
dimensions, duration, fps, codec, audio presence;
source and license;
tags that help the editor find the asset later.

Never delete or overwrite the user's originals. Prefer copying or linking into the workspace. If a file is missing, say so before building around it.

For footage-driven projects, run transcription and analysis through transcript-analyst (HyperFrames/Parakeet, whisper.cpp, or the Whisper CLI). It writes edit/transcript.json, edit/digest.md, and edit/analysis.json, and returns duration, topics, beats, and flags. Then have editor write edit/plan.json from the analysis, style.md, and the brief; get approval before opening the engine. Silence removal, filler-word removal, and b-roll placement are editorial decisions; they belong in edit/plan.json, edit/edl.json, and edit/timeline.json, not buried in a render script.

Step 6 — Choose and drive the engine

Read references/engines.md for the full decision matrix. The default is auto. HyperFrames and Remotion are the two creative engines; FFmpeg is a media utility for probing, cutting, captions, and audio, not a third creative engine.

Situation	Prefer
Real footage, interview, talking head, simple cuts	`ffmpeg` for cuts/audio, plus HyperFrames or Remotion for overlays
HTML/CSS/GSAP, kinetic type, charts, maps, motion graphics	`hyperframes`
React components, data-driven scenes, `@remotion/three`, complex state	`remotion`
3D characters or product scenes with React	`remotion` + `@remotion/three`
3D in an HTML composition	`hyperframes` + Three.js
No Node or FFmpeg	Produce the plan and explain that rendering needs Node/FFmpeg

Respect an explicit engine request. If the requested engine cannot do something the user needs, explain the tradeoff and propose an alternative instead of silently switching.

Scaffold only the engine you are going to use. Keep the engine project inside channels/<channel>/projects/<slug>/engine/<engine>/. Keep the source of truth for editorial decisions in edit/timeline.json (or edit/plan.json in the fast path); let the engine adapter translate it.

Once the plan is approved, build the engine project:

node "<skill>/scripts/rooster.mjs" build meu-video --engine hyperframes
node "<skill>/scripts/rooster.mjs" build meu-video --engine remotion

build reads edit/plan.json, applies the plan's cuts with FFmpeg, mixes plan.music under the voice, remaps the element timings to the cut timeline, copies the base media and element assets, and writes a working engine project. Use --force to rebuild and --no-cuts to ignore the cuts. A cut-only plan or a plan with no music decision is refused unless notes records the exception; pass --allow-cut-only or --allow-no-music only when the user explicitly asked for that. For HyperFrames it also runs the engine's deterministic contract; for Remotion it generates the composition and data files.

Run the build through engineer. It owns the generated code, the logs in work/logs/, and the fixes, and returns status, artifact paths, and any blocker. The main agent does not run the command above directly; it passes the approved plan and the engine. If a fix changes the story, the engineer returns needs-decision instead of editing the plan.

Before the full build, use build <slug> --sample 3. It builds three representative elements over the real cuts so the user can approve motion, type, and density without paying for the whole video. Rebuild with --force after approval.

For the fast path, Option 1 is automatic assembly in HyperFrames for HTML/CSS/GSAP motion. Option 2 is Remotion for React, data-driven scenes, and 3D. FFmpeg remains a utility for cuts, proxies, captions, and audio. Both engines start from the same approved plan.

Step 7 — Preview and review

Offer a preview before rendering:

HyperFrames: npx hyperframes preview (or the bundled adapter).
Remotion: npx remotion studio.
FFmpeg: render a low-resolution draft and show it in the review page.
Unified review: node "<skill>/scripts/rooster.mjs" preview <slug> writes preview/index.html with the player, plan, timeline, captions, audio, validation, and QA checklist. Open it with --open when the harness has a browser.

Read references/timeline.md for the timeline contract and the review page. When a browser is available, use it: open the preview, take screenshots, check console errors, and inspect the timeline. When it is not, render stills at key beats and read them as images. qa can open the preview, capture the screenshots and console errors, and write the report; look at 3–5 of its frames yourself before deciding.

The review page should make these obvious:

every scene and its duration;
the clips on each track;
captions and their timing;
audio tracks and music;
missing assets or render errors;
a checklist of QA items.

Step 8 — QA

Read references/qa.md for the full checklist. Run captions <slug> first when the project needs caption sidecars, and textcheck <slug> to list every on-screen text with its timecode. Spawn qa with the checklist, the render path, and the plan; it returns the verdict, blocking issues with evidence, and frame paths. At minimum, verify:

resolution, aspect ratio, fps, and duration match the plan;
no unintended black frames, freeze frames, or gaps;
audio is not clipping, is at the target loudness, and has no long silences;
captions are in sync, readable, inside the safe area, and correctly spelled;
key text and logos are inside the title-safe area;
every asset exists and has a recorded license;
the hook lands in the first three seconds;
the pacing matches the channel and the plan;
the brand profile is applied consistently;
no cut starts or ends inside a word, and every cut boundary was checked by ear;
every on-screen text in qa/text-review.md was proofread;
the full draft was watched once, not only sampled frames.

Fix the cheap issues before rendering. A technical QA pass on a draft is faster than re-rendering a final. Send fixes back to engineer; do not rebuild by hand in the main thread.

Step 9 — Render and deliver

Use engineer in render mode: render a draft, inspect 3–5 frames, then render the final. The engineer validates the output with FFprobe (duration, resolution, fps, audio channels, loudness) and runs deliver <slug> to write renders/thumbnail.jpg and renders/metadata.json. It returns the final path and the probe stats, not the log.

If the user wants to finish in DaVinci Resolve or Premiere, run export <slug> --format both after the plan is stable. It writes edit/export/cuts.edl and timeline.fcpxml; these are handoffs, not a replacement for the plan.

Deliver renders/final.mp4, renders/draft.mp4, captions.srt/.vtt, thumbnail.jpg, metadata.json, and the project archive. metadata.json should include title, description, tags, chapters, aspect ratio, duration, and any platform-specific fields. Do not upload anywhere without explicit permission.

Step 10 — Learn

If the user liked a look or a component, offer to save it:

rooster profile fork to create a reusable profile;
move a component into profiles/<id>/components;
update the channel defaults if the change should apply to future videos;
record decisions and feedback in review.md.

Reuse is the point of the workspace. A project that cannot inform the next one is a missed opportunity.

Modes

Mode	Behavior
`auto`	Make sensible decisions, log them, stop only for missing assets, license issues, or render failures
`guided`	Stop at brief, script, style/storyboard, rough cut, and final approval
`manual`	The user provides the script, EDL, or assets; execute precisely and ask before changing creative decisions

Source, voice, and style are independent flags. A real-footage video can use TTS narration; a generated video can use the user's voice; a 3D video can have no voice at all.

Workspace contract

The skill expects this shape:

rooster/
├── workspace.json
├── config.json
├── channels/<channel>/
│   ├── channel.json
│   ├── projects/<slug>/
│   │   ├── project.json
│   │   ├── brief.md
│   │   ├── script.md
│   │   ├── style.md
│   │   ├── style/proof/
│   │   ├── storyboard/
│   │   ├── assets/{source,generated,licensed}/
│   │   ├── edit/{transcript.json,digest.md,analysis.json,plan.json,plan.md,plan.html,timeline.json,edl.json,captions/,audio/,export/}
│   │   ├── engine/{hyperframes|remotion|ffmpeg}/
│   │   ├── work/{handoffs,logs,scratch,notes}/
│   │   ├── preview/
│   │   ├── renders/
│   │   ├── qa/{report.md,text-review.md,frames/}
│   │   └── review.md
│   ├── profiles/<id>/
│   ├── assets/
│   └── library/
├── profiles/<id>/
├── library/{music,sfx,fonts,overlays,luts,broll,images}/
└── cache/

New projects belong inside channels/<channel>/projects/. The root projects/ folder is legacy; only keep it for old workspaces.

If the user already has a different structure, adapt to it and record the mapping in project.json instead of forcing a migration.

Guardrails

Do not render with missing assets. A placeholder is a bug, not a style.
Do not cover the footage with a full-screen panel or card unless the user explicitly asks for it. Prefer lower-thirds, captions, corner labels, and overlays that leave the video visible. A mismatched slide is not an invitation to cover the screen.
Do not use unlicensed music, fonts, or footage. If the license is unknown, ask.
Do not download third-party video from a link unless the user owns it or has permission; respect platform terms and copyright. Never bypass DRM, paywalls, or access controls.
Do not upload, publish, or send files to external services without explicit consent.
Do not run destructive shell commands on the user's source media.
Do not hide a failure behind a lower-quality render. Report it.
Do not claim a feature is supported because a library exists; check the installed version and the actual adapter.
Do not create a full NLE, a video-generation model, or a cloud render service as part of the v1 scope. Keep the core focused and pluggable.

Reference map

Read this	When
`references/workflow.md`	Full pipeline, gates, and artifact list
`references/subagents.md`	When and how to delegate, the handoff contract, and the stage playbook
`references/onboarding.md`	First-run workspace setup and defaults
`references/assets.md`	Asset strategies, sources, licensing, and adjustment
`references/token-discipline.md`	Log suppression, transcript digest, and context budget
`references/video-pipeline.md`	The 6-step workflow inspired by the reference video, adapted to our workspace
`references/edit-plan.md`	`edit/plan.json` schema, cuts, elements, approval gate
`references/intake.md`	Questions, defaults, and mode detection
`references/engines.md`	Engine decision matrix and adapter contracts
`references/profiles.md`	Profile schemas and resolution
`references/timeline.md`	Timeline JSON, review page, and browser QA
`references/qa.md`	Technical and editorial checklists
`references/professional-elements.md`	Index of advanced layers and feature references
`references/nle-handoff.md`	EDL/FCPXML export and DaVinci/Premiere import
`references/harness.md`	Capability detection and degradation
`references/link-ingest.md`	Downloading video links with yt-dlp, metadata, subtitles, and licensing
`references/schemas.md`	JSON schemas for project, channel, profile, transcript, analysis, timeline, manifest

Quick commands

# Workspace
node "<skill>/scripts/rooster.mjs" init
node "<skill>/scripts/rooster.mjs" doctor --json

# Channel
node "<skill>/scripts/rooster.mjs" channel new en-tech --language en --format 16:9 --profile tech-neon --voice tts

# Project
node "<skill>/scripts/rooster.mjs" new video-x --channel en-tech --duration 60
node "<skill>/scripts/rooster.mjs" open en-tech/video-x
node "<skill>/scripts/rooster.mjs" paths en-tech/video-x
node "<skill>/scripts/rooster.mjs" ingest en-tech/video-x --url "https://www.youtube.com/watch?v=..." --confirm-rights
node "<skill>/scripts/rooster.mjs" transcribe en-tech/video-x --model small --language en
node "<skill>/scripts/rooster.mjs" digest en-tech/video-x --from 0 --to 60
node "<skill>/scripts/rooster.mjs" styleproof en-tech/video-x --open
node "<skill>/scripts/rooster.mjs" plan en-tech/video-x --show
node "<skill>/scripts/rooster.mjs" textcheck en-tech/video-x
# Advanced layers: see references/professional-elements.md
node "<skill>/scripts/rooster.mjs" check en-tech/video-x

# Review and handoff
node "<skill>/scripts/rooster.mjs" build en-tech/video-x --sample 3
node "<skill>/scripts/rooster.mjs" preview en-tech/video-x --open
node "<skill>/scripts/rooster.mjs" export en-tech/video-x --format both
node "<skill>/scripts/rooster.mjs" render en-tech/video-x --draft
node "<skill>/scripts/rooster.mjs" render en-tech/video-x --final

If a command is not implemented yet, do the equivalent manually and tell the user what you did. Do not pretend the CLI succeeded.

What good looks like

A good RoosterEdit session feels like working with a director who also knows the tools:

the user explains the idea in a few sentences;
the agent asks two or three sharp questions, not twenty;
the plan appears as a brief, a script, and a storyboard the user can react to;
the style is consistent because it comes from a profile, not from vibes;
three style-proof frames and three sample elements are approved before the full build;
the preview is visible in the browser before the expensive render;
every on-screen text is proofread and every cut boundary was checked by ear;
the final package includes the video, captions, thumbnail, and metadata;
the next video starts faster because the profile or component was saved and the channel already holds the defaults.

WesleyQDev/rooster-edit

What is rooster-edit?

Ask in your favorite AI

Documentation