SuperAPI AI Directory

jianying-audio

Design & creation

View repository

Updated 10-16 08:48

About this skill

JianYing Audio

Handle the layering and synchronization of dialogue, narration, original audio, BGM, and sound effects. Values are based on the 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 a unified Rust jianying CLI.
  • The user needs auditable plans, execution, or verification evidence, not just a conceptual answer.
  • When the requirements are not yet clear, first hand off to jianying-use routing; this skill should not be used to handle other editors, ordinary video knowledge Q&A, or speculative execution lacking the necessary material.

Capability boundaries

  • ✅ Can do: Generate a deterministic plan based on real paths and probe results; execute operations in this domain when capability is supported ; output the evidence level actually achieved.
  • ⚠️ Conditions required: 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 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 satisfied version does not mean a capability is available;partial、external_dependency or a missing state must enter the degraded path.

Step 3 — Validate input

Probe media, drafts, configuration, or task status; reject nonexistent paths, out-of-bounds times, unknown schema, 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 restart, playback, or native export evidence according to the target; report the actual level, failed fields, recoverable actions, and unverified items.

Rules

  • The material duration, dimensions, streams, hashes, and draft version 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 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 final acceptance: project verify It only proves the structural layer; playback and native export require independent evidence.
  3. Modifying source drafts 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 no side effects occurred can the user approve a retry.
  5. Filling in resources or times from memory: Resource IDs come from the catalog, times come from probe/ASR/project data; when unobtainable, explicitly block.
  6. Vaguely asking for more information: First give 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 are reviewable.
  • Write targets are isolated from source drafts, and confirmation points are precisely bound.
  • Failure and ambiguous paths retain task ID, logs, and recovery suggestions.
  • Final wording is consistent with the actual evidence level.

Operating Contract

  • Trigger conditions: the user needs to add/replace/relink audio, adjust volume, fade in/out, add sound effects, or mix.
  • Required capability:media.audio、timeline.volume、timeline.audio_fade。
  • Minimum CLI version:1.6.0; with missing or partial capability, 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 networked/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, and do not let BGM mask speech, repeatedly lay down the original audio, or mark untested results as complete.

Workflow

  1. media probe Confirm the material contains the expected audio stream and real 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; when the fade in/out capability is not supported, stop that step and clearly state the gap.
  4. When using media sfx , first select from the catalog by slug and check resource authorization.
  5. Local TTS only invokes a Provider explicitly provided by the user; cloud submissions must go through the cost ledger and precise approval.
  6. project verify then audition dialogue clarity, peaks, transitions, and synchronization.

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

Progressive Materials