jianying-use

JianYing Use

Route the user's goal to the unified Rust CLI. Gather facts first, then decide whether to directly invoke structured commands or generate jianying-job/v2, or stop and provide diagnostics. Do not make the user learn the full command surface first.

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 an auditable plan, 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 must not be used to handle 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; perform operations in this domain when capability is supported ; 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 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 supported and authorized steps. When output is ambiguous, times out, or partially succeeds, 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; 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; 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 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 be stopped and changed to a new output.
4. For ambiguous cases, automatically retry: 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, 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 the gaps such as path, delivery level, or authorization.

Verification checklist

• CLI identity, version, and capability 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 suggestions.
• The final wording is consistent with the actual evidence level.

Execution contract

• Trigger condition: the user proposes a Jianying draft creation, editing, inspection, recovery, or export goal, but has not yet selected a specific workflow.
• Required capability:doctor、capabilities。
• Minimum CLI version:1.6.0; the version is only used for upgrade prompts, and actual routing is based on capability status.
• Default risk:read_only; after entering a specific write process, the risk level of the target skill is used.
• Input facts: CLI version, capability manifest, material paths, target draft, expected deliverables, and host platform.
• Confirmation point: only when subsequent operations produce writes, costs, or native execution, the target workflow binds the specific call request confirmation.
• Success evidence:structural; successful routing does not mean the draft has been cold-reopened, played, or exported.
• Prohibited actions: do not generate Python draft scripts, do not call external headless checkout, and do not describe low-level evidence as final completion.

Minimal routing

1. Execute jianying --version、jianying doctor --json and jianying capabilities --json。
2. Only ask about facts that would change the plan: whether the goal is to create or edit, material locations, whether a final MP4 is required, and whether external/native execution is allowed.
3. Only callable when capability is supported ;partial、external_dependency or when missing, stop and report the missing evidence or environment.
4. Use jianying-job/v2for creation/editing; prefer using media probe、project inspect、project verify。
5. for read-only probing. Return the actual evidence level achieved and the next manual or host verification.

See references/workflow.mdfor common routing, stop conditions, and recovery methods. For a minimal Job example, see examples/minimal-job.json。

Cross-skill handoff

When domain details are needed, hand off by name and ensure the target skill is installed. For example, hand editing work to jianying-edit. Install: npx skills add full-aigc-skills/jianying-skills --skill jianying-edit。

Progressive materials

• On first execution, load normal path to obtain the end-to-end sequence.
• When encountering failure or unknown status, load failure recovery and error recovery table。
• When the user requests privilege escalation, overwriting, or automatic retry, load boundary refusal。
• Complete verification checklistitem by item before delivery, and do not claim completion based only on a plan or the existence of files.