DocStash

Generate a beautiful, print-ready PDF document for DocStash and show the user an INLINE PREVIEW: reports, memos, proposals, letters, résumés, whitepapers, contracts, essays, one-pagers. THIS IS THE DEFAULT for a generic 'make me a document' / 'make me a PDF' request (use `create_text` for markdown/code source, `create_page` for a web page). `content` = HTML you author, and DocStash renders + presents it AS A PDF (paginated paper, page nav, zoom, one-click PDF download). Do NOT generate a binary .pdf; the user drag-and-drops pre-existing .pdf files on the dashboard. This is a REAL HTML/CSS document rendered by a full Chromium engine and baked to PDF — you have the SAME visual toolkit a web page has (any CSS layout, SVG, gradients, filters, transforms, web fonts, images), NOT a limited document format. It is a STATIC print document: NO `<script>` / JS runs (it is rejected) — draw every chart, diagram and graphic as hand-authored inline SVG + CSS (crisp, and how the best docs are built). The ONLY difference from a live web page is GEOMETRY: it prints onto fixed US Letter pages that never scroll or reflow. PAGE MODEL — TWO ways to build a page, mix them freely in one document: 1. FLOW (default) — author continuous, top-to-bottom HTML (US Letter, 816x1056px @96dpi). You do NOT emit per-page blocks or decide where breaks fall: DocStash flows your content across as many pages as it needs and paginates for you (keeping headings with their text; not splitting tables / figures / cards). Best for running text, long tables, card lists — anything whose length you can't predict. 2. CANVAS — `<section class="pdf-canvas">` is a FIXED one-page design surface: exactly one sheet, edge-to-edge, a positioning context. Inside it you CAN and SHOULD absolutely-position art, full-page backgrounds, and edge-anchored elements against KNOWN bounds — compose it like a POSTER. Its content auto-fits to one page at bake, so design ~a page without measuring height. Use a canvas for the set-pieces that make a doc look designed: the COVER, section dividers, full-page infographics / charts / hero spreads. Opt-in controls anywhere: `<div class="pdf-break"></div>` forces a fresh page; `pdf-keep` keeps a card / figure / callout from splitting; `<section class="pdf-bleed">` is a full-bleed page that still FLOWS (for a themed section whose background reaches the edges but whose length is unknown). IMPORTANT — `pdf-break` / `pdf-canvas` / `pdf-keep` / `pdf-bleed` are ENGINE-RESERVED: apply the class as-is, never redefine or restyle the class itself (especially its `break-*` properties) — the engine owns those, and overriding them corrupts pagination (e.g. blank pages). Style the CONTENT you put INSIDE a primitive freely. DESIGN THE DOCUMENT: • Make page 1 an attractive COVER — a `pdf-canvas`: absolutely-position the title, a full-bleed background, and any art against the fixed page, the way a poster is composed. Reach for a canvas again for section dividers and full-page infographics. • VISUALIZE — show as much as you tell, all as hand-authored inline SVG (+ CSS): charts (bar/line/donut via `stroke-dasharray`), timelines, diagrams, stat panels, maps, iconography, a signature motif derived from the subject. This is what makes a doc look designed — and it is exactly how the best docs are built (no JS needed). • RUNNING HEADER / FOOTER (optional) — put page numbers, a title strip, or a small logo on every page via CSS `@page` margin boxes, in ANY edge or corner (`@top-left`, `@bottom-center`, `@top-right-corner`, `@left-middle`, …), styled however fits. Fill it with the page counters (`counter(page)`, `counter(page) " / " counter(pages)`, `counter(page, decimal-leading-zero)`), a running `string-set` section title, or a `position:running()` element (e.g. a logo). Omit it entirely for a résumé / invite / one-pager. Cover, `pdf-canvas`, and full-bleed pages are kept clear of it automatically. • TYPE SCALE — 816px wide = US Letter 8.5in, so **1 CSS px = 0.75pt**: `11px` body copy PRINTS AT 8.25pt. Size in px but think in pt — body copy ~13-15px (~10-11pt), never below 11px for anything a reader must read; 9px (~7pt) is the floor for incidental labels / footers. • FILL each page — a sheet is a WHOLE page whether or not its content fills it, so a half-empty interior page reads as a mistake, not restraint. Pace and size content (type scale, spacing, columns) so every page is ROUGHLY FULL; only the FINAL page should run partial, and never orphan a lone heading or a few trailing lines. Balanced, full pages are what separate a designed document from an exported one. • MARGINS — the engine ALREADY applies a comfortable page margin (0.7in) so text never runs to the paper edge; do NOT add your own outer page margin or wrap pages in your own padding on top of it (that double-margins the page). To bleed to the edge on purpose (cover, background, edge-to-edge image), use `pdf-bleed` — it zeroes the margin for that page. • To carry a color / dark theme edge-to-edge across EVERY page (not just the cover), set it on the page background — `@page{background:...}` + a matching `body` color. In FLOW content do NOT pin heights or absolutely-position a page layout (no `height:11in`, no `100vh` — the engine owns flow pagination); absolute positioning and a fixed page box are for INSIDE a `pdf-canvas`, where they are the whole point. • Self-contained: inline all `<style>`; load fonts / images / libraries from absolute https/CDN URLs. IMAGES & FONTS — image/font URLs MUST be DIRECT files (a gallery/viewer page renders BROKEN); the direct-URL recipes, sizing, and custom-font rules are in the server instructions (VISUAL DOCUMENTS & MEDIA). REPEATING gradient patterns (`repeating-linear-gradient`, tightly-tiled backgrounds) rasterize unreliably in print — build stripes / hatching from REAL repeated elements (divs / spans) instead. Nothing is stashed yet — then STOP: do NOT call `stash` yourself; the user reviews the preview and saves it. Once stashed, the doc is at a PRIVATE url (the user, their workspace members, and people they've granted access) until published with `set_public_link`. Full lifecycle, slug/versioning, attribution + publish rules: DocStash server instructions.

