Method Figure Loop (ALIGN · Codex) — a figure that makes itself, judged blind

🔒 Do not wrap this skill in /loop, /schedule or a cron. It loops internally (render → blind review → decide → redraw), and a round is triggered by a change in the figure, 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 composition source — a published method-overview figure, a paper's or a repo's Figure 1 whose arrangement you want — a method the figure must convey, and a medium the result must be written in: p5.js in a browser, with the p5.js-svg renderer beside it so the same program renders the canvas the reviewer sees and exports the SVG the paper prints.

The method determines the relationships the figure must show. The chosen visual identity determines how its marks look. The composition source supplies useful arrangements, proportions and distinctions; borrow them where they serve this method. The user decides the intended identity and emphasis. A source's missing connector, diamond, thumbnail, empty region or headline is not a reason to retain something that fails in this figure.

You produce a page that replays the building of the figure in the order a designer builds it, and you keep improving it until a reviewer who sees only rendered pixels can explain the method back from the figure alone — every move, in order, every fact — and says the figure is worth looking at, naming no template-made tell worth another round. The user's acceptance is the last gate, and their first look comes early, on the first complete composition, not at the end.

Two modes, both legitimate. 意临 — the method is the source's own (the paper's Figure 1 redrawn as a program): the source's own panels then say what the method says, and the reviewer's explanation may be held against the paper's method section. 风格迁移 — the arrangement from the source, a new method (ARIS-Movie-Director's Figure 1 → ALIGN's loop): 取其法,不取其景, and nothing in the loop judges resemblance to the source's content, only whether the work reads as a figure designed for this method and whether the method can be told back from it. 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 figure. Three things are specific to figures and are why this is not /auto-review-loop:

• The reviewer is blind to the code and, in round 1, to the source. A model that reads the generator reviews the layout algorithm; a model that reads method.md reviews its own memory of the method; a model that sees only the rendered figure reviews what a reader will get. A vision reviewer can open local images: give it paths and tell it to use its own image tool. From round 2 it sees the composition source too — for arrangement comparison only, never to compare one method with another, and never to judge the work's palette or materials.
• Each disagreement goes to what actually decides it. A reviewer applies general taste. method.md says which relationships the figure owes and which facts it states; the chosen identity says what the marks look like; the word budget says what there is room for; the user rules on identity and emphasis. When the reviewer asks for a legend entry the budget cannot carry, the budget wins and the line's own label changes instead; when it says a panel is unclear, the account in method.md says what that panel had to carry. A decision that constrains later work is written down, once.
• Primitives beat parameters. When a coherent parameter change that should affect a visible tell leaves it materially unchanged — the retry arrow re-coloured twice and still read as main flow — stop tuning that representation and reconsider the primitive: a different arrow kind, a split panel, a band where there was a panel. When the reviewer says a tell needs a different construction, test that at the primitive rather than tuning the same representation once more.

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 $method-figure-loop-codex with [composition source] → [method to convey] → 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. Start a fresh agent for each blind round with collaboration.spawn_agent, setting fork_turns: "none" and carrying no parent conversation or memory of earlier rounds. Send the round's second half to that same agent through collaboration.followup_task, after its first answer arrives; calls are serial. Inherit the available model and effort unless the user requests a supported alternative. If no such reviewer is available, say so before the first blind round, finish the work, and hand over the runnable draft explicitly as unreviewed — your own look does not substitute, and neither does your own explanation of the method. A change of reviewer model starts a new score baseline.
• ROUND_BUDGET — from the invocation; default 5 blind rounds when none is given, because a figure wants fewer and larger rounds than a painting (Phase 6). The painting runs took eleven rounds each; ALIGN's own figure took five blind rounds over seven versions and did not pass its gate. Data points, not limits.
• CRAFT_CLAIM — fixed in Phase 0, identity and arrangement in one sentence ("a method overview drawn by this project's authors in its own ink-on-silk idiom, in the arrangement of : three numbered stage bands read top to bottom, panels with a title and a one-line subtitle, four line kinds by meaning, legend and rule panel below"). The reviewer judges execution against this claim — never "a nice figure" in general, never the source's content, and never the distance between the work's materials and the source's. A user ruling rewrites the claim; update the affected instructions in the current plan.
• METHOD — what the figure is of, fixed in wiki/method.md: the relationships a reader must be able to recover, numbered and in order; the facts the figure states; and the implementation detail deliberately left to the caption. That scope holds through review, and does not shrink when the budget gets uncomfortable. The user names what must be on the figure; their look decides the focal elements.
• STYLE_WINDOWS — the composition source fixed in Phase 0 at its reading size, plus 2× crops of the passages whose arrangement you borrow: its densest band, its legend and rule panel, one step panel. Cut once; shown from round 2 on, never in round 1, and for arrangement, grammar and hierarchy only — the identity is the chosen one.
• PROJECT_DIR — the path or existing project the user supplied; otherwise a short obvious ./<slug>/. It holds figure.html, wiki/, thumbs/ (the raster crops the figure embeds) and the working review renders; add src/ only when the implementation actually has separate source parts.
• VIEWS — the reading view, always: the whole figure at the width where its reader meets it. Beside it, the diagnostic crops this round needs, kept stable while their subjects are stable and recut when a redesign moves them. The process sheet goes only to the first construction review and after the replay sequence changes.
• CANVAS — 1800 × 1000 by default; both the canvas and the SVG viewBox. Change it only when the figure's own content demands it, in Phase 0, once. State the display width separately: an 1800 px export shown in a README column at 900 CSS px is read at 900, and every type and line decision answers to that number, not to the export.

