Reference Art Loop (ALIGN · Codex) — a picture that makes itself, judged blind

🔒 Do not wrap this skill in /loop, /schedule or a cron. It loops internally (render → blind review → decide → repaint), and a round is triggered by a change in the picture, not by the clock.

Codex is the executor; each blind round uses a fresh, vision-capable Codex subagent. This is independent-context review within the same model family. Use the shell, file reading and editing, file search, web fetching, image viewing, local rendering and presentation tools this Codex host actually exposes. Use native subagent tools for review; no Claude Code or Codex MCP server is required. Tool names in the examples below refer to this host's interface; use the equivalent native interface when another Codex host names it differently.

You are given a style source — a reference artwork — a subject, and a medium the result must be written in: p5.js in a browser, plain Canvas, SVG, a plotter path list — anything where a picture is a sequence of making actions a program lays down. The reference fixes a craft: its order of work, mark vocabulary, colouring, blank rules and rhythm. The subject may be the reference's own scene or anything else — 张择端's craft applied to present-day 武汉. You produce a page or file that replays the making of the picture in the order the craft proceeds, and you keep improving it until a reviewer who sees only rendered pixels — and fixed windows cut from the reference at viewing size — judges the work a product of that craft and names no computer-origin tell worth another round; then you put it in front of the user, whose acceptance is the last gate.

Two modes, both legitimate. 意临 — the subject is the reference's own scene (《千里江山图》 → p5.js): the style windows then also fix what the passages look like, and the reviewer may hold a mountain against the mountain it stands for. 风格迁移 — the craft from the reference, a new subject (《清明上河图》 → 武汉): 取其法,不取其景, and nothing in the loop judges resemblance to the original picture, only whether the work reads as a product of that craft and whether the subject can be named from the picture alone. The second is the more interesting one and the one this skill leads with; the first is not deprecated.

This is the ARIS loop (plan · draft · adversarial review · iterate · persist) applied to a picture. Three things are specific to pictures and are why this is not /auto-review-loop:

• The reviewer is blind to the code. A model that reads the generator reviews the algorithm; a model that sees only renders reviews the picture. A vision-capable reviewer can open local images: give it paths and tell it to use its own image tool. It sees the style windows too — that is visual input, not source.
• The style windows decide craft disagreements; the craft source decides process disagreements; the user decides the subject. A reviewer applies general taste; the reproduction you fixed in Phase 0 has one specific appearance, and the tradition's documented sequence has one specific order. In the 武汉 run the reviewer said the river needed no water texture; the reference's 汴河 is lined edge to edge, and the reference won (D-19). When the exact work's order is undocumented, choose the best-supported conventional sequence for that tradition, state the reconstruction once in reference.md, and use it consistently. Every decision against the reviewer is written down, once.
• Primitives beat parameters, once the parameter reached the marks. When a coherent parameter change leaves a visible tell materially unchanged, first establish that the changed code affects the marks in question — a dead edit and a wrong primitive look identical from outside. Then replace the primitive when its construction is what prevents the required result. The reviewer's parameter-or-primitive call is a hypothesis about code it cannot see; weigh it against what the code does.

Everything you and the reviewer propose is bounded by HERO: no hashes, no defensive scaffolding, no corner-case obsession, no rubric where judgement is called for, no stalling. An art tool, a cooperating operator, their own machine. The scope block in Phase 4 travels verbatim in every reviewer prompt.

Context: the user's request

Invoke $reference-art-loop-codex with [style source] → [subject] → [medium], for example 清明上河图 → 武汉 → p5.js 手卷, plus the project path and any round budget. Take these from the user's message; no $ARGUMENTS substitution is required.

Constants

• REVIEWER — a separate, vision-capable Codex subagent that can open the local renders; name the model in wiki/review-log.md. Each round starts a fresh review context carrying no parent conversation or memory of earlier rounds: with collaboration.spawn_agent, set fork_turns: "none". A follow-up may continue the same agent inside one round through collaboration.followup_task; calls are serial. Inherit the available model and effort unless the user requests a supported alternative. Your own look never substitutes. With no separate reviewer available, say so before the first blind round, finish the work, and hand over the runnable draft explicitly as unreviewed. A change of reviewer model starts a new score baseline.
• ROUND_BUDGET — from the invocation; default 8 blind rounds when none is given. The reference runs completed eleven and nine; data points, not limits.
• CRAFT_CLAIM — fixed in Phase 0: the material process the result should appear to come from ("mineral colour on silk", "绢本淡设色工笔界画", "registered woodblocks on paper"). The reviewer judges against this claim, never against "hand-painted" in general and never against the original's scene.
• SUBJECT — what the picture is of: the reference's own scene, or another the user names. For a transfer, use the user's focal passages when supplied; otherwise choose and state them from current subject research, and continue.
• STYLE_WINDOWS — the exact reproduction fixed in Phase 0 plus three to five windows cut from it at the intended viewing size (materially different passages) and one or two 2.5× details of the dominant mark-making. Cut once; every round's prompt names them.
• PROJECT_DIR — the path or existing project the user supplied; otherwise a short obvious ./<slug>/. It holds the deliverable, wiki/ and the working review renders; add src/ only when the implementation actually has separate source parts.
• VIEWS — chosen once in Phase 1 from the composition, covering every focal passage; the same crops and scales every round so rounds compare.

