jianying-draft-motion

JianYing Motion

Express camera movement with keyframes, transforms, animations and speed; confirm the capability first, then generate verifiable edits.

When to use

• The user explicitly requests the JianYing capability corresponding to this skill's title and accepts handling via the unified Rust jianying CLI.
• The user needs an auditable plan, execution or verification evidence, rather than just a conceptual answer.
• When the requirement is not yet clear, first hand it to jianying-draft-use for routing; this skill should not be used to handle other editors, general video knowledge Q&A, or speculative execution lacking necessary materials.

Capability boundaries

• ✅ Can do: Generate a deterministic plan based on real paths and probe results; perform domain operations when capability is supported ; output the actually achieved evidence level.
• ⚠️ 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 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 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 version match does not mean the capability is available;partial、external_dependency or a missing state must enter a 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 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. When output is ambiguous, times out or partially succeeds, retain the task ID, audit logs 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 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 declared external Provider boundaries; unrelated credentials must not be collected, uploaded or logged.
• When current evidence is insufficient, use UNVERIFIED、BLOCKED or AMBIGUOUS, and do not 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 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. Automatically retry ambiguous cases: First query the task, audit, and external artifacts; only after confirming that no side effect 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, explicitly block.
6. Vaguely asking for more information: First give an executable read-only plan, then explicitly list 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 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 conditions: the user requests scaling, translation, rotation, opacity, keyframes, entrance/exit animations, or speed changes.
• Required capabilities:timeline.keyframe、timeline.animation、timeline.quantization_report。
• Minimum CLI version:1.6.0; when any required capability is partial, full execution must not be promised.
• Default risk:reversible_write。
• Input facts: clip ID/duration, source range, project FPS, material resolution, target motion, and allowed quantization error.
• Confirmation point: confirm the target copy and application scope before writing to an existing draft and before native playback verification.
• Success evidence:playback; field persistence and structural verification cannot prove how the motion looks.
• Prohibited actions: do not generate Python draft scripts, do not invoke external headless checkout, do not silently quantize, do not skip edge-exposure checks, and do not falsely claim support when a capability is partial.

Workflow

1. Read clip and material facts, and confirm the source range and the target duration after speed changes.
2. Quantize time points to the project frame grid; stop directly on unsafe offsets.
3. For each property, keyframes strictly increase in in-segment time and stay within the segment length.
4. Express the target with the fewest properties, and check whether scaling/translation exposes edges.
5. Accept progressively through isolated writes, structural verification, cold reopen, and playback.

For recipes, quantization, and failure recovery, see references/workflow.md. When scaling is driven by screen-recording click events, load Smart Zoom Contract; the event ledger and plan only provide reviewable input and do not grant keyframe write permission. Stop if any of key capture, coordinate mapping, or screen-recording summary is unsatisfactory. For isolated editing Jobs, see examples/minimal-job.json。

Progressive materials

• On first execution, load Normal Path to get the end-to-end order.
• 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 Verification Checklistitem by item; do not claim completion based only on a plan or the existence of files.