audience-clarity-review
An HTML presentation has arrived — generated by impeccable or a peer session, soon to be shared with a technical audience. Style has been reviewed, rendering verified. What nobody checked: will the audience understand it? Concepts the author lives with for weeks are strangers to the reader; data that begs a chart sits in a paragraph; the same thing gets three names. This skill puts one reviewer on each comprehension axis and reports what will trip the reader.
Scope boundary — comprehensibility, not correctness. Whether a claim is true is out of scope (no ground-truth cross-check). Whether the audience can follow it is the whole job.
Position in the check stack
| Layer | Skill | Asks |
|---|---|---|
| Style / visual design | impeccable | does it look good? |
| Structure + render | html-render-check | does it parse and render clean? |
| Comprehension | this skill | can the audience follow it? |
Runtime requirements are identical to html-render-check (Playwright under ~/tools/playwright-runner, --no-sandbox on cluster nodes). On a fresh node, set up html-render-check first; this skill rides the same runtime. Screenshot capture reuses that stack via this skill's scripts/section-shots.mjs.
Process
-
Locate and read the artifact. Read the HTML fully. Note its section structure, the domain it covers, and the concepts it introduces. Check for a
CONTEXT.mdin the project directory — if present, it becomes the canonical vocabulary for Check 5. -
Pin the audience. From the content, guess who this is for, then ask the user via
ask_user_questionwith 2–4 concrete audience options (e.g. "backend engineers who know GPU basics but not CXL" / "infra team familiar with the project" / "mixed technical audience, no domain background"). The confirmed audience is quoted verbatim into every check brief — every axis judges against it.