Override in the invocation: $method-figure-loop-codex "SenseNova-U1 Fig. 3 → our looped decoder → p5.js" — rounds: 4.

Doctrine

Blind review judges pixels against the method and the craft: round 1 asks a reader who has never seen the paper to tell the method back, and from round 2 the composition source sits beside the work for arrangement comparison — not source code, not method.md, not the source's own method. method.md determines the relationships the figure must show; the chosen visual identity determines how its marks look; the composition source supplies arrangements to borrow where they serve this method; the user decides identity and emphasis; a decision that constrains later work is written once. The function a held passage carries is protected; its shape and its material are not. Every choice a mark needs is made when the mark is built, never when it is drawn, so replay is exact and the SVG is the canvas. A visible failure that outlives a coherent parameter change is a primitive problem once you have established that the changed code reached the marks in question — a dead edit and a wrong primitive look identical from outside. A loop can drive itself; only the reviewer, and then the user, can acquit.

Phase 0 — Fix the identity and the composition source, and study both

Ask the identity question first. Establish whose visual language the figure speaks: the project's, the venue's, or a particular reference's. Use the user's brief and the project's existing work to answer, and ask when they leave a real choice — this is the question that decides palette, typography and illustration, and it is expensive to answer late. State what the composition source contributes and what the project contributes before any of those choices. A venue determines delivery conditions; it does not automatically supply the figure's identity.

Fix the composition source next. Open the exact figure you borrow from — the arXiv version, the README commit, the page it sits on — keep a local copy, and record in wiki/reference.md: its source and version (a v2 figure often has a different legend and one more band than v1), its printed or displayed width (single column, double column, README hero), the crop if you take only part of it, the aspect you will use, and the reading size — the size at which a reader actually meets it. Cut the STYLE_WINDOWS from it now. Every later measurement of the arrangement refers to this one image at this one size. Enlargements diagnose the panel grammar and the heads; they do not set the finish standard.

Establish scale from the display width. State the width at which your reader meets the figure, separately from the canvas, and set the smallest required text from that width in the actual face and script you will use. Establish the rest of the hierarchy with size, weight and face, and drop any size that performs no distinct job — counting the figure's title and tagline among them. Shorten text and reallocate space before lowering the reading floor. The floor settles the word budget before anyone argues about it: a panel 300 px wide at 1800 px across carries one title and one line of six or seven words at the floor, and a figure of nine such panels plus a legend has room for about seventy words. Treat what is not individually resolved at reading size — the ticks inside an icon, the text inside a crop — as texture the reader sees as "a plot", "a page of numbered decisions", never as something they read.

