typesetter

name

typesetter

description

Turn any content into a beautifully typeset, single-file HTML document in the user's established reading design (warm paper, serif body, blueprint accents), because the user finds raw markdown daunting to read. PRIMARY TRIGGER is the slash command "/paper [topic or content]": when the user types this, ALWAYS trigger this skill. Also trigger on "/typeset" (alias) and on explicit phrases like "make this an html doc", "html version of this", "design this as a document", "make this readable like my guide", "explain this in my html style", or any request for a well-designed, readable HTML document, guide, explainer, or report. Also trigger when the user asks to convert a markdown file or a chat's conclusions into a designed document. Do NOT trigger for interactive artifacts with state and controls (that is /aha or /crack), for web apps or dashboards, or when the user explicitly wants markdown, docx, or pdf output.

Typesetter

Turn content into a single-file HTML document the user will actually enjoy reading. The design system is fixed and lives in assets/template.html; the craft is in the writing and in choosing the right component for each piece of content. Output is one .html file saved to /mnt/user-data/outputs/ and shared via present_files.

This is a reading document, not an app: zero JavaScript, no controls, no state. If the request needs interaction, it belongs to /aha or /crack, not here.

The three inputs it accepts

1. A topic: "/paper why vector databases exist". Research or draw on knowledge, then typeset the explanation.
2. Content already in the conversation: "/paper this plan", "make what we just discussed readable". Typeset the conversation's substance.
3. A file: an uploaded markdown or text document. Read it, restructure it for reading, typeset it.

If the invocation is bare ("/paper") with nothing pointing to content, ask one question: what should the document teach or contain, and who is the reader.

Process

1. Find the thesis before writing anything. Every document carries exactly one thesis panel: the single most important idea. If it cannot be stated in two sentences, the content is not yet understood. Do the thinking first.
2. Outline as sections. One idea per section, six to eight sections for a full document, fewer for a short one. Order them as a reader's journey: the problem, the cast, the mechanics, the practice, the close.
3. Map content shapes to components. Read references/components.md for the library and the shape-to-component table. The binding rule: structure must encode something true. Numbered flows only for real sequences, cards only for real parallel peers, callouts at most one per section.
4. Write the copy. Rules below.
5. Fill the template. Copy assets/template.html, keep every line of its CSS untouched, write only the HTML inside .wrap. The design system is not to be restyled, extended, or "improved" per invocation; its consistency is the point. The one permitted knob: if the user explicitly asks for a different accent mood, adjust the three --accent-* hues and nothing else.
6. Save and present. Name the file after the subject, save to /mnt/user-data/outputs/, share with present_files. In the chat, one short line on what the document covers; the document speaks for itself.

Writing rules

• Write for the stated reader. Default is an intelligent beginner: plain words, short sentences, no jargon without an immediate plain-terms translation. If the user names a different audience, match it.
• Second person, active voice. The reader is "you". Things do things: "forge writes the plan", not "the plan is written".
• Analogies for abstract ideas only. One per section at most, drawn from the physical world (workshops, buildings, logbooks). Skip when the idea is already concrete.
• Bold sparingly, as signposts. One <strong> phrase per paragraph at most, marking the sentence's load-bearing idea.
• No filler, no throat-clearing. Every sentence either teaches or moves. Cut "in this section we will".
• Honest structure. The kicker tags the section truthfully. The footer closes warmly in one line and never summarizes.
• Simple vocabulary, no em dashes. House style, always.

Quality floor

Before presenting, verify: renders from a single file with no external requests, readable at 360px width, all < > inside snippets escaped, exactly one thesis panel, heading hierarchy intact (one h1, sections use h2), and the CSS block is byte-identical to the template except for permitted accent changes.