jianying-draft-transitions

JianYing Transitions

A transition is a semantic connection between adjacent segments. Verify boundaries and assets first, then decide whether to use it.

When to use

• The user explicitly requests the CapCut capability corresponding to this skill's title and accepts processing via the unified Rust jianying CLI.
• The user needs auditable planning, execution, or verification evidence, not just a conceptual answer.
• When requirements are not yet clear, first hand off to jianying-draft-use routing; this skill should not be used for other editors, general video knowledge Q&A, or speculative execution lacking necessary assets.

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 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 call external headless checkout, do not overwrite source drafts, and do not fabricate asset 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; if 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 the capability is available;partial、external_dependency or a missing state must enter the degraded path.

Step 3 — Validate inputs

Probe media, drafts, configurations, or task states; 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 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

• Asset 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; any field change requires re-confirmation.
• User data is processed only within the local target path 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; filling in results by inference is prohibited.

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 finished-film acceptance: project verify Only proves the structural layer; playback and native export require independent evidence.
3. 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.
4. Automatically retry on 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; if they cannot be obtained, block explicitly.
6. Vaguely asking 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 capability have been 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 the task ID, logs, and recovery suggestions.
• The final wording is consistent with the actual evidence level.

Run contract

• Trigger conditions: the user requests transitions, shot continuity, beat sync, or queries available transition resources.
• Required capability:timeline.transition、media.catalogue。
• Minimum CLI version:1.6.0; when transition is partial, only generate a plan and diagnostics.
• Default risk:reversible_write。
• Input facts: adjacent segment IDs, durations/handles, beat or chapter boundaries, resource catalog status, and authorization.
• Confirmation points: confirm before using member/restricted resources, writing to an existing draft, or performing native playback.
• Success evidence:playback; a catalog hit or the presence of a wire field is not acceptance of the visual result.
• Prohibited actions: do not generate Python draft scripts, do not call external headless checkout, do not add transitions to the final segment, do not overuse every cut point, and do not treat cache existence as authorization.

Workflow

1. Use media catalog to search names; fabricating resource IDs from memory is prohibited.
2. Check the adjacency relationship, durations, and available handles of the preceding and following segments.
3. Transitions attach to the outgoing segment, and their duration must not exceed the available window on both sides.
4. When the capability is not supported, output a suggested plan and do not write to the draft.
5. Once supported, write to an isolated copy and check rhythm, black frames, and missing resources via cold reopen and playback.

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

Progressive materials

• On first execution, load normal path to obtain the end-to-end sequence.
• When encountering failures or unknown states, 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.