Write the order of work. Labels, illustrations, panel dimensions and connections are designed together; the replay shows their assembly, and the stages are named after that design is made, from what this figure actually contains. A thumbnail stage exists only when thumbnails exist. If panels arrive with their titles and subtitles, say so in the stage's name. Final lettering may add connector labels and captions without pretending all the text was designed last. For ALIGN's own figure the honest naming would have been: regions and headings → labelled panels → connections → illustrations → connector labels → legend, rule and showcase. Where the source's own order is visible — a title strip that plainly went down first, a legend added last — borrow it; otherwise state yours once in reference.md. Each stage is something the user can scrub to. Name each stage for what it visibly adds, and correct the label when it is wrong.

Write the panel grammar. Name each materially distinct family your method needs and what each means: a stage band (a region with a numbered title, holding panels), a step panel (title, subtitle, an illustration area), a gate, a store (a wiki, a log), a release. The source's own families are the starting inventory; what separates them in your figure comes from your identity — a diamond tells a gate from a step in one idiom, a doubled 界画 rule does it in another. Note width rules — are panels sized to their content or to a grid? — the proportions inside a panel, and what a panel never contains (a paragraph; a second illustration). One shape for a step, a gate and a store is the figure's version of the 武汉 run's one line weight on every material, a tell in every round until the grades were separated: the reader must know from the shape alone which is which.

Write the line grammar, by meaning. Each line kind the method needs: what it means (main flow, retry loop, repair loop, audit trace, data reference), its weight, colour, dash, head, where it attaches (panel edge, never inside), whether it carries a label and where the label sits. The main flow is the heaviest and usually unlabelled; a loop that returns to an earlier panel is lighter, coloured, and labelled with its condition and its limit ("RETRY · max 4/panel"); an audit trace is the thinnest and greyest. How many kinds there are comes from this method's scope and from what a reader can tell apart at reading size, not from how many the source drew.

Write the palette by role. Choose the ground, the panel fill and the accents from the chosen identity, then give each a role: one accent per loop kind, ink for the main flow, one colour for failure and one for pass, nothing coloured for decoration. Separate regions by enough contrast to survive the intended reading size — numbered bands may share one tint — and keep the ground quiet enough for the method to read. Judge each line at reading size on the chosen ground; adjust weight and opacity together. A gradient or a shadow answers to the chosen identity and to reading size: keep it when the identity uses it and it still reads at that size, drop it when it is decoration — decoration is the tell a reader names without knowing why.

Write the figure's explanatory scope, before the budget. Write the short account this figure must let a reader recover: who acts, what passes between steps, what a decision changes, what persists through a loop, and what produces the output or ends the process. Select from the method the facts this figure promises to communicate; implementation detail that cannot earn space goes to the caption or the surrounding text. Hold that scope steady through review — neither silently drop a required relationship, nor expand the figure to answer every question a reader could ask.

Write the word budget, and spend it down. Set the word budget from this method's scope, the display width and the space available. Fit essential labels at reading size. Leave room below the ceiling; pay for essential additions by cutting weaker text. Spend first on actors, transitions, conditions and outputs; repeated titles, slogans, example tags and redundant legend text surrender their words when a required relationship needs them. Fit essential wording in both scripts at reading size: characters still take width and attention whatever the language, and changing language is not a way to evade the visual budget.

Write what the eye must read first. Name the first, second and third landing your figure wants, and check the source's own three for a workable order — usually the band titles and the main flow, sometimes a single rule panel. The landings belong to the method's moves and to the statement the reader must retain; a glance that lands on a mascot, a miniature or a slogan has the hierarchy inverted, whatever the words say.

Write what makes a figure look template-made. Every panel the same size regardless of what it holds; every arrow the same weight; a legend that explains what the eye already understood; icons from a set; a colour per panel with no role; text centred in every panel; a title inside the figure that the caption already carries; clip-art where the method's real output would say more. Judge the figure in front of you against these.

What is left alone. No panel for the input where a small glyph and a line do; no label on the main flow; a band with two panels when two are what happened; margins nobody filled. These are the cheapest wins in the work — until a reader needs something there. Emptiness is protected by what it does for the reading, never by the source having had it too.

