One line on what to judge, and what to ignore.
The argument this one makes, in one line.
` renders as a broken icon the moment
the file moves. Base64 it into the page, or draw it in inline SVG or HTML.
- **Judging shape? Render it greyscale and say so in the lede.** Colour decides the argument
before they have looked at the structure.
## Opening it properly
**`open -a "Google Chrome" file.html` is not showing them anything.** It creates the tab and does
not bring the browser forward, so it stacks up behind whatever they are actually looking at. On
macOS use this instead:
```bash
osascript <<'EOF'
tell application "Google Chrome"
activate
set w to front window
make new tab at end of tabs of w with properties {URL:"file:///ABSOLUTE/PATH"}
set active tab index of w to (count of tabs of w)
end tell
EOF
```
`activate` brings the window forward and setting `active tab index` selects the new tab. You need
both. On Linux, `xdg-open` is the equivalent, and on Windows, `start`.
**Then verify it worked.** Read the active tab's URL back and check it is yours - another window
or another process may have taken focus in between:
```bash
osascript -e 'tell application "Google Chrome" to return URL of active tab of front window'
```
A command that exits 0 is proof it ran, never proof they saw it.
## What renders as HTML, and what must not
**HTML** for anything they will look at or share: plans, reviews, comparisons, reports,
dashboards, option grids, session handoffs.
**Plain text** for anything they will paste into another tool: social posts, newsletter bodies,
docs, config files, instruction files. HTML there breaks the paste target, and in a config file
it costs tokens on every future session while buying nothing.
State which one you are producing before you build it.
## Two things that ruin it
**No background grid or texture on anything text-heavy.** It looks good on a dashboard and makes
a dense document genuinely hard to read.
**Look at it yourself first.** A render you have not opened is a render you cannot describe
honestly, and it is how a broken page gets presented as a candidate.
## What you say around it
The render does the explaining. Your words around it should be almost nothing.
**Lead with the verdict, not the process.** First line is what they are looking at and what you
think of it. Never open with what you are about to do or how you got there.
**End with one next thing**, on its own line, doable now:
```
Next: pick a direction and I will build it out.
```
One next step, not a menu. Not "let me know if you want changes", not a list of five things they
could ask for. If there is genuinely nothing next, say the work is done and stop.
**Say the verdict out loud, including the failures.** "This one is broken, the other two are
worth looking at" beats silence, and it beats presenting a broken page as a candidate.
## Do not guess
The failure that wastes the most time is not a bad render. It is a confident one built on
something nobody checked.
If you do not know a filename, a number, a status, a path, or what a link points to, **go and
check it** - read the file, run the query, open the page. A plausible answer you did not verify
is the failure, not a shortcut.
If you genuinely cannot check, say **"not verified"** in those words and name what is missing.
Never fill a gap with something that merely sounds right, never infer a value from a filename,
and never report the result of a check you did not run.
This is the same instinct Anthropic's own guidance names in its hallucination guidance: give the
model explicit permission to admit uncertainty and say it does not know, rather than leaving it
to pick the most likely-sounding answer.
## The check before you speak
One question: **have they seen this, with their eyes, in this session?**
If no, you are not finished, however done the artefact is.