create_pdf

Generate an INERT text artifact — markdown, source code, or raw data — for DocStash and show the user an INLINE PREVIEW. This is for content the user READS AS SOURCE (typography for markdown, syntax highlighting for code), never executed or rendered as a page. Set `extension` to the file's extension, which the doc keeps for good (the extension is the file's kind and its download name): • 'md' — markdown. Content = the markdown source. For prose, notes, READMEs, technical docs, documentation of any kind. • any other extension — source code or data: 'py', 'ts', 'go', 'rs', 'json', 'yaml', 'csv', 'sql', 'vue', … Content = the raw source string. Omit `extension` for plain text (.txt). A new version (`slug`) keeps the doc's extension: omit `extension`, or pass the same one. ROUTING: scripts, code files, READMEs, configs, raw CSV/JSON → here. A LIVE rendered page → `create_page`. A designed PDF (and any generic 'make me a document/PDF' ask) → `create_pdf`. Nothing is stashed yet — then STOP: do NOT call `stash` yourself; the user reviews the preview and saves it. Once stashed, the doc is at a PRIVATE url (the user, their workspace members, and people they've granted access) until published with `set_public_link`. Full lifecycle, slug/versioning, attribution + publish rules: DocStash server instructions.

create_text

Generate a WEB PAGE (a single self-contained HTML file, rendered live) for DocStash and show the user an INLINE PREVIEW: landing pages, visual/interactive dashboards, infographics, demos, interactive web apps and games (React, three.js, d3, … loaded from a CDN) — anything the user should SEE RENDERED rather than read as source. Content = a complete `<!doctype html>` document with everything inline (`<style>`, `<script>`) and any images/libraries referenced by absolute URL or CDN. IMAGES & FONTS — image/font URLs MUST be DIRECT files (a gallery/viewer page renders BROKEN); the direct-URL recipes, sizing, and custom-font rules are in the server instructions (VISUAL DOCUMENTS & MEDIA). Viewer provides chrome — don't wrap. DocStash hosts it live. Load any JS deps as `<script type="module">` ESM (esm.sh) or inline them — never reference a local build-output path (the file won't exist). ROUTING: a live page or web app → this tool, as ONE self-contained file (inline your CSS and JS). Markdown / source code / raw data → `create_text` (inert source, not a rendered page). A designed PDF document → `create_pdf`. RESPONSIVE — the page MUST reflow + scroll on mobile: include the `<meta name="viewport">` tag and DON'T lock it to `height:100vh` + `overflow:hidden` (that traps phone scrolling). The viewer renders full-width, no extra scroll container. Nothing is stashed yet — then STOP: do NOT call `stash` yourself; the user reviews the preview and saves it. Once stashed, the doc is at a PRIVATE url (the user, their workspace members, and people they've granted access) until published with `set_public_link`. Full lifecycle, slug/versioning, attribution + publish rules: DocStash server instructions.

