見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
html-confirm: HTML when there is something to SEE, chat when there is not
The failure this skill exists to prevent runs in both directions. Asking someone to choose between sixteen images inside a chat message is unusable. Building a whole HTML page so someone can answer "A or B" is friction dressed up as service.
The line to draw
| Situation | Surface |
|---|---|
| They must look at an image, design, storyboard, render, layout, cover, or any generated artifact to decide | HTML page, opened locally |
| They are reacting to a report, audit, comparison, options-with-tradeoffs page, or status dashboard | HTML page |
| The decision needs per-item notes across many rows, or may be answered across several sittings | HTML page with a review layer |
| A plain choice among a few text options | chat, option cards are fine |
| Session-start scoping, "should I proceed", yes/no gates | chat |
| A one-line clarification | chat, plain text |
The mechanical test when unsure: can the thing being decided fit inside a chat option card? If it is a picture, a page, or sixteen variants, it cannot, so build the page. If it is "A or B", it can, so just ask.
Still true regardless of surface: the capture rule
Before asking anything, answer this: when they finish answering, how do the answers actually get back to me? Two real ways this breaks:
- A reviewer fills in an in-page review layer, clicks export, and the download silently fails, so
the whole round of feedback is lost. Fix: also write the export into a selectable, auto-selected textarea, so a blocked download still yields copyable text.
- A sandboxed iframe preview breaks
localStorage, downloads, and the clipboard. Never hand
someone a sandboxed embedded page for a decision that involves per-item state. Give them a local file and open it.
What to produce (when HTML is the right surface)
ONE self-contained .html file that:
- States the decision up top in plain language, plus how to answer ("reply A / B / C, or tell
me what to tweak"). Lead with the ask.
- Shows the actual thing being decided. This is the whole reason the page exists. Embed the
images, render the options side by side, show before and after, display the artifact under review.
- Lists each option with a one-line tradeoff, and marks your recommendation.
- Adds terse context that changes the choice: cost, risk, what is blocked.
Format: inline <style>, real content only, UTF-8 and CJK-safe, no heavyweight frameworks. Reference local images by relative path, or base64-embed them when the page needs to be portable.
If you keep a reusable review-layer template, append it to the file rather than re-authoring it each time:
cat <PATH_TO_YOUR_REVIEW_LAYER_TEMPLATE>.html >> <report>.htmlWhere to save and how to open
- Save the file where the topic lives, for example
<project>/docs/<topic>-confirm.html. - Open it locally:
open "<path>"on macOS. Skip auto-open on headless or unattended runs. - Print one line:
Opened: <path>. - Then stop and wait. Do not also ask the same question in chat.
- If they say they cannot open it, do not re-send the same page. Put the decision in chat as a
short lettered list answerable in three lines, and ask whether a different format (PDF, plain text) suits the device they are on.
Minimal skeleton
<!doctype html><html><head><meta charset="utf-8"><style>
/* clean, inline, theme-aware; recommendation card highlighted */
</style></head><body>
<h1><Decision></h1>
<p>Reply <b>A</b>, <b>B</b>, or <b>C</b>, or tell me what to tweak.</p>
<!-- option cards, recommendation marked -->
<!-- the visuals being decided: <img src="../path/to/art.png"> -->
</body></html>