/screenshot-critique

name: screenshot-critique
description: Use the unprimed sub agent as a second set of eyes before accepting visual work — MANDATORY before declaring any user-reported visual bug fixed or claiming a visual change verified; primed eyes pass defects fresh eyes catch.

Screenshot Critique

Use an unprimed sub-agent as a second set of eyes before accepting visual work. This is for visual defects, not pixel metrics; pair it with `compare-screenshots` when you also need numbers — including on a single shot with nothing to compare against, whose scene metrics say whether the frame has any content in it at all.

Workflow

1. Capture or locate the exact PNGs/GIF frames under review. 2. Keep native-size evidence and create supplementary 2x-4x crops for every key feature, plus the full screenshot. Include complete endpoints and fades; recheck crop bounds after geometry changes. Crop selected units, city/town stacks, flags/poles, shadows, selection rings, labels/icons, roads, terrain features, water, and any artifact-prone area. If the complaint is about "too faint", "wrong order", or "not in perspective", the crop is mandatory. 3. Spawn one fresh explorer with `fork_context: false`; pass only the full images, the crops, and a short neutral task. Include the approved reference and user requirements when judging fidelity; withhold history, implementation details, prior verdicts and the expected answer. 4. Ask for concrete visible defects with confidence levels. Name likely risk categories: unit/prop depth ordering, layering, shadows, selection-marker contrast, ground-plane perspective, flag/pole attachment, label style and icon readability, blur, scale, lighting, artifacts, missing models, terrain feature readability, roads, water, and overall scan readability. 5. Run the returned critique through `scripts/receipts.mjs`. Every number it flags is a claim the critique cannot show a command for, and every file it flags is one the critique named but never wrote; strike those claims or re-measure them yourself before any of them reach a decision. 6. Compare the sub-agent's critique against your own inspection. Treat overlap as high-priority evidence. Treat novel high-confidence findings as bugs to inspect, not as taste notes to dismiss. 7. Record actionable findings in the spec, visual report, or next task plan before claiming the screenshot is accepted.

Sub-Agent Prompt

Use this shape, replacing the bracketed surface and attaching local images:

Fresh visual critique task. You have no project backstory and should only
inspect the supplied screenshots and crops. First inspect the full screenshot
for context, then inspect each crop at zoomed scale. Look for concrete
visual/layout defects in [surface], especially unit/prop depth ordering,
layering, shadows, selection-marker contrast, ground-plane perspective,
flag/pole attachment, label style/icons, blur, scale, lighting, artifacts,
missing models, terrain feature readability, roads, water, and scan
readability. Do not assume these are correct. Return a concise list of issues
you can see, with confidence and whether the issue is visible in the full image,
the crop, or both.

Describe what you see in words. You are looking at these images, not measuring
them, so state no pixel value, luminance, percentage, ratio, count, or offset
unless you ran a command that produced it and you quote that command and its
output beside the number. "The hem reads clearly darker than the floor beside
it" is a finding; "44.0 versus 33.6" without a receipt is a fabrication. The
same goes for files: name no artifact you did not create with a tool you
actually have.

Spawn config:

• `agent_type`: `explorer`
• `fork_context`: `false`
• attach screenshots as `local_image` items
• omit model overrides unless the user explicitly requests one
• grant a measurement tool whenever you want numbers back — see Receipts

Receipts

A number in a critique is a **receipt or a guess**, and the two are indistinguishable once they are written down. An agent handed images and asked for defects will answer in whatever register the question was posed in: ask it how much darker the hem is and it returns a luminance mean, because that is what the answer is shaped like — not because it measured anything. Sometimes the estimate lands close and sometimes it inverts the finding; nothing in the report tells you which, and it reads as the strongest evidence there precisely because it is numeric. The same reflex names the crops and dumps it says it wrote.

• **Match the tool surface to the output contract.** Before spawning, read your

own prompt and ask which tool produces each claim you demanded. A judge with images and no shell can report what it sees and nothing else. If you want measurements, grant the tool that measures and name it in the prompt; otherwise stop asking for them.

• **A number without its command is not a finding.** Every quantity must arrive

with the command that produced it and that command's output, close enough to read together. Findings that fail this are struck, not discounted.

• **Verify, don't trust the eye of the verifier.** Run `scripts/receipts.mjs`

over the returned report — `node scripts/receipts.mjs <report.md>` — before you read the findings, so an unsupported number never gets to be persuasive first. It exits nonzero and prints each unbacked quantity and each file the report named but never wrote. `scripts/receipts.eval.mjs` is its own eval, over reports written in the eval whose right answer is known by construction, both directions pinned: run it after changing the checker, and never widen what counts as a receipt to make a failing case pass.

• **Know which half of it is proof.** The file check is proof: the path is

resolved on disk and a stated sha256 is recomputed, so an invented crop dies there. The number check is attribution, not execution — it asks w