SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsjianying-draft

jianying-draft

Design & creation

View repository

Updated 10-15 21:47

About this skill

JianYing Draft

Used to construct or review structured Jobs/Plans; not responsible for bypassing the CLI to directly write draft protocols.

When to Use

  • The user explicitly requests the CapCut 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, rather than merely a conceptual answer.
  • When requirements are not yet clear, delegate to jianying-use routing first; this skill should not be used for other editors, general video knowledge Q&A, or speculative execution lacking 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: Writes must use isolated copies; costs, external services, and native application actions require 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 statuses.

Step 1 — Establish a Fact 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 status 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 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 log, and artifacts, and do not automatically retry.

Step 6 — Verify and Deliver

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

Rules

  • Material durations, dimensions, streams, hashes, and draft versions in the plan must come from tool output.
  • Approval must bind 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 boundary; unrelated credentials must not be collected, uploaded, or logged.
  • When current evidence is insufficient, use UNVERIFIED、BLOCKED or AMBIGUOUS; do not fill in results with inferences.

Gotchas

  1. Mistaking version for capability: Always check the specific capability; do not execute directly just because the CLI version is new enough.
  2. Mistaking structural validation for final acceptance: project verify It 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 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 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, 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 are reviewable.
  • Write targets are isolated from source drafts, and confirmation points are precisely bound.
  • Failure and ambiguous paths retain the task ID, logs, and recovery recommendations.
  • The final wording is consistent with the actual evidence level.

Runtime contract

  • Trigger conditions: the user needs Job/Plan Schema, domain objects, timeline structure, v1 compatibility, or version diagnostics.
  • Required capabilities:schema.job_v2、schema.plan_v1_compat。
  • Minimum CLI version:1.6.0; a capability handshake is still required before submission.
  • Default risk:read_only; generating only a plan produces no draft side effects.
  • Input facts: target operation, new or existing draft, canvas/FPS, material probe results, track and clip temporal relationships, expected evidence.
  • Confirmation point: plan compilation requires no confirmation; when executing the plan, confirmation is bound by the specific write or external operation.
  • Success evidence:plan; passing Schema validation does not equal passing draft structure or real Jianying verification.
  • Prohibited actions: must not generate Python draft scripts, must not call external headless checkout, and must not directly spell out private wire fields that have not been validated by Schema.

Core rules

  • The root schema is jianying-job/v2, and operations are create/edit/inspect/verify/publish/export/batch.
  • Time uses integer microseconds; frame-sensitive positions must also comply with the project FrameRate quantization result.
  • New projects use project.type = new; existing drafts use existing, and an isolated output must be provided when writing.
  • Materials are first media probe --json, do not use designed duration in place of measured facts.
  • v1 input can only be placed in the compatibility envelope, and the CLI converts it and returns field-level diagnostics.
  • Unknown schemas, breaking versions, or missing capabilities must fail structurally.

For the field model, operation selection, and verification levels, see references/workflow.md. For an executable minimal example, see examples/minimal-job.json。

Progressive materials