render-loop
Skill4 starsChanged 17 days agoMITView on GitHub
Iterate on layout changes to a rendered output (PDF, document, generated image, email template) by looking at the real result: render without a browser or session, rasterize, zoom into the touched area and compare before and after stacked. Use when working on subjective design notes, when there is no reference to measure against, or when you need to confirm visually that a change is noticeable and not just applied.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- y-a-v-a/session-exporttheir own version, first seen Jun 16, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- y-a-v-a/session-export★ 3same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository46 other files it gives its agents.
- AGENTS.mdAGENTS.md
- add-repo-to-docsSkill
- adrSkill
- auth-bypass-localSkill
- before-afterSkill
- bug-huntSkill
- carry-envSkill
- code-healthSkill
- crux-doctorSkill
- crux-initSkill
- css-to-componentsSkill
- deploy-fallbackSkill
- deploy-watchSkill
- device-loopSkill
- drive-browserSkill
- e2eSkill
- end-sessionSkill
- eval-fixturesSkill
- explain-planSkill
- flowSkill
- grillSkill
- merge-conflictsSkill
- motion-videoSkill
- oauth-reauthorizeSkill
- prod-signalsSkill
- promote-to-docsSkill
- prose-checkSkill
- read-documentSkill
- repo-mapSkill
- review-prSkill
- root-causeSkill
- runbookSkill
- security-auditSkill
- share-localSkill
- shipSkill
- skill-auditSkill
- skill-creatorSkill
- teachSkill
- ui-behaviourSkill
- ui-tellsSkill
- visual-diffSkill
- visual-testSkill
- wizardSkill
- workspaceSkill
- write-testsSkill
- x-postsSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 24
Replicate the production pipeline's flags: If the production render launches the headless browser with specific flags, the script must use …
- Distinctive: line 64
If the output has fixed-size canvases, content that doesn't fit is clipped without warning.
- Distinctive: line 67
Before closing a change, identify and force the domain's real edge cases: the longest possible text, the label with the most characters, …
- Distinctive: line 96
When an output is outside the scope of what you are changing but can break by accident, a fingerprint protects it: render, rasterize, store …
- Distinctive: line 101
A guard that has never been seen to fail is worthless: Always validate it in the negative: cause the change, check that it trips, and …
- Distinctive: line 107
If the render forces a media type (typically print), the style rules specific to that media are the ones that apply, not the base ones.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
render-loop
A short loop for layout changes: edit, render, look, adjust. It works when the reference is a person's judgement.
Complementary to /visual-diff, which measures against a reference. If an
official design exists to compare against, that is the tool; this one is for when
there isn't.
1. A deterministic renderer, outside the application
The first thing is to be able to produce the output without navigating the application by hand: no session, no clicking, with the same data every time. Usually that means a small script that mints whatever credential is needed and calls the render route directly.
Three things that script must do, and that produce false results if missing:
Replicate the production pipeline's flags. If the production render launches the headless browser with specific flags, the script must use exactly the same ones. Rendering without them produces artifacts (black headers, different composition) that look like design defects and are not.
Wait for fonts. Without waiting for them to be ready, the output uses the fallback ones and you are measuring a font nobody will see.
Cancel animations. Animation libraries often start at zero opacity and don't complete in headless: the output can come out blank with no error at all.
2. Rasterize
Convert the output to an image at a resolution that is comfortable to look at, not the highest possible. For multipage documents, limit it to the page you are touching.
3. Zoom into the touched area
Looking at the whole page is no use for judging two pixels.
python3 <this-skill-directory>/scripts/inspect.py zoom page.png 40 290 310 440And then open the PNG and look at it. That is the step that gives value to everything else; without it this is just generating files.
4. Compare before and after stacked
Essential for size changes: a one-pixel jump is measurable but may not be visible until you see them side by side.
python3 <this-skill-directory>/scripts/inspect.py stack before.png after.png \
--box 40 280 310 4405. Force the worst case before accepting anything
If the output has fixed-size canvases, content that doesn't fit is clipped without warning. Validating with the usual example is not enough.
Before closing a change, identify and force the domain's real edge cases: the longest possible text, the label with the most characters, the empty field, the value that doesn't resolve. Force them in the local data and restore them afterwards.
It is worth leaving that list written in the project documentation: they are concrete facts (which is the longest text and how many characters it has) that nobody remembers two months later.
6. Measure the real geometry of assets
Positioning or sizing an image by its box doesn't work, because its box is not its content.
python3 <this-skill-directory>/scripts/inspect.py asset public/logo.png
python3 <this-skill-directory>/scripts/inspect.py asset public/icon.svgIt reports the real transparent margin of a PNG and the declared aspect ratio of an SVG. Real cases that cost several attempts each: a PNG with 28% transparency at the top, whose content fell 85 px below its coordinate; another with 27% on the right, which looked a third smaller than it could be; an SVG with a 3.44:1 ratio put in a square box, which rendered as a strip.
Measure the asset before touching the number.
7. Put a regression guard in place
When an output is outside the scope of what you are changing but can break by accident, a fingerprint protects it: render, rasterize, store the hash of each page and compare on every run. It fits well in a pre-push hook, tolerating that the local environment may not be up.
A guard that has never been seen to fail is worthless. Always validate it in the negative: cause the change, check that it trips, and revert. It is the only way to know you are measuring what you think.
Warning: the media variant wins
If the render forces a media type (typically print), the style rules specific to that media are the ones that apply, not the base ones.
A change to the base class may have no effect on the output, and at the same time make it look like the regression guard is broken when it is actually working fine. When touching a rendered output, change the right variant.
Limit
This doesn't detect what you don't think to try. For systematic coverage after a
batch of changes, use /visual-diff with a battery of scenarios.
Related
/visual-diff: measure against a reference/visual-test: inspect web pages across viewports
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

