stitch-remotion

Stitch Screen Walkthrough Video

Quick Start

1. "Create a video for the three-step store appointment flow; first provide a locally reviewable result."
2. "Show a zoom into the key area of the order page; keep the existing scope and provenance."
3. "Arrange Chinese titles and voiceover for existing screenshots; mark missing inputs and validation status."

For designers, frontend developers, and teams maintaining this flow. Designers provide intent and assets, developers provide engineering/tooling, and the team preserves provenance and acceptance status during handoff.

Capability Boundaries

✅ Good At

• Create a video for the three-step store appointment flow.
• Show a zoom into the key area of the order page.
• Arrange Chinese titles and voiceover for existing screenshots.

⚠️ Requires Assets

• Screen assets and actual dimensions.
• Order, duration, frame rate, and output aspect ratio.
• Existing Remotion project and available dependencies.

❌ Not Applicable and Handoff

• Clickable web app → stitch-ui-react-components.
• Regenerate Stitch page → stitch-ui-execute.
• Real business operation screen recording → use the authorized screen recording flow and provide a shot list.

Workflow

1. Confirm the screen order, retrieve/download the required images to video/public/assets/screens, and protect the signed URL.
2. Write the dimensions, titles, durations, and imagePath to screens.json, using the actual returned assets.
3. Generate ScreenSlide and TransitionSeries according to the template; transitions are sibling nodes between Sequences.
4. Unify the Remotion dependency versions and calculate total frames = sum of scene frames - overlap; each segment must be longer than the transition.
5. After previewing, render and check the first frame, transitions, last frame, captions, and voiceover; when not rendered, report only the storyboard or source artifacts.

Order by dependency: provenance check → local artifacts → authorized external operations → validation handoff. For multiple tasks, do the current main path first; when information is missing, first output a draft with assumptions, then precisely list what is missing and its purpose; do not use vague prompts like "please provide more context."

Security and Result Validation

Do not read unrelated account configurations and do not collect user passwords; credentials are provided only by the environment or authorized connectors. Use only demo data in examples; before uploading, replace customer names, phone numbers, and order numbers with demo values, and check HTML, screenshots, and file metadata. Do not write keys, session cookies, full base64 text, or signed download URLs into reports/repositories. Do not fabricate unverified parameters, visual effects, or business numbers; the output should note the source, basis for decisions, what was actually executed, and what has not yet been verified.

• Two segments of 4 seconds each, 30fps, one 20-frame transition = 220 frames.
• staticFile paths are relative to public.
• The final video's actual frame count, aspect ratio, and keyframes have been checked.

Customizable: fps, canvas size, duration per screen, transition type, voiceover, and captions. Value-added checks: recalculable frame count; asset manifest; key area/voiceover synchronization.

FAQ

Q1: What is the main deliverable? Demo input 2×4 seconds, 30fps, 20-frame transition → durationInFrames=220; this is a hypothetical storyboard calculation and does not claim that a video has been generated.

Q2: When should I switch to another entry point? Clickable web app → stitch-ui-react-components; regenerate Stitch pages → stitch-ui-execute; screen recording of real business operations → use the authorized screen recording process and provide a storyboard list.

Q3: What happens if inputs are missing? First provide a clearly marked draft of local assumptions, and list 'Need to supplement: screen assets and actual dimensions; order, duration, frame rate, and output aspect ratio; existing Remotion project and available dependencies.' Write operations that depend on these inputs are not executed.

Q4: How do I determine completion? Two segments of 4 seconds each, 30fps, one 20-frame transition = 220 frames; staticFile paths are relative to public; the final video's actual frame count, aspect ratio, and keyframes have been checked.

Q5: How do I customize it? fps, canvas size, per-screen duration, transition type, narration, and subtitles; if not provided, use the existing project values and indicate the assumptions.

Q6: Does it automatically upload, install, or go live? Only perform actions covered by the current request and existing authorization; without a remote receipt, do not claim upload success; without runtime verification, do not claim it is live. Additional installations or scope expansion require explaining the specific impact first.

Reference as needed

• Read when executing detailed mappings, APIs, or templates: Extended process。
• Read when encountering failures or abnormal inputs: Anti-patterns and Gotchas。
• Read when dealing with edge cases, compatibility, customization, and authorization: In-depth FAQ。
• Read when complete input/output and verification scenarios are needed: Local application example。
• The local implementation basis is the source code accompanying the current skill and pinned upstream snapshot; the structure follows the Agent Skills specification. The tool's current behavior is subject to the actual schema; when not connected, do not claim to have verified online behavior.

When to use

This skill is loaded when the user needs to select and execute a verifiable, recoverable professional workflow for the current request . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: orchestrate Stitch screen assets into a Remotion walkthrough video; triggered when the user needs transition, zoom, subtitle, or narration demonstrations. Interactive React applications and live screen recording are not part of this entry point..

Rules

• Read before write: first confirm the current state and real capabilities, then perform actions that change external state.
• Least privilege: use only the files, tools, accounts, and network scope required to complete the current step.
• Evidence first: when run results, resource IDs, versions, hashes, or test outputs are missing, clearly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and stage states; when results are unclear, query first rather than retrying blindly.
• Privacy and security: logs, examples, receipts, and error messages must not contain tokens, cookies, keys, or personal sensitive data.

Workflow

Step 1: Clarify intent

Confirm whether this skill matches the goal; if it is only an adjacent need, hand it to a more precise skill.

Step 2: Perform pre-check

Confirm the goal, inputs, constraints, available tools, success criteria, and failure boundaries; if any key condition is unknown, stop at the read-only stage.

Step 3: Form a plan

List the tools to be called, the objects that will change, the success criteria, and the safe exit method after failure.

Step 4: Execute actions

Execute with the minimum sufficient steps, and record evidence at key state changes; every external call retains a traceable state or receipt.

Step 5: Verify delivery

Output results, verification evidence, incomplete items, risks, and clear next steps, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions match the user's intent, and adjacent tasks have not been misrouted to this skill.
• The input, target object, version, and output location are all clear, and no guessed values have been used in place of required values.
• All writes, payments, publications, or irreversible actions are within the scope authorized by the user.
• The results have been verified with independent checks; "command succeeded" or "file exists" alone does not count as complete acceptance.
• The output includes actual evidence, failed/skipped items, remaining risks, and executable next steps.

Gotchas

1. Treating a plan as a result: A document or prompt is not equal to actual execution; the actual execution level must be stated.
2. Retrying on error: A timeout or lost response may already have produced remote state; query first before deciding whether to retry.
3. Implicit scope expansion: Batch, full-scale, publication, overwrite, and payment operations are not natural extensions of ordinary reads and writes.
4. Version drift: When referencing external resources, record the version, tag, or commit; do not treat a mutable branch as release evidence.
5. Stale evidence: Caches, old screenshots, and historical tests cannot prove the current environment; refresh key evidence before delivery.

Non-applicability and boundaries

Do not exceed the scope given by the user; writes, payments, publications, and irreversible actions require explicit authorization. If the request requires another skill, do not copy its body text; hand off by skill name and preserve the current task context.

Progressive disclosure

• When input/output, state, and authorization points need to be determined, read references/workflow-contract.md。
• When pre-delivery self-check is needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first runs, refusal of overreach, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。