Compile requirements into a deterministic jianying-job/v2, execute through the Rust CLI, and deliver according to the target evidence.
When to use
- The user explicitly requests the CapCut capability corresponding to the title of this skill and accepts processing through the unified Rust
jianyingCLI. - The user needs auditable planning, execution, or verification evidence, rather than just a conceptual answer.
- When requirements are not yet clear, first hand off to
jianying-userouting; this skill should not be used to handle other editors, general video knowledge Q&A, or speculative execution lacking the necessary materials.
Capability boundaries
- ✅ Can do: Generate a deterministic plan based on real paths and probe results; perform operations in this domain when capability is
supported; output the evidence level actually achieved. - ⚠️ Requirements: Writes must use an isolated copy; fees, external services, and native application actions must have precise approval; playback or export conclusions must have corresponding runtime evidence.
- ❌ Out of scope: Does not automatically install or upgrade the CLI, does not generate Python draft scripts, does not call external headless checkout, does not overwrite source drafts, and does not fabricate resource IDs, media facts, or success status.
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 satisfactory 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. If output is ambiguous, times out, or is partially successful, retain the task ID, audit log, 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 target; report the actual level, failed fields, recoverable actions, and unverified items.
Rules
- The material duration, 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, re-confirm.
- 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、BLOCKEDorAMBIGUOUS; it is forbidden to fill in results by inference.
Gotchas
- Treating version as capability: Always check the specific capability; do not execute directly just because the CLI version is new enough.
- Treating structural validation as final acceptance:
project verifyOnly proves the structural layer; playback and native export require independent evidence. - 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.
- Automatic retry for ambiguous: First query the task, audit, and external artifacts; only after confirming that no side effect occurred may the user approve a retry.
- 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.
- Vaguely asking for more information: First provide an executable read-only plan, then explicitly list the 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.
Run Contract
- Trigger condition: the user wants to create a draft from materials, or complete an edit without damaging the source draft.
- Required capabilities:
job.run、project.create、project.edit_isolated、project.verify。 - Minimum CLI version:
1.6.0; check each capability before execution. - Default risk:
reversible_write。 - Input facts: create/edit mode, absolute paths and probe results of materials, source draft, isolated output, canvas/FPS, acceptance level.
- Confirmation points: writing to an existing draft, publishing, overwriting output, launching Jianying, or native export each binds to a specific target confirmation.
- Success evidence:
cold_reopen; only whenproject verifypasses may you report structural. - Prohibited actions: do not generate Python draft scripts, do not call external headless checkout, do not overwrite the user's draft in place, or treat a proxy preview as the final export.
Minimal Workflow
doctorandcapabilitieshandshake.- For each material, execute
jianying media probe <path> --json。 - Only ask about choices that would change the edit: target name, aspect ratio, keep/delete semantics, subtitle/audio requirements, and delivery level.
- Generate a v2 Job; when editing an existing draft, use
project.type=existingand specify a new output. jianying job run job.json --out <draft> --state-root <state> --json。jianying project verify <draft> --json, then execute the cold reopen, playback, or export gate according to the user's goal.
For the complete create/edit and recovery steps, see references/workflow.md. For an isolated edit example, see examples/minimal-job.json。
Progressive Materials
- On first execution, load normal path to obtain the end-to-end sequence.
- When encountering failure or an unknown state, load failure recovery and error recovery table。
- When the user requests unauthorized access, overwriting, or automatic retry, load boundary refusal。
- Before delivery, complete verification checklistitem by item; do not claim completion based only on a plan or the existence of files.