SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsjianying-draft-audio

jianying-draft-audio

Design & creation

View repository

Updated 10-27 10:06

About this skill

JianYing Audio

Handle the layering and synchronization of dialogue, voiceover, original audio, BGM, and sound effects. Values are based on the source material and audition facts; do not use fixed universal volume levels.

When to use

  • The user explicitly requests the CapCut capability corresponding to the title of this skill and accepts processing through the unified Rust jianying CLI.
  • The user needs auditable planning, execution, or verification evidence rather than only a conceptual answer.
  • When the requirements are not yet clear, first hand them to the jianying-draft-use router; this skill should not be used to handle other editors, general video knowledge Q&A, or speculative execution lacking the necessary source material.

Capability boundaries

  • ✅ Can do: Generate a deterministic plan based on real paths and probe results; when the capability is supported , execute operations in this domain; output the evidence level actually achieved.
  • ⚠️ Prerequisites: Writes must use an isolated copy; costs, 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 the source draft, 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; if 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 satisfied version does not mean a capability is available;partial、external_dependency or missing states must enter a degraded path.

Step 3 — Validate inputs

Probe media, drafts, configuration, or task states; reject nonexistent paths, out-of-range timestamps, 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. On ambiguous output, timeout, or partial success, 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

  • Media 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; any change to any field requires re-confirmation.
  • User data is processed only within 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; it is forbidden to fill in results with 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 final acceptance: project verify Only proves the structural layer; playback and native export require independent evidence.
  3. Directly modifying the source draft: First create an isolated copy and record the input hash; any request to overwrite in place must be stopped and changed to a new output.
  4. Automatically retry on ambiguous: First query the task, audit, and external artifacts; only after confirming that no side effect occurred can 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, block explicitly.
  6. Vaguely asking for more information: First provide an executable read-only plan, then explicitly list the gaps such as paths, delivery levels, or authorization.

Verification checklist

  • CLI identity, version, and capabilities are recorded.
  • All input paths, media facts, and hashes can be reviewed.
  • The write target is isolated from the source draft, and the confirmation point is precisely bound.
  • Failure and ambiguous paths retain the task ID, logs, and recovery suggestions.
  • The final wording is consistent with the actual evidence level.

Run contract

  • Trigger conditions: the user needs to add/replace/relink audio, adjust volume, fade in/out, sound effects, or mixing.
  • Required capabilities:media.audio、timeline.volume、timeline.audio_fade; for TTS also check media.tts_local or media.tts_provider, and one must not be used as a substitute for the other.
  • Minimum CLI version:1.6.0; with missing or partial capabilities, only the supported subset may be executed.
  • Default risk:reversible_write。
  • Input facts: audio stream/duration/sampling facts, target draft copy, track roles, dialogue intervals, loudness targets, and authorization boundaries.
  • Confirmation points: confirm before writing to an existing draft, invoking online/paid TTS, overwriting audio artifacts, or native playback.
  • Success evidence:playback; waveforms, file existence, and structural validation are insufficient to prove the mixing result.
  • Prohibited actions: do not generate Python draft scripts, do not invoke external headless checkout, do not let BGM mask speech, duplicate the original audio, or mark untested results as complete.

Workflow

  1. media probe Confirm that the material contains the expected audio stream and actual duration.
  2. media add-audio/replace/relink Process the material; when the sound comes from video, prefer adjusting the video segment volume.
  3. timeline volume Set the clip's base volume; if the fade in/out capability is not supported, stop this step and clearly state the gap.
  4. When using media sfx , first select by slug from the catalog and check the resource authorization.
  5. For TTS, first confirm the boundary according to four categories: system, local process/HTTP, networked client, and cloud provider; EdgeTTS must not be treated as an offline model, nor may a generic local-process/local-http be treated as evidence that a named open-source model has passed licensing and handshake.
  6. For cloud providers, first execute media tts ... --provider <cloud> --plan; the plan binds only the credential environment variable name, content/request hash, target, task, and maximum budget. Only when the user explicitly requests that provider, the exact approval has been persisted, and the current CLI's execution subpath has passed the handshake may you remove --plan and carry --approval-id to submit; do not construct HTTP requests yourself. media.tts_provider=partial Automatically selecting a cloud provider is still prohibited, as is claiming support for all providers, but a named execution path that has received exact approval must not be misreported as nonexistent. plan, queued, and ambiguous must not be described as synthesized.
  7. project verify then audition dialogue clarity, peaks, transitions, and synchronization.

The narration for film commentary or a README tutorial must first be generated and the real audio probed, then subtitles and ducking arranged according to the actual duration; a fixed BGM volume must not be inherited. Loudness, peaks, dialogue priority and human listening determine the final mix.

For layering, TTS and recovery see references/workflow.md. For isolated editing Jobs see examples/minimal-job.json。

Progressive materials