Gemini 4 Argon High in Antigravity: verification-rule prompt for Three.js projects

Emily @IamEmily2050Originally posted 2026.10.21

Open original on X

I've had two projects running with Gemini 4 Argon High inside Antigravity for the last three days, and I might not finish before the weekend. I learned a lot during this process, and I will share more details when they are finished, but for anyone starting a new project, make sure they have verification rules. Use my prompt to save time and tokens; real world is from long, real running projects if you are doing Three.JS VERIFICATION RULES (read before building anything) 1. Verifier first. Write scripts/verify-*.mjs before the first [scene/shot/page]. A missing metric FAILS its gate with the message "metric missing". Never `metric ?? value` or `flag !== false`. Self-test: run every gate on an empty metrics object; every gate must fail. Per gate: one red case (wrong value → fail) and one green case. 2. Numbers come from the reference, not from the prompt. Measure [the reference images] first: luminance p10/p50/p90, clipping share, silhouette fill ratio, adjacent similarity. Each gate is "inside the band the reference measures". Print the reference's number beside ours every time. 3. Two bounds on every number, plus what must still be visible. Not "clipping under 2%". Write "clipping in [0.2%, 2.0%], and the [named light sources] still clipped". Not "mean luminance under 0.2". Write "[0.06, 0.18] and at least [N] readable [lamp pools]". 4. Measure from pixels, never from the item's own metadata. Render to PNG, then measure with a script that never reads a sidecar, a class field or a declared region. A cap like "at most [4] of [25] may use [layout X]" is enforced on a measured property (enclosure of the subject box on three sides, fill ratio of the silhouette in its box, horizon height, coverage, aspect) and the declared class must agree with the measurement or the item fails. 5. Name the degenerate solution for every gate. Before building, a second agent who did not write the gates answers in writing, per gate: "what is the cheapest way to pass this without doing the work?" (darken the frame, dry the road, draw a box, relabel, tile the background). Every answer becomes a negative gate or a measured replacement. A negative gate names the degenerate solution exactly (a backdrop field that encloses the subject's box), never a property honest work also has (large flat fields in a flat style). 6. Economy against the reference. Count colour regions larger than 0.02% of the frame at 480 px in the item and in its reference; the item's count must be in [0.6x, 1.4x] of the reference's. Busier than the reference is a defect. 7. Distinctness beside consistency. For any set seen together: adjacent-item structural similarity at 240 px in [0.15, 0.60]; subject centre shift between neighbours at least 12% of the frame, from rendered centroids; a measured cap on any one layout. References for a series are generated from the style in words, never image-to-image from one master image. 8. One before many. Build ONE item per kind ([one scene per composition class]). Put each beside the previous round at the same size in out/roundN/five_up.png. A blind critic (Argon High, has not seen the code, opens the image with view_file) answers per item, verbatim in the report: - "Is the subject inside a doorway, box or booth? yes/no" - "Does the background read as [a painted wall and sky] or as a patchwork? which" - "Name the event/subject." - For neighbours: "Can you tell these two apart, and which is which?" Fan out to the rest ONLY when every answer is right. At most three attempts, then write what failed and stop. 9. Judge the whole contact sheet before any single item is accepted. 10. The suite is frozen for the round. The agent that writes the verifier builds nothing. Gates change only between rounds, through a probe: two variants of one brief differing in one thing, same seed and gates, composed by an agent that ran neither; the lesson goes in HARNESS_LESSONS.md and is retired with evidence, never deleted. Working rules: PROGRESS.md after every step; every file written before replying; edits in chunks of at most 120 lines; git commit after each numbered step; full tool paths; never stop a process you did not start; subagents name their model explicitly, never "inherit"; cheap fast model for render-and-measure loops, strong model for planning, direction and critique.