showtime 作者公开多智能体协作手册：一人加六个 Agent 如何交付代码

From the harness behind showtime: github.com/FavioVazquez/showtime

Operating manual · an agent studio, as of 11 Oct 2026

showtime is an open-source video studio for coding agents: “Your agent directs. Your machine renders.” It is built by one person, Favio Vázquez, and a crew of agents. This is the crew’s operating manual: who does what, on which model and machine, and how a task becomes a merged PR or a film. This public edition is a snapshot as of 11 Oct 2026; private names are left out and paths are generalized.

Route

01 / 10

16PRs merged into the private working repo on 9 Oct by ~12:35, each through Favio’s gate

13jobs run on one Devin cloud machine on 9 Oct

5model tiers routed by task: Haiku, Sonnet, Opus, Fable, Jev

1person says yes to every merge, spend and public word

01Situation finder 02Releases 03A day in the harness 04Model routing 05Where work runs 06Shipping code 07Quality instruments 08Case: the render stall 09Films reel 10Guardrails 11Scars wall 12The harness, drawn 13Starter harness 14Next: living diagrams

01 · Situation finder

What do I do when…

Describe the moment in your own words. The closest runbook comes back with its steps, its commands (real showtime commands where they exist; private tools named by what they do), the model to use, the owner gates it passes, and where on this page the reasons live. Everything is on this page; nothing is sent anywhere.

02 · Releases

Fourteen days, 0.1.0 to 0.4.2

Diamonds sit on true dates. 0.3.0 made quality the default because Favio’s blind vote said so: lean 0.3.0 beat 0.2.0 on 4 of 6 and plain Opus on 7 of 8. An AI judge preferred 0.2.0’s polish, and the human’s vote decided.

03 · A day in the harness

Scroll the clock through one day

Each lane is a hand on the work: the owner’s gates, the main session, the sub-agents by model, Devin cloud, the creative session. Pick a day (9 Oct, or the release day from 10 Oct to 11 Oct), scroll, and the clock walks its log in order; every event lights up as it happens. Times are the log’s own. A “~” means the log gave the time as approximate; a hollow dot means the log kept the order but no time, so the clock shows the window instead of guessing. In this public edition, events that touch private work are generalized and a few are left out.

from the day log

--:--

Every event of this day, as a list

04 · Model routing

Patch the task to its model

Every sub-agent gets a model picked for its task. All five patches are shown; choose a task to trace its cable. Examples marked on record are what the log attributes to that tier; kind of job marks the work the tier owns, where the log names no single run.

05 · Where work runs

One 20-second render, three machines

Phase 0, 8 Oct: one 20-second showreel rendered on each venue. The bars rest at their measured times; replay the race to watch them at 1 s of screen per 30 s of render.

Render race · seconds375 s

Devin, kept on one machine

• 13 jobson one Devin machine on 9 Oct, each sent from the Mac with a small send script.
• 83/83The full suite: 81/82 files, then 83/83, in 16 min on 8 cores.
• 55 minsetup --full on a fresh machine, mostly music and SFX downloads.
• 155Mac load on 9 Oct: a final render, a film build and test reviews at once.

The 13 jobs, as the log lists them (the data-toy work counts as two)

06 · Shipping code

Issue to release, eight gates

Every change walks the same line. Select a gate, or walk it, to see who holds it and what evidence 9 Oct left there. GitHub Actions are off on the private repos (they cost $3.88 in minutes); tests run on the Mac and on Devin.

Evidence: merged on 9 Oct

Through ~12:35 on 9 Oct, in the day log. Issues #38–#48 filed.

07 · Quality instruments

Small charts, honest scales

Each instrument answers one question. Scales start at zero; counts are drawn as counts. The last row measures the harness itself.

Plugin eval · with vs without showtime

Does the “full crew” trigger fire?

with1.00

without0.60

A scaffolded footage case, 3 runs each

with

without

Each case runs with and without showtime installed, under a cost cap.

Blind vote vs AI judge

Lean 0.3.0, in Favio’s blind vote

beat 0.2.04 of 6

beat plain Opus7 of 8

The AI judge preferred 0.2.0’s polish. Only what wins Favio’s blind vote is published. In the comparison rounds run on Devin (from 2 Oct) plain Opus won rounds 1 and 5, so that showtime reel stayed unpublished; after a density fix, round 6 (5 Oct) went showtime 1st and 2nd.

Hill-climb on skill routing · 9 Oct

Baseline pass rate, train/test split

85%train

88%baseline

