jianying-setup

JianYing Setup

Read-only diagnostics unify the Rust runtime environment. Installation, upgrade, configuration changes, and launching CapCut are independent actions and must be executed only after the user explicitly requests them.

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 auditable plans, execution, or verification evidence, rather than just a conceptual answer.
• When requirements are still unclear, first hand off to jianying-use routing; 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 deterministic plans based on real paths and probe results; execute operations in this domain when capability is supported ; output the evidence level actually achieved.
• ⚠️ Requires conditions: Writing 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: 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 satisfied version does not mean the capability is available;partial、external_dependency or a missing state must enter the degradation path.

Step 3 — Validate input

Probe media, drafts, configuration, or task status; 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 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, 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

• 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, 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, and 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 stop and be changed to a new output.
4. For ambiguous, retry automatically: First query the task, audit, and external artifacts; only after confirming that no side effects occurred can the user approve a retry.
5. Filling in resources or time 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 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.

Runtime Contract

• Trigger conditions: the user needs pre-installation checks, environment diagnostics, version/capability handshake, or Runtime Profile troubleshooting.
• Required capabilities:doctor、runtime.status。
• Minimum CLI version:1.6.0; even if the version is satisfied, capabilities still need to be checked item by item.
• Default risk:read_only。
• Input facts: CLI absolute path and hash, host platform, ffmpeg/ffprobe, draft root, configuration profile, Jianying process, and Runtime Profile.
• Confirmation points: confirm the specific action and target separately before installation, upgrade, configuration modification, or starting/stopping Jianying.
• Success evidence:structural; doctor passing does not prove real Jianying compatibility or native export.
• Prohibited actions: do not generate Python draft scripts, do not call external headless checkout, and do not automatically install, top up, launch applications, or downplay unsupported status.

Diagnostic Flow

jianying --version
jianying doctor --json
jianying capabilities --json
jianying runtime status --json
jianying config validate --json

1. Record the binary path, version, and SHA-256 that were actually invoked.
2. Report missing tools, a missing draft root, a running editor, and an unknown Runtime Profile separately.
3. capability is not supported When this is set, output the required minimum capability and recovery suggestions, and do not automatically select an alternative engine.
4. If installation or repair is needed, first cite the official source for the current platform and explain what will be modified.

For field explanations and troubleshooting order, see references/workflow.md. For a read-only Job example, see examples/minimal-job.json。

Progressive Materials

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