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
- A topic: "/paper why vector databases exist". Research or draw on knowledge, then typeset the explanation.
- Content already in the conversation: "/paper this plan", "make what we just discussed readable". Typeset the conversation's substance.
- 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
- 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.
- 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.
- Map content shapes to components. Read
references/components.mdfor 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. - Write the copy. Rules below.
- 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. - Save and present. Name the file after the subject, save to
/mnt/user-data/outputs/, share withpresent_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.