ELX EzVideoEdit

What does ELX EzVideoEdit do?

This Skill is designed to run with the ELX Workbench; it is not a standalone video processor. The installed bundle-location.json points to the actual workbench. The CLI within the source code automatically locates the root directory, but you can also specify it using EZVIDEOEDIT_ROOT. Before first use, read the local setup. Local models, Python, MCP access permissions, and text services must be configured by the user; the author's authorizations or credentials are not inherited.

Stage 1: Production and Delivery

Execution defaults to completing local delivery. The user selects the source material, output directory, and the manual subtitle review method for this batch. If no selection has been made, ask whether to skip or manually modify. If the skip option for this batch has been explicitly confirmed, read back the fresh summary for each video, record it as "skip," and do not repeat the question or claim that manual proofreading has been completed. Do not require a platform account or browser connection as a condition for local completion.

1. Run node .agents/skills/elx-ezvideoedit/scripts/cli.mjs help, then use status to verify actual capabilities. Launch or reuse services via launch. Write tasks through the same service; do not directly modify task.json. See local API for detailed fields.
2. Use tools/list and get_status to discover the native-production/1 capability. Official 0.9.1 and verified 0.9.0 both call using the actual schema. First, verify instances under the same profile. If necessary, use node packaging/setup.mjs native-open to open the GUI, then native-connect. The GUI and stdio share the same profile. When models, APIs, or permissions are missing, report the location of native settings; let the user handle it, do not modify policies to bypass restrictions.
3. The quality chain consists of MOSS for primary transcription, FireRed for word-level timestamps, and Qwen3-ASR for independent verification, using local models and Python. AI-powered sentence segmentation and proofreading use the saved native text services. Report actual execution, cache reuse, and degradation separately; do not mark completion based solely on configuration tags. Subtitle stutter cleanup does not equal audio/video trimming.
4. Use native-start for serial production, native-state for queries, and native-resume to resume. Use native-operation for independent tools. After AI preview, apply using the same job_id; do not re-send. If a timeout or unclear result occurs, first check old job/attempt. Only resume after the user has completed configuration when configuration_required is explicitly raised; do not blindly resend.
5. Native scope =current allows only current projects; creating or opening other projects requires library scope. Independent capabilities execute under their respective permissions. Do not call old 0.8.7 continuous authorization or batch token interfaces for version 0.9.x; do not add batch_token to official apply_plan/export_subtitles calls.
6. After a formal save_project, export the video and official SRT, and verify they match the same project snapshot. native-adopt only binds source projects with identical material SHA. review-inspect reads the actual number of suggestions; if permissions are insufficient, retain an unknown count. For already authorized skips, save review-choice using the current signature. Manual modifications are saved by the user in the native program; then review-finish only re-exports video/SRT without re-running recognition overwriting manual edits. For verification_required, use review-recover to check the old job; do not restart.
7. Degradation of timestamps follows the service's existing safeguards. Skipping manual checks does not mean ignoring failures, unknown errors, or missing time evidence. Only save the protected range when explicitly allowed to proceed conservatively. preserve-review is only for completed but partial text proofreading where the error count is 0; preserve the entire original text and protected intervals, do not adopt suggestions from that batch, do not resend, and retain the partial receipt.
8. Generate exactly 5 titles in different styles, 3 different descriptions each no longer than 50 characters, and independent tags based on the actual transcription. Covers must be three actual images in 16:9, 4:3, and 3:4 aspect ratios. Check text, content, and aspect ratio for each cover individually; do not stretch. You may recommend combinations, but cannot pretend the user has already selected.

Proceed continuously within the approved scope. Confirm with the user for any new external services, costs, directories, or permission changes. On pause, retain the original footage, project, output, and receipts. After resuming, first perform a read-only check. By default, execute serially within the current conversation. Delegate to a new conversation or sub-agent only when explicitly requested by the user; the model is chosen by the user and the host. The web "hand off to Codex" only saves a to-do; it does not mean the host has executed it.

Folder Delivery

Each video gets a <original_filename>_交付 folder containing the following files directly in the root: final_captioned_video.mp4, original video (with original filename), subtitles.srt, publishing_copy.txt, cover_16x9.png, cover_4x3.png, cover_3x4.png, delivery_instructions.txt. Place only editable project files and actual referenced dependencies in the "工程" (project) subdirectory.

• After material verification, move the single original source footage back to its original location using the original filename. Verify SHA and absolute path before and after moving; update and verify project references. Do not copy a duplicate and pass it off as the delivered original. If duplicate copies already exist, list their paths, count, sizes, and impact. Only proceed after obtaining deletion confirmation; do not overwrite the single original footage.
• The project must correspond to the same snapshot as the final video/SRT and all dependencies must be available. Include only the actually referenced material; do not package entire cache copies or historical projects. The delivery instructions merge the cut count, model/subtitle reminders, and verification conclusions. Keep the complete receipt in the workbench.
• scripts/package-stage1.py --help is a streamlined packaging entry point. Input the task, copy, and cover paths saved by the service; move the original footage from the same disk as original-root. Stop on cross-disk or name conflicts; do not implicitly copy and delete. The workbench import will still copy work materials; do not arbitrarily delete working copies based on this.
• Only claim complete delivery after verifying materials, summaries, timestamps, image proportions, and project dependencies. If there are no viable candidates for editing, report an actual count of 0; do not falsely claim to have removed audio/video. Verify update packages before applying; retain user modifications and history; do not overwrite directly.

Stage 2: Optional Upload

By default, the user uses their existing MultiPost or standard platform entry points. At the end of Stage 1, provide the delivery path and copy. If the user has not yet indicated an upload preference, remind them that manual upload is possible. If they have explicitly declined to upload, end the process; do not repeat the question. See optional upload boundaries for details.

Only when the user explicitly requests Agent-triggered uploads should the existing plugin's normal entry point be used. Verify the real account and authorization, and stop before final publication. If the plugin, login, verification code, or controls fail, preserve the context for handover. Do not automatically use Computer Use, inject patches, or modify plugins. Confirm before making payments, registrations, publications, sending messages, or changing account permissions. The workbench preparing a receipt does not mean the upload or publication was successful.