create

Turn a brief into a finished motion piece (default 1080×1920 vertical; landscape/square also available) through the 甲乙环 (critic-loop) pipeline. Quality is produced by a unified design-and-build agent working in one continuous context — each draw seeded with its own idea-level direction, judged on its actual rendered frames, picked at its r1 preview (by the user, or by a blind selector), self-checked, then polished — by the critic loop, or by the user's own eye — with the user's eyes as the final gate.

You (the agent reading this skill) are the orchestrator. You spawn the sub-agents, run the render tooling, and ferry critic verdicts verbatim — you do NOT design, and you do NOT judge aesthetics. Every role prompt and protocol reaches the sub-agents by them Reading the verbatim definition/protocol files — never by you paraphrasing them.

The one rule that protects everything: do not summarize any role definition or protocol (the builder, the direction lister, 甲, the blind selector) in your own words. Wording only binds an agent when that agent has the literal text in its context. Always delegate by Read (${CLAUDE_PLUGIN_ROOT}/…), never by retelling.

Inputs

The pipeline needs a brief and a spec before any draw. Collect both in Step 0 (below); for any you can't get, propose a sensible default and let the user accept it in one line.

• brief: the piece's job, as the user gives it (audience, takeaway, tone — whatever they choose to write). Required. If there is none, ask for it.
• spec — the finished-video parameters:
  • aspect / resolution: vertical 1080×1920 (default — social/portrait), landscape 1920×1080, or square 1080×1080. Propose vertical as the default; the user may pick another.
  • duration — offer it as a choice, not a blank (see Step 0): a couple of sensible second-counts for this brief, "I'll name one", or "don't constrain it — the designer decides". Whichever second-count the user picks or states, it is locked; only the explicit "don't constrain it" option makes it free. This authority goes to the builder with the spec, and holds through every later step.
  • fps (default 30).
  • on-screen copy: is there required text/wording, or is it the designer's call?
  • audio intent: sound is on by default — simple sound effects the builder makes or sources itself; the user may turn it off. The pipeline adds no full music or voice-over by default; the user can ask for them (see extra requests). Every judgment in the pipeline is visual-only (nothing in self-check, the blind select or the 甲乙环 judges sound); only the user's own ears do, when they watch the previews and the finished piece. Say so when you state the default. The minimal tool-chain pointer for sound is: consult the remotion-best-practices skill's remotion-markup node (audio.md / sfx.md — <Audio>, remotion.media remote SFX) for what the engine supports, and source CC0 assets yourself — the plugin ships a small pack of recorded CC0 sounds (assets/sfx/, listed in its index.json; the builder's definition says where), and the pipeline validates no audio. (Note: sfx.md uses @remotion/sfx, which is deliberately NOT in the base dep set — audio being experimental, the builder installs it on demand with npx remotion add @remotion/sfx, which resolves the version matching the prepared engine.)
• target-project port (only if asked): if the user intends to port the finished piece back into an existing Remotion project rather than ship the standalone workspace render, ask for that project's Remotion version and whether it has three / @remotion/media installed up front. The workspace automatically prepares the latest stable Remotion + three before drawing; an older/leaner target can drift on API, so knowing the target version before drawing avoids a port-time surprise. (Porting is a user-side activity the pipeline doesn't itself verify.)
• extra requests (only if the user volunteers them): anything beyond these defaults — voice-over through an open-source TTS or one the user provides, their own music, logo, fonts or footage, a library they want used, another delivery format. Defaults are not limits. Record the request as given in COMMISSION.md and carry it in the brief, so the direction-lister and every builder receive it; the builder works out how, installing what it needs. If something truly can't be done in this environment, say so plainly and let the user decide — never refuse it only because the defaults don't mention it. Say what the pipeline can't check: sound, voice included, is judged only by the user's own ears. A credential the user provides (an API key) reaches the builder through the environment, never written into a file. Don't quiz the user for extras.
• N (draws): independent draws before the pick. Default 3. (More draws = higher ceiling; N is the user's knob.) Each draw is dealt its own idea-level direction (Step 1.5), so the N previews are genuinely different options.
• who picks the base: the user (default) — they watch each draw's preview (its r1 video) and pick the base; or 交给 AI 挑 — the blind-selector agent picks on the same previews. Either way the pick happens at r1, before any self-check.
• who polishes the picked piece: the critic loop (default — 全自动: hands-off, safe; a design-blind critic and the builder iterate until the critic converges, then the user sees the result) or 亲自打磨 (optional, for users who want to judge the finish themselves — the critic loop is skipped; the user watches the self-checked piece, and whatever they say about it is ferried verbatim to the same builder, round after round, until they accept it).
• workspace: a user-side project dir (NOT under the plugin). Default ./<piece-slug>/ in the user's CWD.

The critic loop has no round knob — it runs until 甲 reports CONVERGED: YES, then the user's eyes are the final gate.

Step 0 — Commission (gate; collect before any draw)

A real run starts from the user, not from a guess. Before scaffolding or drawing, confirm the commission — the brief, the spec, and the production knobs from Inputs. Do not start drawing until this is settled.

1. Brief — if there is no brief, ask for one. Take it as the user wrote it: don't quiz them for an audience, takeaway or tone they left out.
2. Spec — settle each parameter. For anything the user didn't state, propose a default and let them accept or change it in one line (don't silently assume):
   • aspect/resolution (default vertical 1080×1920; offer landscape 1920×1080 / square 1080×1080),
   • duration — ask it as a pick-list, and record which of two authorities results. Don't leave it as a blank to type into: put the options in front of the user (AskUserQuestion is the right instrument) — two or three second-counts that suit this brief, "I'll name one", and "don't constrain it — leave the length to the designer". Then record:
     • locked — the user picked or stated a second-count. Any number the user put their name to is locked, whether you proposed it or they volunteered it; accepting your proposal is choosing. It is a promise to the user, and no later step may change the total length.
     • free — the user explicitly chose "don't constrain it". The builder still hard-wires a concrete durationInFrames (the engine needs one), but that number is 乙's own internal decision, never aligned with the user — so it is not a promise, and 乙 may change it later. Same for any second-count 乙 writes into DESIGN.md: it's a one-shot draft value, not a constraint.
     • Carry this flag verbatim to every builder (Step 2). If in doubt, it is locked — never silently promote a user's number to "adjustable".
   • fps (default 30),
   • on-screen copy (required wording vs. designer's call),
   • audio intent — default on: simple sound effects the builder makes or sources itself. Tell them plainly that nothing in the pipeline but their own ears judges sound (see Inputs). They may turn it off, or ask for more — voice-over, their own music (extra requests).
3. Knobs — surface the production knobs too; don't bury them as silent defaults:
   • N (draws before the pick) — default 3. This is the user's knob (more draws = higher ceiling, more cost/time). State the default and let them raise/lower it. Never silently pick N — the gate exists precisely to surface the user's decisions.
   • who picks the base — ask it as a choice: the user picks (default — once all N previews are ready they watch each draw's r1 video and choose) or 交给 AI 挑 (the blind selector picks on the same r1 previews). Record the choice. If the user chose to pick, they can still say "你替我挑" at pick time and the blind selector picks instead (Step 3).
   • who polishes the picked piece — ask it as a choice: the critic loop (default — hands-off) or 亲自打磨 (the user judges the finish themselves; their comments go verbatim to the builder until they accept). Record the choice. If the user left it to the loop, they can still voice what they don't like at the final gate (Step 5), and that switches the piece to 亲自打磨 from there.
   • workspace — where the piece is built; default a <piece-slug>/ folder in the user's CWD. Offer to change it.
   • extra requests — take any the user volunteers (see Inputs) into the brief; don't quiz them for more.
4. Confirm back the resolved commission in one short summary (brief + final spec + duration authority: locked ⟨Ns⟩ / free + N + who picks + who polishes + workspace + any extra requests), saying how you read anything the user left open (a slogan they gave in one language for a piece in another, say: who words it). The user's answers to your questions are not the confirmation: send the summary as its own message and wait for their reply before writing anything or starting Step 1; a reply that changes nothing ("ok", "go") confirms it. Then write it to <WORKSPACE>/<piece-slug>/COMMISSION.md, together with the model ID you are running on and the model each sub-agent role runs on (they inherit yours unless their definition overrides it) — a run is only comparable to another if you know which model made it. If the user said "just go / your call", fill every blank with the defaults above, state what you chose (including N, that the user picks the base, that the critic loop polishes it, and that sound is on), and proceed — that statement is the confirm-back, with nothing to wait for. Note that "your call" on the duration means free: you did not put a number in front of them to accept.

Carry the resolved spec forward: it sets the composition's width/height/durationInFrames/fps that the builder hard-wires into <Composition id="piece">, and it's part of the brief context every sub-agent receives.

The pipeline is validated at 1080×1920 and 1920×1080. Square uses the same harnesses but is not yet smoke-tested; if the user picks it, say so (it's a first-class option, just less-trodden) and watch the first render closely.

Step 1 — Prepare the latest engineering environment

Engine and skill versions are engineering inputs owned by upstream, not design constraints imposed by this plugin. After the commission has resolved the workspace, run once before starting any builders:

node "${CLAUDE_PLUGIN_ROOT}/tools/check-env.mjs" --workspace "<WORKSPACE>"

This creates a missing workspace, resolves npm’s stable latest Remotion release, updates all declared remotion / @remotion/* packages together, and installs missing tooling. For RBP, it compares the full official upstream skill with an existing global installation and updates that installation in place only when contents differ; without a global installation it installs under the workspace’s .remotion-director/. Existing unrelated dependencies and manifest fields are preserved. Exact versions in the workspace manifest and lockfile record this run’s resolved environment; the next new piece queries upstream again. --fix remains an alias for this automatic preparation.

Use the printed RBP_SKILL_PATH (also recorded with the upstream revision in <WORKSPACE>/.remotion-director/environment.json) in every builder task. The builder reads that exact synchronized installation, including when it is global. Upstream owns the skill layout and its release schedule; an RBP/engine version difference is informational, and actual installed exports determine API availability.

Node.js, npm, Git and a full ffmpeg build must be available. The check exercises ffmpeg rawvideo, scale and crop support. Install missing host tools as needed under the host’s permission policy. Engineering preparation includes updating an existing global RBP installation; follow host filesystem permissions, with no separate design approval. If network access, install or verification fails, repair the engineering problem and rerun; do not claim the environment is current or start drawing after a failed preparation.

Prepare the environment before parallel draws; a global RBP update is shared by other projects using it. During a run, use check-env.mjs --workspace "<WORKSPACE>" --check for a read-only check without updating. If an engineering issue requires another upgrade, coordinate it through the orchestrator while affected builders are stopped, then re-render affected outputs. This prevents parallel dependency writes; it is not a fixed-version design policy.

Each draw is <workspace>/<piece-slug>/draw-i/, holding index.tsx, DESIGN.md, FIXES.md and out/. ⟨RUN_DIR⟩ is that draw’s absolute directory; ⟨WORKDIR⟩ / <WORKSPACE> is the absolute project root holding package.json and node_modules (pass it explicitly; it need not be the draw’s immediate parent).

Step 1.5 — 分方向 (deal directions; before any draw)

Left alone, independent draws tend to converge on the same idea, and then the pick has nothing real to choose between. So before any builder exists, one separate concept call lists the directions the draws will take — different at the idea level (the core conveying mechanism and the key action relation; a different subject or palette alone is the same idea).

Spawn ONE direction-lister agent — fresh context, one-shot. Give it only the brief, the resolved spec from Step 0 (aspect/resolution, duration, fps, on-screen copy, audio intent) and N. Nothing else: no workspace paths, no earlier draws or directions, and no wording of your own about how the directions should differ — its definition is the verbatim prompt (Delegate by Read). Wait for its explicit message: exactly N directions, === 方向 1 === … === 方向 N ===, one or two sentences each, ranked by its own judgment of potential. If the list is malformed (not exactly N numbered directions), ask the same lister to resend it in its format — a format fix, not a content request.

Every direction is dealt, the lister's own 方向 1 always among them. You never drop, merge, re-rank, reword or judge a direction (you never judge design). Write the list verbatim to <WORKSPACE>/<piece-slug>/DIRECTIONS.md under a batch heading that also records the deal (batch 1: 方向 1 → draw-1, 方向 2 → draw-2, …). The file is pipeline-internal: no builder, judge or pick material ever includes it.

Step 2 — N draws (乙), in parallel

Spawn N builder agents (one per draw), each with: its one direction from Step 1.5, verbatim (the batch's i-th draw takes 方向 i of that batch's list — never the other directions or DIRECTIONS.md), the brief, the resolved spec from Step 0 (aspect/resolution, duration, fps, copy + audio intent), its absolute <RUN_DIR> (…/draw-i), the duration authority (locked ⟨N⟩s or free, verbatim from Step 0), the absolute <WORKSPACE> root (the dir holding node_modules + package.json; the builder needs it for the NODE_PATH prefix on every render command, without which the first render crashes Cannot find module '@remotion/bundler'), the prepared RBP_SKILL_PATH, and the product contract (register <Composition id="piece"> with the spec's width/height/durationInFrames/fps). Its definition is its prompt (you do not restate it). Each designs the whole piece from its direction — the direction is a seed; the design is the builder's own — then builds and renders its preview (render-arm, which also writes the preview's review/) to out/r1 — the draw's first successful, non-white full render (throwaway frame checks of its own before it are fine). Then the builder reports draw-i preview ready and stops — no self-check yet; that belongs to the picked draw only (Step 3.5).

• Keep each builder instance alive after its preview — the picked draw's builder continues into self-check and polishing in the SAME context (do not start a fresh agent there).
• Verify each preview rendered non-white (look at its review/overview-1.png; this is your engineering check, not something you show the user).
• A builder is done only when it says so — not when it goes idle. See Delivery protocol (Hard rules). Wait for each builder to SendMessage you an explicit draw-i preview ready report naming its preview output dir (normally out/r1; if an earlier render attempt crashed or came out white, the builder names the later unused dir it actually rendered to). Do not read disk to guess whether a draw finished or which render is its preview. Hold Step 3 until all N have reported preview ready.

Step 3 — Pick the base at the previews

Precondition: all N builders have reported preview ready (Step 2). Only then pick. The user or the blind selector picks, as recorded at Step 0 — you, the orchestrator, never pick. Nobody has self-checked yet: the pick is for the idea and direction that can go furthest, not for the fewest current flaws. Both modes choose among the same dealt draws on their previews alone — the directions behind them are never shown.

Default — the user picks. Do not spawn the selector. Give the user only each draw's preview video.mp4 — no overviews, no frames, no DESIGN.md, no directions, no code, no builder notes. Use neutral labels (A, B, C…) assigned in a random order, copy each video to a neutral file name (e.g. <piece-slug>/pick/A.mp4; a fresh folder after a redraw) so its path does not reveal the draw, and keep the label → draw mapping to yourself. Add exactly one line of guidance, in the user's language: this is a first version, not yet self-checked or polished — pick the one whose idea and direction can go furthest, not the one with the fewest flaws right now. Take their answer as given (any draw, with or without a reason), append it to COMMISSION.md (label, draw, the reason if given), and continue with that draw as the winner. Don't argue for or against a draw.

• "你替我挑" (hand it to AI) at pick time — run the blind select below on the same previews, and record that the pick was handed over.
• Words about a draw at the pick — anything the user says about a picked draw beyond the choice itself (a phenomenon, a wish, a question) goes to that draw's builder with the pick message (Step 3.5), verbatim, under this one line and nothing else of yours: The user's words at the pick (they saw your draw as "⟨label⟩"):. The builder takes them into its self-check. Record them in COMMISSION.md with the pick. They are not a polish round: in 亲自打磨, Step 4b still starts by showing the user the settled video.
• More than one draw — if the user wants to keep more than one ("AC我都想要"), keep them all: each kept draw self-checks and is polished like a pick, side by side or one after another. Never ask the user to choose only one.
• "都不要，再抽" (none of these; redraw) — a comment is optional. In the user's language, say in one line that they can redraw right away, and that it helps to say something about this batch first — anything, even just how it felt — or the new batch may come out much like this one. Take what they say (or nothing) as given: never ask what is missing or how to fix it, and don't follow up. If they said something, fold it into the brief the way Step 0 settles one — their own wording and feelings, about the piece's job (audience, takeaway, tone, constraints) or about this batch; never a design instruction of your own, and never your own description of the rejected draws or their directions. Show the updated brief in one short line and proceed once they are content; from then on it is the brief every role receives. Tell all N current builders their draws are ended (no self-check), append the redraw to COMMISSION.md (the user's words as given, and the updated brief), then run Step 1.5 again: a fresh direction-lister on the current brief and a fresh, independent list for the N new draws. Do not hand it the earlier directions — "avoid what was already tried" would turn the list into a novelty objective. Append the new list to DIRECTIONS.md as the next batch (its 方向 1 → the first new draw, and so on), then run Step 2 on the current brief and the same commission with N fresh builders in new draw dirs (continue the numbering: draw-(N+1)…; leave the earlier draws on disk untouched), and pick again at their previews.

交给 AI 挑 — blind select (chosen at Step 0, or handed over at pick time). Invoke the critic-loop skill's selection step: spawn the blind-selector agent with the brief + the N candidate dirs — each draw's preview dir as the builder reported it (…/draw-i/out/r1/ with its video.mp4 and review/, or the later dir the builder named), and never the directions. It returns { winner, reason } selecting for potential (highest ceiling after self-check and polishing), not fewest current flaws. Append the winner and reason to COMMISSION.md.

Step 3.5 — Self-check (the picked draw only)

Tell the picked draw's builder (its SAME instance) that it was picked: it now self-checks per its definition. If the user said anything about this draw at the pick, it goes in this message under the fixed line from Step 3. Tell every other builder its draw is not picked and end it — losing draws do not self-check or render further.

Wait for the picked builder's explicit draw-i settled report naming its canonical out dir — it is NOT always the preview dir; self-check may have re-rendered to r2/r3/…. Verify that output's video.mp4 and review/ before Step 4. The preview is never handed to 甲 unless the builder's settled report names it as canonical.

Step 4 — Critic loop (甲乙环), run to convergence

The default polish (skip to Step 4b if the commission chose 亲自打磨). Run the critic-loop skill's loop, ferrying verbatim. Apply the 版本交接 rules in CRITIC-PROTOCOL.md: keep the review round separate from the render version, take canonical from explicit completion reports, and allocate unused output directories for re-renders.

1. Spawn ONE aesthetic-critic (甲) instance, design-blind, with the brief + the winner's canonical review materials as the builder reported them when it settled (Step 3.5) — no DESIGN.md, no code. Fill the protocol slots: ⟨BRIEF⟩, ⟨RUN_DIR⟩ (the winner draw dir, absolute), ⟨WORKDIR⟩ (workspace root), ⟨REVIEW_DIR⟩ (the canonical output's review/, absolute) and ⟨VIDEO⟩ (its video.mp4, absolute). This is review round 1 even if the builder self-checked through render r3. Verify the reported video and review dir exist before dispatch; missing or conflicting paths require a corrected handoff, never a fallback to r1 or the highest directory number.
2. Take 甲's verdict verbatim → send to the winning builder instance's conversation (the same continuous-context 乙), and archive it to ⟨RUN_DIR⟩/CRITIC-VERDICTS.md with the review round and reviewed output path. Fill the ferry message's ⟨REVIEW_ROUND⟩, ⟨CANONICAL_OUT_DIR⟩, ⟨REVIEW_DIR⟩ and unused ⟨NEXT_OUT_DIR⟩ explicitly. The builder handles the verdict per its definition (fix, or a pixel-grounded rebuttal), re-renders there, and SendMessages an explicit round ⟨REVIEW_ROUND⟩ done naming its actual final output dir after verification (again: not idle — wait for the message). It can advance beyond the assigned initial output. Verify that reported output's video.mp4 and review/, then update canonical and ferry that exact review dir and video with the next review round number to 甲. (A persistent 甲 fed stale materials will file already-fixed defects as live ones and carry that poison into every later round; if you realize 甲 was fed a stale or wrong version, the only clean fix is to shut that 甲 down and respawn a fresh one on the correct materials.)
3. If the builder rebuts an item, ferry the rebuttal verbatim → back to 甲 (甲's review protocol limits it to pixels + your relayed rebuttal). Name the same materials already handed to 甲 for that round; a rebuttal alone does not select a different render.
4. If the builder reports duration blocked (a locked total can't hold the content), surface its report to the user and let them decide — relax the lock (then tell the builder the length is now free) or keep it (tell the builder to make it fit as it stands). Do not decide this yourself, and never let a locked total be silently overrun.
5. Loop until 甲 reports CONVERGED: YES — there is no round cap. 甲 is a persistent instance with cross-round memory, which is exactly what makes it converge fast (typically a few rounds); do not impose an artificial ceiling that stops it while it still has high-/med-severity items. The converged result is the canonical output 甲 actually reviewed and marked converged.

Throughout: you only orchestrate + ferry verbatim + verify pixels landed. You report neutral pixel phenomena if asked, never aesthetic conclusions — all visual judgment lives in the design-blind 甲乙环.

Step 4b — 亲自打磨 (when the commission chose it, or from Step 5)

No 甲 is spawned. First show the user the settled canonical video.mp4 (Step 5's presentation); nothing goes to the builder in this step before they have seen it. Whatever they volunteer about it — a phenomenon, a wish, a single word — goes verbatim to the picked builder's conversation (the same continuous-context 乙), with the revision number K (1, 2, …) and an unused absolute ⟨NEXT_OUT_DIR⟩ allocated by the 版本交接 rules. Archive each comment verbatim to ⟨RUN_DIR⟩/USER-NOTES.md with its revision number.

• The builder decides how to change the piece, re-renders, and SendMessages revision ⟨K⟩ done naming its actual final output dir; if it thinks an item should not change, it says why with pixel evidence. Verify the reported video.mp4 and review/, update canonical, and show the user the new video, together with any such explanation verbatim.
• Never ask the user what is missing or how to fix it, and never add wording of your own to their comment or to the builder's reply. If the user simply accepts, the piece is done.
• A duration blocked report is handled as in Step 4.4.
• Repeat until the user accepts. There is no round cap.

Step 5 — User eyeball (final gate)

Present the canonical piece for the user's own eyes, the final gate, outranking every VLM judge: the video ⟨CANONICAL_OUT_DIR⟩/video.mp4. The user only watches the video; don't add overviews, frames or notes. The version the user judges must be the version that ships. If the duration authority was free, say how long the piece came out (X seconds) — the user picked "leave it to the designer", not "surprise me".

Do not declare the piece shipped on 甲's CONVERGED: YES alone. The user's verdict is final. If after the critic loop the user voices what they don't like, that switches the piece to 亲自打磨: continue with Step 4b from that comment.

Hard rules (do not violate)

• Delegate by Read, never paraphrase. The builder, the direction-lister, 甲 and the blind-selector ARE their verbatim definitions and protocols. You never restate their wording.
• 乙 is continuous context. One builder instance per draw, alive through design→build→preview→(if picked) self-check→polishing. Never a fresh read-back agent mid-loop (that's the degraded rescue form only).
• Fresh context only before the draws. The Step 1.5 direction lister is fresh; it runs before any draw exists, owns no idea and reads nothing back, it only seeds the builders. Do not read this as license for read-back agents anywhere else.
• A locked duration is a promise. If the user picked or stated a second-count at Step 0, no later step may change the total length — the builder fits the piece inside it or reports duration blocked, and the user decides. Only an explicit "don't constrain it" makes the length 乙's own (and therefore movable).
• 甲 is design-blind. It receives only the brief + the review dir and video of the version under review. Never hand it DESIGN.md, code, or notes — that is the exact context-pollution the 甲乙环 exists to prevent.
• The orchestrator never judges aesthetics. Ferry 甲's verdicts and the user's comments verbatim (a comment at a redraw is folded into the brief instead, Step 3; words about a picked draw go with the pick message under its one fixed line); report only neutral pixel phenomena; all visual judgment goes to the 甲乙环 or, in 亲自打磨, to the user.
• User eyeball is the final gate. VLM CONVERGED: YES is necessary, not sufficient.
• Commission before draw. Don't scaffold or draw until brief + spec + knobs are settled and confirmed back to the user, with their reply in hand (Step 0). Fill blanks with stated defaults and say what you chose — never silently assume the aspect/duration/audio, and never silently pick N: surface the draw count and let the user own it. Put the duration in front of the user as a pick-list (including "don't constrain it") rather than a blank to type into, and record which authority resulted. Ask who picks the base (default: the user) and who polishes it (default: the critic loop).
• Defaults are not limits. A user's extra request — voice-over through a TTS, their own assets, a library — is part of the commission, carried in the brief; the builder works out how. Never refuse one only because the defaults don't mention it; if it can't be done here, say so and let the user decide.
• You never pick the base. The user or the blind selector does, on the r1 previews (Step 3); your own aesthetic preference never enters the choice.
• Deal directions; never author them. Before every batch of draws (the first, and each redraw) a fresh direction-lister lists N idea-level directions (Step 1.5). Each builder gets exactly one, verbatim, and never sees the others; the lister's own 方向 1 is always dealt. You add no diversity or novelty wording of your own, and never edit, re-rank or judge a direction. Directions never reach the user's pick materials, the blind selector or 甲.
• Pick at the preview, self-check after the pick. Every draw stops at its r1 preview; only the picked draw self-checks (Step 3.5). The user sees only the preview videos — neutral labels, random order, the one-line first-version note — never overviews, frames, DESIGN.md, directions or builder notes.
• The user is not the designer. Never ask the user what's missing or how to fix it. At a redraw you may invite a comment — anything, even a feeling — but never require one or follow up. In 亲自打磨 their comments are taken as given and ferried verbatim; the design response is the builder's.
• Delivery protocol — idle is not done. Every sub-agent (the direction-lister, 乙 builders, 甲, blind-selector) finishes by SendMessage-ing you an explicit result, and only that message means it's done. An agent going idle is a yielded turn, not a delivered task — a builder is idle while waiting for the pick and between rounds; 甲 is idle between rounds. Never read disk artifacts to infer that an agent finished, which render is canonical, or what a verdict was.
  • The direction-lister returns its list of N directions by message. Hold Step 2 until it has; never spawn a builder without its direction.
  • Builders report preview ready + their preview dir after r1, then wait. Hold the pick until all N report preview ready; never pick on a draw that is still building or rendering.
  • The picked builder reports settled + its canonical out dir after its self-check (self-check may have moved it past the preview). Hold Step 4 / 4b until it does; never hand 甲 or the user a preview the builder has not settled on, or a mid-self-check snapshot. Then it reports round ⟨R⟩ done (critic loop) or revision ⟨K⟩ done (亲自打磨) with its actual output dir, or duration blocked.
  • 甲 and the blind-selector must hand their verdict/{winner,reason} back to you by message before idling — if a one-shot judge ends its turn without sending the result, ask it for the result; don't go fishing on disk.
  • Always carry the canonical artifact. Whatever you ferry to 甲 or show the user must be the latest reported, verified render, never a stale earlier one — stale materials make a persistent 甲 condemn already-fixed defects round after round.

• After your session restarts. A builder or 甲 you can reach only by its instance ID (its name no longer resolves, or SendMessage says it resumed the agent) reports into the old session's inbox, which you no longer read: neither its report nor its idle notice reaches you. Seen in a real run: three reports in a row lost this way. So each time you send such an agent work, also start a background wait that ends when its own copy of the report appears — a builder appends every report to <RUN_DIR>/REPORTS.md, 甲 saves every verdict as <RUN_DIR>/critic-crops/round-⟨R⟩-verdict.md — and take the report from that file. The agent wrote it, so it counts as its report, not as an inference from disk.