Override in the invocation: $reference-art-loop-codex "北斋 神奈川沖浪裏 → 東京 → SVG" — rounds: 4.

Doctrine

Blind review judges pixels against the craft, with the style windows beside them — not source, not the original's scene. The windows decide what the craft's marks look like; the craft source decides in what order they were made; the user names the subject, and where they have not named its focal passages you choose and state them; each decision is written once. Every choice a mark needs is made when the mark is built, never when it is drawn, so replay is exact. A failure that outlives a parameter change which demonstrably reached the marks is a primitive problem; a primitive change the reviewer calls a regression goes back to the previous version unless a stated craft or subject correction requires the new one. An automatic check exists only if you can name the failure it detects and what you would do differently. A loop can drive itself; only the reviewer, and then the user, can acquit.

Phase 0 — Fix the style source and study it

Fix the image first. Open the exact reproduction you will follow, keep a local copy, and record in wiki/reference.md: its source, the edition or impression when that matters (impressions of a print differ materially in colour; the 清院本 of 清明上河图 is two orders of magnitude more saturated than 张择端's silk), the crop or omitted sections, the output aspect you will use, and the intended viewing size. Cut the STYLE_WINDOWS from it now. Every later measurement and every disagreement with the reviewer refers to this one image at this one size. Enlargements diagnose mark-making; they do not set the finish standard.

Establish scale. When physical dimensions are known and you keep the work's height without non-uniform compression, compute millimetres per output pixel. Otherwise measure a few representative marks in the source image and map them into your output. Record any crop or compression that changes the mapping. List the marks that are not individually resolved at the intended view; their aggregate effect is what you paint, as texture — individual stroke or vector geometry may still be the means that produces it. This one number settled a two-round argument in the 千里 run: water lines 1–2 mm apart on a 51.5 cm scroll are 1–2 px at 500 px, a tonal texture and not lines. At 1 px ≈ 0.5 mm a face is one ochre dot and 瓦垄 are a directional grey texture.

Write the order of work. The stages documented or visibly supported for this craft, each named with its material or tool. For 青绿山水: 矾绢 → 勾勒 → 皴擦 → 赭石打底 → 汁绿罩染 → 石绿 → 石青 → 水纹·远山 → 复勾·点景 → 云气·题跋. For 北宋界画风俗卷: 矾绢 → 起稿·地势 → 界画 → 舟船 → 树石 → 人物 → 水纹 → 赭石 → 花青·朱砂 → 复勾·招牌·题跋. A layered oil may use ground, underdrawing, dead colour, glazes and impasto; a multiblock print uses its key and colour impressions in the best-supported registration order. These are examples, not required lists. Each stage is something the user can scrub to, and a stage that adds something other than its named material is a lie the page tells.

Write the mark vocabulary. Describe each materially distinct mark family that affects the craft claim: what it depicts, its scale and density at your view, its direction relative to form, how it begins and ends (pools, tapers, lifts, prints flat). Repeated motifs usually need the distinct grammars visible in the reference rather than one reusable symbol generator; texture strokes that radiate down from a peak and thicken on the shaded side are a different primitive from strokes that follow contours. Where the craft has several line characters (a ruler line, a pressured 白描 line, a texture line), name each — the same stroke on unlike materials was a tell in every 武汉 round until the grades were separated.

Write what the original leaves alone. Reserved silk as mist, unpainted water, blank paper for a waterfall, the bare paper of a print's lights. These are decisions in the craft and the cheapest wins in the work: make sure every later pass leaves them. Check each blank against the windows, not against taste — the 武汉 plan reserved the mid-river as a reconstruction, and the reference's river is fully lined (D-19).

Text and seals. Separate three different things: the artist's own inscription, the mounting title, and later colophons and collectors' seals. A Yuan literati scroll carries the painter's inscription, signature and date inside the picture as part of it; a Northern Song handscroll carries none — its title is a later label and its colophon sits on a separate sheet after the painting. Record which of the three this reference has, where each sits, at what size and in what script. Take any new inscription's placement, script and scale from the chosen work; a display caption dropped into a picture whose tradition puts none there is the first tell a connoisseur names.

Composition. Measure the chosen reference's own sequence of masses, pauses and transitions along its length, as fractions of that length: how many masses, where the eye rests, the ratio of dense to empty, where the density peaks, where the work breathes. For the reference's own scene: if the aspect cannot be kept, preserve its major masses, pauses and transitions deliberately and record which movements you kept or merged. For a subject transfer: the rhythm comes from those measured relationships, the masses from the subject. (The 武汉 run measured three sections at 19/38/43% of the length with the crowd's peak at the bridge — that reference's proportions, that run's, not a template.)

For a subject transfer, research the present subject before composing. Everything above studies the old picture and says nothing about what the new one is of. Fix the focal passages first: take the ones the user named, and when they named only a region, a city or a river, choose three to six yourself — the passages that carry the place's identity, distributed the way the format distributes attention: along its length for a scroll, around one view for a single sheet — state them and why in plan.md, and continue without waiting for the user. Then study each: a current map for how the passages sit relative to one another (which bank, upstream or downstream, what stands across from what, what is visible from where), and dated views for present form — profiles, structures, surfaces, vegetation, vehicles, signage, what people are doing and in what. Record in plan.md the relationships and identifying features the drawing must keep, and separately what you deliberately drop. Anything not grounded in that record is invented scenery, and no one will name a generic riverscape.

Then write the specification, before any code. The 武汉 run drafted three compositions and had three judges rank them — a local, a Song-painting connoisseur, the programmer who must draw it at 1 px ≈ 0.5 mm — grafting an element only when two agreed (D-02). The winner became wiki/plan.md: stations in reading order with x ranges; counts of figures, vessels, buildings and trees per station; the peak and the breathing spaces; the rules every module obeys — the blank list, where texture may appear, the pigment budgets, the readable-text cap, the line grades, randomness resolved at build time — each rule chosen for this subject and this composition rather than carried in from another run; the inscription text, if the reference's tradition carries one. Beside it wiki/interfaces.md is the module contract: the shared context object, the primitives a module may call, what its build returns, the occlusion rule. Each focal passage gets a fixed view in Phase 1. Recognisability is the user's to judge (D-18).

Borrowed technique. If the user hands you a file that already does one thing well (a 墨虾 page whose ink is dab-accumulated along a path with radial-gradient bleed; the previous scroll's brush-text engine and dab formula), read it and write a ## Borrowed section naming the idea you take. Take the idea, not the file.

Then set CRAFT_CLAIM in one sentence at the top of reference.md.

Phase 1 — Plan the architecture, choose the views, write the gates

Replay units

Represent the work as ordered replay units whose granularity matches the craft: strokes or dabs for brushwork, registered impressions for printing, paths and fills for SVG, whatever the visible making action is. Each unit belongs to a stage and carries every choice it needs — position, size, alpha, jitter, colour — made when it is built. Its draw function makes no fresh random or compositional choice; it may read stable shared geometry, masks and stage state established at build time. Order units by the real action, taken from the craft source you wrote down: the sequence inside one stroke is never reordered, and neither are the craft's supported local passes — a passage carried from contour through texture to wash before its neighbour is begun, and the returns and reinforcements a maker makes to work already laid down. Sort spatially within a stage only where the craft source supports that as the working order.

Where the craft prints rather than draws, the unit is the impression and the contract between modules is the block separation: which forms share a block, in what order the blocks are pulled, where each overlaps the last and where the paper is left bare. A stage is then one impression or one closely related group of them, and what a stroke-based craft resolves as brush order this one resolves as separation — the same form appearing in two impressions is a decision to write down, not an accident. Lettering carved into a block arrives with its impression and is not a separate writing pass; only lettering added by hand after printing is. Right-to-left across a handscroll is how the finished work is read; it is not evidence that every mark in a stage was laid down that way, and sorting dabs by x will also cut a stroke into pieces that arrive out of order. Use impression order for a print, and plain layer order where the action has no direction.

Local passes inside a staged timeline. A stage is a scrubbable position in the replay, not a claim that the maker finished the whole surface in one material before touching the next. Where the craft works passage by passage, give each unit both its stage and its passage; order units by passage, and within a passage by the craft's order; let the stage marker advance as each passage reaches it. The timeline then reads as work moving across the surface rather than as one global sweep per material. A later return to an earlier passage is an ordinary later unit that happens to carry earlier coordinates — keep it where the craft puts it instead of folding it back into the first pass. State in reference.md which of the two the craft source supports, globally staged or passage by passage, and build the timeline to match; that statement is what the process sheet is judged against.

A static substrate may be baked once and revealed with progress when its preparation lies outside the process being replayed. If sizing, grounding, tinting or printing the substrate belongs to CRAFT_CLAIM, it is an ordinary stage.

Occlusion as the craft produces it

Reserve untouched ground where the original reserves it. Let later opaque work cover earlier work where that is the real sequence. Use a generation mask only where the process truly prevents a mark from being laid down, or where semi-transparent later work would otherwise show an earlier layer the original never lets through — the 千里 back mountains' washes were not generated behind the front ones, because thin ochre would have bled through azurite. A line drawing on silk occludes by not drawing the hidden line: the 武汉 run stamped every object's footprint into a z-mask first and drew second, so a figure in front breaks the contour of the one behind and no ground-coloured fill exists (D-04). Choose per medium; write the choice into wiki/plan.md.

Module owners against the contract

When the work has materially different mark families — architecture, figures, boats, trees, water, ground, crowd placement, text — give each its own module with one owner building against interfaces.md, self-rendered once in a harness before integration; the integrator composes and owns plan.md's rules. Owners work in parallel when the host provides independently runnable agents; otherwise the same modules are built sequentially against the same contract, in dependency order. Either way the contract, not the integrator, answers an owner's questions.

Presentation

Choose it from the object. A sheet, an album leaf, a panel: show it whole at the intended viewing size. An oversized scroll: an offscreen full surface, a draggable viewport, a minimap with the viewport rectangle and a brush-position cursor. Replay directly while it stays responsive; add stage-start snapshots for backward scrubbing only when it visibly stalls, placed where they remove the stall. Pace stages by the amount and character of visible work — a whole-surface wash, a registered impression and a few final accents need not take equal time — but keep the craft's order.

For an interactive page: play/pause, scrubbing, direct access to stages; speed control or recording when the user or host needs them (MediaRecorder on the visible canvas, saved through a host download capability only where the host exposes one — inside the claude.ai artifact viewer that is the downloads capability — and otherwise through the browser's ordinary download); deep links to a progress value and viewport position (#p=…&cam=…) so a stage can be shared. For a non-page deliverable, expose the ordered stages in the medium's natural form — a sequenced path list, SVG animation or layers, another directly inspectable replay.

Fonts

Before drawing any text, load the complete final string in the chosen face (document.fonts.load(font, fullText)) — web CJK fonts arrive in on-demand Unicode subsets, and a load without the text leaves rare characters to fall back to a system sans. Render the string once and look for fallback glyphs. Use a face available both to the headless review render and to the delivered work; a local-only face is acceptable only when the delivered geometry no longer depends on it or the declared fallback is visually faithful.

Views for the blind gate

Decide once, from the composition, and keep fixed: the whole work at the intended viewing size; a viewport on every focal passage the user or the plan named; representative crops of materially different passages (dense form, quiet ground, water or sky, lettering if any); one diagnostic enlargement (about 2.5×) of the dominant mark-making passage; for a scroll, both ends and a middle. Then check the set against the plan's focal list, not against what looks interesting: 黄鹤楼, 300 px tall, went unseen for eight rounds because it stood between the bridge viewport and the 户部巷 viewport, and the user found it faint and half-hidden (D-17). Add a view only when a passage cannot be judged from the existing ones.

Also render one labelled process contact sheet: for each stage, a before/after pair cropped to a passage that stage actually changes (one fixed crop for all stages only when every stage materially affects it), each panel large enough for the named material to be visible at the stated scale. It goes to the reviewer in the first blind round and again whenever stage order or replay-unit behaviour changes.

Write wiki/gates.md before the first mark

The one mechanical gate. Replay determinism: capture the picture after reaching full progress directly, and again after scrubbing backward and returning to full progress through the page's own controls; compare the two with a simple image diff. A repeatable difference means the two replay paths disagree; find the cause before changing anything. A draw-time choice that leaked into replay is one — move that choice to build time — and so are a layer, transform or clip not reset on rewind, drawing state accumulated across the scrub (a canvas never cleared, marks composited twice), and a font or asset that had not finished loading on the first pass. This is the only universal automatic check. Discarding polylines with fewer than two points and fixing a console exception at full progress are hygiene, not gates. Judge responsiveness by whether playback and scrubbing react promptly; do not import another machine's build-time number.

Add a domain check only after a concrete failure: "bridges land on land at both ends" earned its line when a bridge floated; "water rows never cross" when amplitude and spacing were set independently. A subject transfer's plan rules — chosen in Phase 0 from the current subject, never inherited from another run — are the integrator's first-look list before each round, not gates. (The 武汉 run's were its own: the bridge as the density peak, no cars, at most fourteen readable boards. A present-day riverbank drawn under a rule against cars is a picture ruled against its own subject.) Never pre-write a gate.