Read material and draft facts without changing files. All subsequent plans should reference the results of this probe.
When to use
- The user explicitly requests the 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 the requirement is not yet clear, first hand it 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 evidence level actually achieved. - ⚠️ Requires conditions: Writes must use isolated copies; costs, external services, and native app 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 statuses.
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 satisfying version does not mean the capability is available;partial、external_dependency or a missing status 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 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 goal; 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; any change to any field requires re-confirmation.
- User data is processed only within local target paths and the 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 with 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-cut acceptance:
project verifyThis only 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 stop and be changed to a new output.
- Automatically retry ambiguous cases: First query the task, audit, and external artifacts; only after confirming no side effects 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, explicitly block.
- 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 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 wants to view media information, draft structure, version, diff, reference integrity, or verification level.
- Required capability:
media.probe、project.inspect、project.verify。 - Minimum CLI version:
1.6.0; record the actual version and capability status in the result. - Default risk:
read_only。 - Input facts: absolute paths of the media or draft, target check questions, expected evidence level, and host platform.
- Confirmation points: read-only checks require no confirmation; cold reopen, playback, or native export are independent external actions.
- Success evidence:
structural; unless actually executed, it cannot be upgraded to cold_reopen/playback/native_export. - Prohibited actions: do not generate Python draft scripts, do not call external headless checkout, do not modify drafts, do not treat file existence as content correctness, and do not use planned duration to pass off as measured duration.
Workflow
jianying media probe <media> --jsonObtain duration, dimensions, streams, and type.jianying project info|version|inspect <draft> --jsonObtain a stable digest.jianying project verify <draft> --jsonCheck reference, timeline, and bundle integrity.- When comparison is needed, use
project diff, and specify which differences are expected edits. - Report facts, failed fields, and the current highest evidence level.
For the checklist and the meaning of evidence, see references/workflow.md. For read-only Jobs, see examples/minimal-job.json。
Progressive materials
- On first execution, load normal path to get the end-to-end sequence.
- When encountering failures or unknown states, 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; do not claim completion based only on a plan or file existence.