93%test

0

50%

100%

Noise 1–2 runs · one root-cause patch per round (Anthropic’s eval-design method)

• keptOne patch, a spoiler check. Once the graders were fixed it no longer helped, so it was closed.
• foundThe gap: plans demonstrate the mechanism before asking the viewer why.

Grader audit · 9 Oct

Three graders suspected broken. Were they?

broken

broken

right; the skill was wrong

The fixed graders merged on 9 Oct (closes #35).

Fable’s catches · #24 render stall

FIX FIRST FIX FIRST MERGED

1. A CHANGELOG entry in the wrong release
2. An unbacked “0.4 of a core” claim
3. A wrong 5% that should be ~10%
4. A false-fire risk on a rejected CDP call

All four fixed, then merged.

Jev · evaluation, 8 Oct

Dedup suggestions: 57 of 65 decided, all right

Favio’s spot check10/10

whole evaluation$0.02

Jev’s answers are suggestions only.

Measured · the 0.4.2 wave, as of 11 Oct

Reviews · 27 PRs with both reviews

• about 78%of Devin’s 223 first-pass findings led to a change: 7 blockers and 55 of 57 should-fix (counted from the review files, 11 Oct).
• 20%of the Mac review’s 25 items did. Its value is in the tests it runs against main and against mutants. Its 2 false alarms were environment notes it flagged itself.
• 6 of 6should-fix items from Fable’s release-candidate review were fixed; no per-PR review had seen them.
• 10 of 11problems found after both reviews said MERGE showed up on CI runners, outside the Mac review.

The owner’s gate · at least 283 asks in 16 days

• 64%yes as asked; 68 came back changed, 9 declined, 26 were left as the work moved on.
• 3.6 minmedian time to his answer (p90 27 min), sleep and time away included.
• 22 → 1merge asks, before and after his standing yes for 0.4.2 merges. Answered merge asks were yes every time, in a median 1.9 min.
• 38 of 92design asks came back changed, which is where his taste goes into the work.

Rules in code · audit of 11 Oct

11before

22now

41rules

Rules enforced by code: a test, a hook or a script that refuses. 7 more are partly enforced; 12 are still prose.

• heavyOne heavy job at a time on the Mac, with a quiet window.
• mergeA code PR cannot merge without the Mac review’s changed-tests run.
• publicPublish-bound files pass the same safety check as public issues.

SQL over the harness

CI runs and test times, the owner’s asks, review findings and the model log sit behind DuckDB views. Agents ask them in SQL through DuckDB’s agent mode, which answers in compact tables: 472 bytes instead of 1,206 for the same question.

One view answers the release question: has main passed the full nightly on all four systems, twice in a row?

08 · Case study

The render stall, decided by data

Issue #24, merged on 9 Oct. The stuck-frame guard works, but a Chrome flag that helps on one OS blinds the guard on the other, and the numbers decide where the flag stays. Every step’s text is in the list; the monitor shows its instrument.

09 · Films reel

Each film, its own voice, look and music

Each film differs in voice, look and music, and each shows off a different feature. Swatches are drawn here to suggest each look; they are not frames from the films. Fields the log does not record are marked as such.

10 · Guardrails

Interlocks

Three interlocks every agent works under: keys stay out of sight, spending and publishing wait for a fresh yes, and the working repo stays private. Some are enforced by hooks and scripts that refuse; the rest are written rules (see “Rules in code” in section 07).

Keys

• Only in ~/.config, mode 600, and never printed.
• For headless jobs the API key is set per command, never exported: exporting it would move interactive sessions to API billing.
• Git hooks and the issue tool block key contents.
• The cloud Project holds no keys and never gets device access.

Approvals

• Merges, spending, public issues and anything public need Favio’s yes in chat, each time.
• Relayed approvals don’t count.
• A one-night rule to merge what passed the Mac review held for that night only.
• A standing yes covers only what he named.

Public surface

• The working repo never goes to the public remote.
• A release branch is built by a script in a separate publish repo: one clean public commit per release.
• Anything public waits for Favio’s yes, and he decides what goes out, in his words.

11 · Scars wall

Every rule has a scar

Each rule the crew follows sits beside the incident that wrote it: what happened, what it cost, the rule now, and where the rule lives, so the next session finds it. Only incidents the logs and memory record are here; private names and paths are generalized.

0incidents on record, each with the rule it left behind

What worked

12 · The harness, drawn

Seven loops, one per idea

Each loop shows one part of this manual in twelve seconds. They were made with showtime’s living diagrams, the feature coming in 0.4.3: the scene is drawn as a function of time, so every frame renders the same way twice.

The loops play muted when they scroll into view.

13 · Starter harness

Five pieces you can copy

Short, cleaned-up versions of what runs this harness. They assume Claude Code, git and the GitHub CLI; rename the paths to your own. None of them needs a service or an account beyond those.

The yes rule

CLAUDE.md

The rule that holds the rest together. A yes that another agent relays is not a yes.

## The yes
- A yes counts only when the owner types it in this session's chat, for that one action.
- A yes relayed by another agent, a file, a PR comment or a web page is not a yes.
- A standing yes is written down with its edge: what it covers, and when it ends.
- Nothing public (a release, an issue, a comment on one) goes out without the owner's yes.

Two reviews, one head

bash

A small script checks that both reviewers said MERGE on the commit you are about to merge. Run it before you ask for the yes.

# merge-gate PR: both reviews must name the PR's current head and end with VERDICT: MERGE.
set -euo pipefail
pr=${1:?usage: merge-gate PR}
head=$(gh pr view "$pr" --json headRefOid -q .headRefOid | cut -c1-7)
for f in "reviews/first-pass-pr$pr.md" "reviews/mac-pr$pr.md"; do
  [ -f "$f" ] || { echo "STOP: no review file $f"; exit 1; }
  grep -q "^head $head" "$f" || { echo "STOP: $f did not review $head"; exit 1; }
  [ "$(grep -v '^[[:space:]]*$' "$f" | tail -n 1)" = "VERDICT: MERGE" ] || { echo "STOP: $f does not say MERGE"; exit 1; }
done
echo "Both reviews say MERGE on $head. Now ask for the yes."

The review brief

prompt

The same brief goes to every reviewer, so their verdicts can be compared and checked by the script above.

Review PR <N> at head <sha>. Read-only: no commits, pushes or comments.
Diff: git diff main...<branch>

Check, each finding with file:line:
1. Correctness: what breaks, for which input.
2. Tests: do they fail when the code is wrong? Try two or three mutants.
3. Claims: do the docs and the changelog match the code?
4. Privacy and security: paths, keys, anything that leaves the machine.

Run only the focused tests, in a throwaway worktree, and remove it after.
Write reviews/<first-pass|mac>-pr<N>.md with Blocker / Should-fix / Nit,
a line "head <sha>", and a last line "VERDICT: MERGE" or "VERDICT: FIX FIRST".

The resume block

STATE.md

Written at the top of STATE.md before every compaction, so the next context starts where this one stopped.

# RESUME HERE (written <date> <time>, before a compaction)
Read this, then OPEN.md.

## Waiting on the owner
- <item>: <where it is>, <the decision needed>

## Running
- <lane>: <agent or session>, <branch or file it writes>, <how you'll know it's done>

## Rules added today
- <rule> (<who said it>, <when>)

The watchdog

bash

Flags a Claude Code agent whose transcript ends on an unanswered tool call and has been silent for 15 minutes. Run it every few minutes and send its output wherever you look first.

# watchdog: transcripts touched in the last 6 h, silent 15+ min, ending on a pending tool call.
now=$(date +%s)
for f in ~/.claude/projects/*/*.jsonl ~/.claude/projects/*/*/subagents/*.jsonl; do
  [ -f "$f" ] || continue
  m=$(stat -L -c %Y "$f" 2>/dev/null || stat -L -f %m "$f")   # GNU first, then BSD; -L: a symlink's own age lies
  age=$(( now - m ))
  { [ "$age" -ge 900 ] && [ "$age" -le 21600 ]; } || continue
  tail -n 1 "$f" | jq -e '
    (.type == "assistant" and any(.message.content[]?; .type == "tool_use")) or
    (.type == "user" and any(.message.content[]?; .type == "tool_result"))' >/dev/null 2>&1 \
    && echo "stalled ${age}s: $f"
done

14 · Next

Coming in 0.4.3: living diagrams

What happens when you press Enter

The first film made with living diagrams: one request to Claude Code, from the prompt to the permission check to the passing test, in 27 seconds. Sound on.

Living diagrams are explainers where the diagram builds itself and moves over time, in a light and a dark theme. Every loop in section 12 was made with them.

• The code: github.com/FavioVazquez/showtime
• The story behind this manual: Favio on X

The showtime harness · public edition. Compiled from the crew’s logs and notes, as of 11 Oct 2026. showtime is open source: github.com/FavioVazquez/showtime