Compile requirements into deterministic jianying-job/v2, execute via the Rust CLI, and deliver against target evidence.
When to use
- The user explicitly requests the CapCut/JianYing capability corresponding to this skill's title and accepts handling via the unified Rust
jianyingCLI. - The user needs auditable planning, execution, or verification evidence rather than just a conceptual answer.
- When requirements are still unclear, first hand off to
jianying-draft-userouting; 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 actually achieved evidence level. - ⚠️ Requires conditions: 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 invoke 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 permitted 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 inputs
Probe media, drafts, configuration, or task state; reject nonexistent paths, out-of-range times, unknown schemas, mismatched hashes, and approvals that cannot bind 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 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 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 to the command, parameters, target, validity period, and budget; any field change requires re-confirmation.
- User data is processed only within local target paths and declared external Provider boundaries; unrelated credentials must not be collected, uploaded, or logged.
- When current evidence is insufficient, use
UNVERIFIED、BLOCKEDorAMBIGUOUS; do not 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 film acceptance:
project verifyOnly proves the structural layer; playback and native export require independent evidence. - Modifying the source draft directly: First create an isolated copy and record the input hash; any in-place overwrite request must be stopped and changed to a new output.
- For ambiguous cases, automatically retry: first query the task, audit, and external artifacts; retry may be approved by the user only after confirming no side effects occurred.
- Fill in resources or times from memory: resource IDs come from the catalog, times come from probe/ASR/project data; if unavailable, explicitly block.
- Vaguely ask for more information: first give an executable read-only plan, then explicitly list the gaps such as paths, delivery level, or authorization.
Verification checklist
- CLI identity, version, and capabilities are recorded.
- All input paths, media facts, and hashes are verifiable.
- 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.
Runtime contract
- Trigger conditions: the user wants to create a draft from materials, or complete edits 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 of materials and probe results, source draft, isolated output, canvas/FPS, acceptance level.
- Confirmation points: writing to an existing draft, publishing, overwriting output, launching Jianying, or native export are each bound 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 user drafts in place or treat proxy previews as final exports.
Minimal workflow
doctorandcapabilitieshandshake.- Run for each material
jianying media probe <path> --json。 - Ask only about choices that 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 run the cold-reopen, playback, or export gate according to the user's goal.
For full 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 get the end-to-end sequence.
- When encountering a failure or unknown state, load failure recovery and error recovery table。
- When the user requests privilege escalation, overwriting, or automatic retry, load boundary refusal。
- Before delivery, complete each item in verification checklist; do not claim completion based only on a plan or the existence of files.