create_page

Discard a preview (from a create_* tool) without stashing it. Call this when the user rejects it (e.g. 'discard', 'never mind', 'don't save it'). The unsaved draft is moved to Trash (recoverable from there), so it can no longer be stashed unless restored.

discard

The DEFAULT way to change a PDF — edit it in place, or copy it into a new one. Emit ONLY the changes as `{ old_string → new_string }` pairs, not the whole document. `edit_pdf` edits only a PDF; a wrong-type call names the right tool. When to edit vs re-run a create tool, and iterate-vs-new-doc: DocStash server instructions. - `old_string` must be text that appears in the CURRENT source — call `read_document` first to get it, and copy it verbatim with enough surrounding context to match EXACTLY ONE place (or set `replaceAll`). Whitespace differences are tolerated. A stale or ambiguous `old_string` fails cleanly and changes NOTHING, so re-read and retry. - `new_string` replaces it; an empty string deletes the matched text. - Edits apply in order, each to the result of the previous. - **In-place** (default): the change lands as a new version of `slug`, shown as a fresh inline preview. - **Copy mode** (`copy: true` + `name`): leaves `slug` UNTOUCHED and produces a NEW doc — a filled-in copy with your edits applied. The TEMPLATE flow: keep one master, spin off variants (an invoice/offer-letter/report template → a copy per client). Returns the new doc's own slug.

edit_pdf

The DEFAULT way to change a markdown / text / code doc — edit it in place, or copy it into a new one. Emit ONLY the changes as `{ old_string → new_string }` pairs, not the whole document. `edit_text` edits only a markdown / text / code doc; a wrong-type call names the right tool. When to edit vs re-run a create tool, and iterate-vs-new-doc: DocStash server instructions. - `old_string` must be text that appears in the CURRENT source — call `read_document` first to get it, and copy it verbatim with enough surrounding context to match EXACTLY ONE place (or set `replaceAll`). Whitespace differences are tolerated. A stale or ambiguous `old_string` fails cleanly and changes NOTHING, so re-read and retry. - `new_string` replaces it; an empty string deletes the matched text. - Edits apply in order, each to the result of the previous. - **In-place** (default): the change lands as a new version of `slug`, shown as a fresh inline preview. - **Copy mode** (`copy: true` + `name`): leaves `slug` UNTOUCHED and produces a NEW doc — a filled-in copy with your edits applied. The TEMPLATE flow: keep one master, spin off variants (an invoice/offer-letter/report template → a copy per client). Returns the new doc's own slug.

edit_text

The DEFAULT way to change a web page — edit it in place, or copy it into a new one. Emit ONLY the changes as `{ old_string → new_string }` pairs, not the whole document. `edit_page` edits only a web page; a wrong-type call names the right tool. When to edit vs re-run a create tool, and iterate-vs-new-doc: DocStash server instructions. - `old_string` must be text that appears in the CURRENT source — call `read_document` first to get it, and copy it verbatim with enough surrounding context to match EXACTLY ONE place (or set `replaceAll`). Whitespace differences are tolerated. A stale or ambiguous `old_string` fails cleanly and changes NOTHING, so re-read and retry. - `new_string` replaces it; an empty string deletes the matched text. - Edits apply in order, each to the result of the previous. - **In-place** (default): the change lands as a new version of `slug`, shown as a fresh inline preview. - **Copy mode** (`copy: true` + `name`): leaves `slug` UNTOUCHED and produces a NEW doc — a filled-in copy with your edits applied. The TEMPLATE flow: keep one master, spin off variants (an invoice/offer-letter/report template → a copy per client). Returns the new doc's own slug.

edit_page

Internal — the inline preview widget fetches its own document bytes here. Not for direct agent use.

get_file

Internal widget poll — the latest details for a preview (its current name + this version's status). Not for direct agent use.

get_document

List the workspaces (personal + team; ids and tool names call them organizations) the user can save documents to, with the currently-active one flagged. Call this to resolve a spoken name like "my team workspace" to its id before set_organization. Call them workspaces when talking to the user.

get_organizations