short-drama-delivery-audit

Validates short-drama video deliveries by auditing provider receipts and probing MP4 durations with ffprobe.

6.8k|540|Updated May 6, 2026
One-click install
npx skills add https://github.com/opensquilla/opensquilla --skill short-drama-delivery-audit
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: short-drama-delivery-audit
Source: https://github.com/opensquilla/opensquilla/tree/main/src/opensquilla/skills/bundled/short-drama-delivery-audit
Command: npx skills add https://github.com/opensquilla/opensquilla --skill short-drama-delivery-audit

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

Before a short-drama workflow publishes its final video, someone must prove that paid image and video generation actually ran against real providers, that no local fallback silently replaced provider output, and that the delivered MP4 files are decodable with the promised durations. This Skill performs that deterministic pre-publish gate without calling a model or contacting any media provider.

Core Features & Use Cases

  • Receipt Verification: Parses sanitized JSON receipts for the reference image and every shot image/video, rejecting placeholders, missing provider request or job IDs, and non-real providers.
  • Paid-Submission Disposition Tracking: Consumes bounded scheduler dispositions (safe_no_submit, maybe_accepted, receipt) plus SHA-256 receipt proofs to decide whether billing status is confirmed, unknown, or safely unsubmitted.
  • Media Probing with ffprobe: Confirms each shot MP4 and the final subtitled MP4 are decodable and match expected content-plus-bookend durations within tolerance.
  • Use Case: A meta-short-drama pipeline finishes rendering; before publishing, this gate emits one JSON verdict (verified, degraded, or blocked) listing issue codes such as VIDEO_FALLBACK_EXECUTED or PAID_SUBMISSION_STATUS_UNKNOWN so the orchestrator can halt or proceed safely.

Quick Start

Run the delivery audit against the short-drama run directory to verify provider receipts and video durations before publishing the final video.

Frequently Asked Questions about short-drama-delivery-audit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify AI-generated video deliveries before publishing?

Run the audit script against the run directory containing script.txt, receipt JSON sidecars, and MP4 files. It parses active shots, validates provider receipts, probes videos with ffprobe, and returns a JSON verdict of verified, degraded, or blocked.

How to check video duration and decodability with ffprobe?

The audit invokes ffprobe with -show_entries format=duration:stream=codec_type,duration and JSON output. It confirms a video stream exists, extracts the maximum finite duration, and compares it against expected shot and final durations within a 0.75-second tolerance.

What does PAID_SUBMISSION_STATUS_UNKNOWN mean in the audit verdict?

It means provider acceptance and billing cannot be proven for that asset because the receipt is missing, malformed, or not bound to the current run by a SHA-256 proof. The verdict advises checking provider history before starting a replacement generation.

Does this audit call the media provider or a language model?

No. The audit is fully deterministic: it never contacts a media provider and never invokes a model. It only reads local script, receipt, and video files, plus bounded scheduler-supplied disposition data passed on stdin.

Why does the audit report RECEIPT_NOT_PROVEN_CURRENT_RUN?

This occurs when a conclusive receipt sidecar exists but its SHA-256 digest was not carried by the exact bundled paid subprocess in the current run. Stale or forged workspace sidecars can never upgrade an asset disposition to confirmed.

What are the limitations of this delivery audit?

It supports at most 10 contiguous shots, requires ffprobe and Python on the host, and only accepts the fixed disposition vocabulary safe_no_submit, maybe_accepted, and receipt. It is an internal machine-owned gate, not user-invocable, and cannot prove billing without current-run receipt proofs.