Present Skill

Takes a blog post and produces one HTML file that reads like a masterfully taught internal document: a title, a summary, real headings and short paragraphs, and a figure for every idea -- diagrams that move to show the mechanism, numbers set large, a formula typeset where the formula is the point. The author opens it and walks people through it, or shares the link and people read it alone. Both must work.

It is a document, not a deck. No full-screen sections, no hero, no scroll-snapping, no progress bar, no slide feel. The first screen is the title and the summary, and the page scrolls like any other. Single file, real selectable text, comfortable line length with defined width limits (--measure for prose column, with visual elements permitted to break out to --wide or --max-width), full theme support matching present-md, and a fixed section skeleton -- summary, context, body, sources -- so every document has the same shape.

It is not the blog either. The post merely recorded or explained; this document teaches. Write it as an expert engineer explaining the concept to a sharp peer: start from first principles, build direct intuition for why the problem is hard and why this solution exists, and make the narrative flow naturally from cause to effect. Text is minimal and ruthlessly optimized for understanding: each idea gets exactly enough prose to illuminate the mental model and make the concept click -- the figure, code, or format diagram carries the mechanism, while the prose anchors the intuition.

Audience: practicing engineers, not students. Ground explanations in first principles and physical or systems realities (e.g. disk seeks vs sequential I/O, cache line invalidation, network roundtrips). Favor concrete mechanics over abstract description -- pseudocode for algorithms, the on-disk or wire format for stored/transmitted structures, real code where the post has it. A mechanism explained only in prose gets translated into pseudocode or a format figure, not more prose.

The one rule that makes it look good

Assemble the system; design only when the concept earns it. The reference/ directory next to this file holds a finished design system: base.css, runtime.js, skeleton.html, svg-templates.md, and a verify.sh that checks the result. The document is built by pasting those verbatim and filling the slots, and most visuals are a template from svg-templates.md with the labels changed -- that stays the fast, safe default and should be your first move for every idea. But the catalogue is not a ceiling: when an idea's shape does not fit any row, or a different visual form would carry the concept more clearly than forcing it into an existing template, invent one. A custom visual is judged the same way a templated one is -- only the tokens base.css defines (never a new hex, never a gradient/blur/shadow/texture it doesn't already have), a <figure> with a <figcaption>, the mechanism-moves/evidence-stays-still rule, and every ban in Step 4 -- so it still reads as part of the same system rather than a different page bolted on. See "Going off-catalogue" in Step 2. What's gone is the requirement to force every idea into an existing box-and-arrow arrangement when a better shape exists.

Read skeleton.html, svg-templates.md, at least one post in reference/examples/ so you know what a source looks like, and examples/bitcask.spine.md -- a real spine for one of them, with the wrong spines it avoids -- before starting. Do not skip this because the task looks simple. Do not read base.css or runtime.js in full: they are injected mechanically in Step 5, never retyped, and everything you need from them (the component classes, the theme tokens) is documented in this file, the catalogue, and the skeleton's examples.

Input Handling

The user may provide input in any of these forms. Identify which it is before doing anything else.