Illustrations. The source's mascots, characters, drawn scenes and generated thumbnails are its content, not its craft; never take them. Choose each panel's illustration for what the reader must understand there: a real crop when its visible content explains that step at reading size, a drawing in the chosen identity's own line when the panel needs to identify an actor, an artifact or an operation, and nothing at all when the only thing gained is another miniature. The source's thumbnail count is not a requirement. Nothing in the figure is generated by an image model, and nothing is drawn to look like one.

Text and title. Does the source carry a title inside the figure? A README hero does; a paper's Figure 1 usually does not, because the caption carries it and a second title is the first thing a reviewer of the paper strikes. Decide from where your figure will live, and write the decision down.

Composition. How many bands, the reading direction (left to right along a row of bands; or top to bottom, one band per row; or a column of stages with a loop returning up the right edge), the ratio of panels to ground, where the loops cross the bands, where the legend and the rule panel sit and why there. For the source's own method: if the aspect cannot be kept, preserve the bands, the loop crossings and the bottom row deliberately and record which you kept or merged. For a method transfer: borrow the source's rhythm where it serves the method (three bands in roughly 30/40/30 of the height, the loops crossing between bands two and three, a bottom row for legend, rule and output) and change it where it does not — ALIGN merged the source's three-part bottom row into one showcase strip and moved the rule panel up beside band 3. The panels come from the method.

For a method transfer, write the specification before any code. Draft wiki/method.md: the relationships the reader must be able to recover, numbered and in order — each one sentence — and the facts the figure must state (which model sees what; what crosses a round and what does not; a count, a limit, a score trajectory); which illustration each panel carries and why that one; what the rule panel must state. Then wiki/plan.md: bands with their y ranges; panels per band with x ranges, family and illustration; every line with its kind, source, target, label and the band it crosses; the legend entries; the output presentation; the rules every module obeys (the blank list, the word budget, the type scale and its floor, lines attach at panel edges, randomness resolved at build time). Beside it wiki/interfaces.md is the module contract when there are modules: the shared layout object, the primitives a module may call, what its build returns, the occlusion order. The user names what must be on the figure here — for ALIGN, the blind reviewer, the wiki, and the fact that no pixels cross rounds — and each named element gets its place in the first glance. Whether the figure says what they meant is theirs to judge.

Borrowed technique. If the user hands you a file that already does one thing well (a previous figure's arrow-routing around panels; a scrub UI; a band-tint scheme), 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 and choose the views

Replay units

Represent the figure as ordered replay units whose granularity matches the build: a band, a panel, an arrow, an illustration placement, a text run, a legend entry — whatever the visible designer's action is. Each unit belongs to a stage and carries every choice it needs — position, size, radius, colour, weight, dash, label text, font size, the routed path of an arrow — made when it is built. Its draw function makes no fresh random or compositional choice; it may read the stable shared layout, the panel rectangles and the stage state established at build time. If any randomness exists (a seeded dash length, a hand-set-looking offset), resolve it at build time; most figures need none. Order units by the real action: left to right within a stage in the reading direction, band by band; arrows in the order main flow → loops → traces; text after every shape it sits on.

The same units feed both renderers: the P2D canvas the page replays and the review screenshots come from, and the p5.js-svg renderer that writes the paper's SVG at full progress. A unit that draws differently in the two — a blend mode, a canvas filter, drawingContext work — is a unit the paper will not get; keep to fills, strokes, text and images.

Occlusion as the designer produces it

Bands go under panels; arrows go over bands and under panels, so an arrow ends at a panel's edge and its head is never hidden inside — route the path to the edge at build time rather than drawing to the centre and covering the overlap. Crops are clipped to their reserved rectangle. Text goes over everything and never touches a stroke. A loop crossing a band it does not belong to crosses in the gap between panels or takes the margin — the arrangement you borrowed usually shows a workable answer. Write the order into wiki/plan.md; occlusion is settled once, there.

Module owners against the contract

A figure is usually one program. When it has materially different families — a band layout, an arrow router, an illustration set, a legend — and more than one pass is needed, 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 because the contract, not the integrator, answers their questions. Do not split what one pass can hold.

Presentation