video-jury

Video Jury

One job: seven judges, one video, one honest verdict before you post. Claude never posts, edits or deletes anything. You decide.

The tools actually run: scripts/prep.py and scripts/verdict.py are plain Python (standard library only) and need ffmpeg installed. prep.py turns the video into an evidence pack: frames, contact sheets with the time printed on every tile, picture-change times, loudness numbers, a spectrogram and the transcript. verdict.py counts the votes and groups the findings. Both live in this skill's own folder (usually ~/.claude/skills/video-jury/), so call them by full path. If code execution is off, say the jury cannot run, because a judge that has not seen frames is guessing.

Steps

1. Intake. Get the video path. Ask once, in one short message, for anything they have: the cover image, the caption text, a transcript or word timings. None are required. Run python scripts/prep.py --check; if ffmpeg is missing, give the install line it prints and stop.
2. Build the evidence. Work in ./video-jury/<video name>/ in the user's current folder (ask before creating ./video-jury/ the first time): python scripts/prep.py VIDEO --out ./video-jury/<name>/pack [--cover IMG] [--caption TXT] [--words JSON | --transcript TXT] Tell the user what the pack is missing (the limits it prints).
3. Seat the jury. Read references/judges.md. Launch seven subagents in one message, one per judge, so they run at the same time. Each one gets only: the shared rules, its own section, the answer shape, the pack folder, and where to save its answer (./video-jury/<name>/run-1/<judge>.json). Never give a judge the maker's notes, another judge's answer or your own view. If you cannot launch subagents, run the seven lanes one after another yourself, each from the pack only, and tell the user the judges were not blind to each other.
4. The foreman. Run python scripts/verdict.py ./video-jury/<name>/run-1. Show the vote table exactly as printed. Then give at most five fixes in plain words, most agreed first, each with its second and the judge or judges who raised it. List what the judges said not to change and what they could not judge.
5. Run it again (offer once). Votes move between runs: in the maker's own test the same video got 2 POST and 5 FIX, then 4 POST and 3 FIX, then 1 POST and 6 FIX. So the count is a guide, and the notes that come back are the verdict. If they say yes, repeat step 3 into run-2 and run python scripts/verdict.py --compare ./video-jury/<name>/run-1 ./video-jury/<name>/run-2. Read each matched pair and confirm it is the same problem before calling it confirmed.

Hard rules

• Never post, schedule, upload, edit, trim or delete the video or anything else. The jury only reads.
• No judge can hear or play the video. Never write as if one did. Sound is judged by meters.
• No finding without a time and a file. Open the frame and look before repeating a finding to the user.
• Do not soften a verdict, add your own findings to the count, or predict views, reach or revenue.
• One job per judge. Do not merge lanes to save time, and do not let judges see each other.
• Everything stays in ./video-jury/ on the user's computer. Send it nowhere.
• Say plainly that seven judges reading frames uses a lot of usage (800,000 to 900,000 tokens per run on a one-minute video in the maker's tests), before the first run and before a second one.

What to hand back

The decision line (POST, FIX FIRST or HOLD) with the vote count, the vote table, up to five fixes with their seconds, the "do not change" list, what could not be judged, and the path to VERDICT.md. End with one question: "Want me to run the jury a second time to see which notes come back?"