SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsjianying-export-prep

jianying-export-prep

Design & creation

View repository

Updated 10-15 21:47

About this skill

JianYing Export Prep

Choose agent preview, draft archiving, or native export according to the delivery goal, and truthfully report the actual evidence.

When to use

  • The user explicitly requests the Jianying capability corresponding to this skill's title and accepts handling it through the unified Rust jianying CLI.
  • The user needs auditable planning, execution, or verification evidence, not just a conceptual answer.
  • When requirements are not yet clear, hand off to jianying-use routing first; this skill should not be used for other editors, general video knowledge Q&A, or speculative execution that lacks the necessary materials.

Capability boundaries

  • ✅ Can do: generate deterministic plans based on real paths and probe results; when capability is supported , execute operations in this domain; output the evidence level actually achieved.
  • ⚠️ Requires conditions: Writes must use isolated copies; fees, external services, and native application actions must have precise approval; playback or export conclusions must have corresponding runtime evidence.
  • ❌ Out of scope: do not automatically install or upgrade the CLI, do not generate Python draft scripts, do not call external headless checkout, do not overwrite source drafts, and do not fabricate resource IDs, media facts, or success states.

Step 1 — Establish a factual baseline

Record the user's goal, absolute paths, host platform, target deliverables, and allowed side effects; when information is insufficient, first provide a read-only diagnostic plan and list the missing facts item by item.

Step 2 — Handshake capabilities

Run version, doctor, and capabilities checks. A satisfying version does not mean the capability is available;partial、external_dependency or a missing state must enter the degraded path.

Step 3 — Validate inputs

Probe media, drafts, configuration, or task status; reject nonexistent paths, out-of-range times, unknown schemas, mismatched hashes, and approvals that cannot be bound to a target.

Step 4 — Form a deterministic plan

Write the operations, parameters, output paths, risk levels, confirmation points, and expected evidence into the plan. Order multiple tasks as "read-only facts → reversible writes → external/native actions."

Step 5 — Execute or stop before the gate

Execute only steps that are supported and authorized. When output is ambiguous, times out, or is partially successful, retain the task ID, audit logs, and artifacts; do not automatically retry.

Step 6 — Verify and deliver

Run structural validation, then append cold reopen, playback, or native export evidence according to the goal; report the actual level, failed fields, recoverable actions, and unverified items.

Rules

  • The material durations, dimensions, streams, hashes, and draft versions in the plan must come from tool output.
  • Approval must be bound to the command, parameters, target, validity period, and budget; if any field changes, reconfirm.
  • User data is processed only within the local target paths and the declared external Provider boundaries; unrelated credentials must not be collected, uploaded, or logged.
  • When current evidence is insufficient, use UNVERIFIED、BLOCKED or AMBIGUOUS; do not fill in results by inference.

Gotchas

  1. Treating version as capability: always check the specific capability; do not execute directly just because the CLI version is new enough.
  2. Treating structural validation as film acceptance: project verify only proves the structural layer; playback and native export require independent evidence.
  3. Modifying the source draft directly: first create an isolated copy and record the input hash; any in-place overwrite request must stop and be changed to a new output.
  4. Automatic retry for ambiguous: First query the task, audit, and external artifacts; only after confirming that no side effects occurred may the user approve a retry.
  5. Filling in resources or times from memory: Resource IDs come from the catalog, and times come from probe/ASR/project data; if they cannot be obtained, explicitly block.
  6. Vaguely asking for more information: First provide an executable read-only plan, then explicitly list gaps such as paths, delivery level, or authorization.

Verification checklist

  • CLI identity, version, and capability have been recorded.
  • All input paths, media facts, and hashes can be reviewed.
  • Write targets are isolated from source drafts, and confirmation points are precisely bound.
  • Failure and ambiguous paths retain the task ID, logs, and recovery suggestions.
  • The final wording is consistent with the actual evidence level.

Execution contract

  • Trigger condition: the user is preparing to preview, deliver a draft, generate the final MP4, or check export readiness.
  • Required capability:render.proxy、render.native、runtime.profile。
  • Minimum CLI version:1.6.0; when the native capability or Runtime Profile is not supported, the native path must stop.
  • Default risk:external_native_execution; proxy rendering is a reversible local write.
  • Input facts: draft verification results, delivery type, absolute output path, overwrite policy, Runtime Profile, editor state, and authorization.
  • Confirmation points: precise confirmation before launching Jianying, native export, overwriting output, or using member resources or external services.
  • Success evidence:native_export; proxy artifact can never serve as native_export.
  • Prohibited actions: do not generate Python draft scripts, do not call external headless checkout, do not describe an ffmpeg proxy preview as a Jianying final MP4, or automatically attempt on an unknown Runtime Profile.

Workflow

  1. Execute project verify, and check the materials, subtitles, audio, and output path.
  2. When only a preview is needed, use render proxy or render batch, and make clear that it does not include the complete native effects.
  3. Before native export, require that render.native and runtime.profile are supported, and obtain precise approval.
  4. Persist the native-export task and track progress; when it times out or the result is unknown, mark it ambiguous.
  5. Verify the output container, streams, duration, non-emptiness, and SHA-256, and perform playback spot checks when necessary.

For gates and result determination, see references/workflow.md. For a native export Job example, see examples/minimal-job.json。

Progressive materials