PDF → Interactive Web Page

Workflow

1. Define the scope

• When the PDF exceeds roughly 30 pages, do not turn the entire document into a web page. Stuffing an entire book into one web page can only turn it into a shallow directory site and destroy the experience of “reading.” Start with one section: one that is self-contained, visually compelling, and has something the reader can interact with. If the user is present, offer 2–3 candidates for them to choose from; if not, choose one yourself and state in the delivery notes which section you selected and why.
• If the user wants a map of the entire book (character relationships, chapter structure), build a “navigation layer” and explain that it is based on the table of contents or external knowledge rather than the full text.

2. Read the source and determine the reading mode

references/reading-modes.md

3. Build the fact ledger before writing the page

id → source page → exact source sentence (preserve the original language) → your plain-language restatement

references/fidelity-checklist.md

4. Define the structure (simple and focused)

• The first screen is the “30-second version”: one plain-language sentence that explains the most important conclusion, paired with a global graphic (map, structure diagram, flowchart, or argument map). After reading the first screen, the reader should know what the document is about and whether it is worth continuing.
• No more than 7 scenes. Each scene has three layers: a one-sentence takeaway (always visible) → a hands-on interaction (expanded by default) → details and the original text (collapsed by default).
• Keep all default-visible text under 2,500 Chinese characters; put anything beyond that into collapsed sections. Do not constrain yourself with adjectives such as “concise” or “time-saving”—count the characters. In the experiment, writing only “save time” actually doubled the text length; specifying a 2,500-character limit reduced the same chapter from 11,495 characters to 2,710.
• Introduce terminology with an everyday analogy first, then give the formal term.
• Include at least 2 “guess, then reveal” moments: first let the reader guess a number or choose an answer, then reveal the answer from the source. Readers remember it better after guessing, and this is the most fun part.
• End with 3 “Can you answer this?” questions, with sources attached to the answers.
• Write explanations in your own words; quote original sentences only in side-by-side source comparisons (and avoid reproducing long copyrighted passages of annotations or commentary).

5. Define the style and create the key visuals

• Follow the user’s chosen style; if none is given, choose one based on the content. Keep the color palette, typography, lines, and textures consistent throughout. See

  references/style-presets.md

  for style presets.
• Create only 2–4 large key visuals, selecting the most important moments and treating each as an independent work of art: pay attention to composition, foreground, middle ground, and background, and incorporate details mentioned in the source (objects, clothing, text, numbers, place names). Support the remaining scenes with typography, charts, and small decorative elements. The reason is that as the number of illustrations increases, each one receives less attention, until the screen is filled with sloppy small images.
• Do not build people from basic geometric shapes such as circles and rectangles; do not use cartoon faces or emoji. If people are difficult to draw, depict a back view, silhouette, close-up, or object instead, or let typography itself carry the visual.
• Write art direction, not technique details. In the experiment, “simulate traditional Chinese painting” produced better results than a version packed with instructions about ink-outline drawing, ruled architectural drawing, SVG filter parameters, and so on: the more technique-specific the prompt, the more concerned the model becomes with whether the strokes look right, and the weaker composition and detail become.

6. Write the page

references/page-contract.md

7. Self-check, then deliver

1. Run

   python3 scripts/audit_html.py <your index.html>

   . It will list external resources, the default-visible word count, the number of source citation markers, whether all required features are present, and every sentence on the page that contains a number. Fix the page based on the report.
2. Select the 12 hardest claims on the page (numbers, quotations, rules, causal statements, and the first-screen conclusion) and verify each against the source. If a claim cannot be verified, either correct it, remove it, or explicitly mark it as an “inference.” This cannot replace verification by the reader, but it blocks the most common errors.
3. If you can open it in a browser, check that the console has no errors and that there is no horizontal overflow at mobile width.

Delivery

• File:

  index.html

  .
• Give the user a 3–5 line explanation: the reading approach, the scenes, what the 2–4 key visuals depict, what from the source was left out, and which content is inferred or illustrative.
• Include a reminder to click the citation markers and check the original sentences for key numbers and rules.

Environments without Skill

references/prompt-standalone.md