save-as-pdf
Print-ready PDF export
git clone --depth 1 https://github.com/asgeirtj/system_prompts_leaks /tmp/save-as-pdf && cp -r /tmp/save-as-pdf/Anthropic/claude-design/skills/save-as-pdf ~/.claude/skills/save-as-pdfSKILL.md
# Save as PDF Reformat the current HTML design into a paginated, paper-ready PDF. The "Instant" export already gives the user a PDF at the design's native pixel size — this path is for when they want real pages. **Do NOT rasterize the page into a PDF.** Never use jsPDF, html2canvas, dom-to-image, or any other canvas/screenshot-to-PDF approach — they produce blurry, non-selectable, oversized output, and do not generate a PDF binary yourself. PDF export is print-based: a print-ready copy is handed to `show_pdf_export_dialog` and the browser's own print engine renders crisp, selectable, text-based pages. The only supported way to make a copy print-ready is a component that owns its print geometry — the doc_page starter for documents, or a source already built on `<deck-stage>` or `<doc-page>`. Do not hand-author `@page` rules or print CSS resets, and NEVER declare `<meta name="omelette-owns-print">` yourself — the starters announce print ownership at runtime, and a hand-authored meta tells the platform to trust print CSS you would then have to hand-write and maintain. Hand-rolled print CSS behind that meta is the legacy path; the doc_page starter replaces it everywhere it is available. ### Steps 1. **Read the current HTML design file** to understand its structure and content. Re-read it on every PDF request, even if you read it or made a print copy earlier in this conversation — the user may have changed content or tweak values (the Tweaks panel writes into the source file) since then. Note the `[version: v<N>]` token in the read result's header — step 2's provenance stamp needs it, and only a version read in THIS request is valid to stamp. 2. **Write the print copy, stamped with its provenance.** Always write it fresh from the source you just read — an existing `-print` copy from an earlier request is a stale snapshot, and reusing or only partially updating it ships outdated values to the PDF. The print file path is the source path with `-print` inserted before the extension — same directory, same basename. If the source is `slides/deck.html`, write `slides/deck-print.html`; if the source is `web/index.html`, write `web/index-print.html`. **Do NOT** use the deck title or project name as the filename, and **do NOT** write to the project root if the source is in a subdirectory — any change in directory depth breaks every relative URL (`@font-face` `src: url(...)`, `<img src>`, `<link href>`, CSS `background: url(...)`) and the print tab shows missing images and system-font fallbacks. **Stamp the copy's provenance (required whenever the read header shows a version — every arm of this step).** Include this tag in the copy's `<head>`, carrying the version from step 1's read header and the source's project-relative path (for a read header of `[File: designs/report.html] [version: v172]`): ```html <meta name="omelette-print-source" content="v172 designs/report.html"> ``` `show_pdf_export_dialog` REFUSES a copy whose stamp is missing or no longer matches the source's current version — that is what makes a stale copy un-exportable. If it refuses with a stale-copy error, go back to step 1 (re-read the source) and rewrite the copy fresh; never just add or edit the stamp on an existing copy. If the read header shows no `[version: ...]` token, the project isn't versioned — omit the stamp; the export tool skips the freshness check there. **If the source is already built on `<deck-stage>` or `<doc-page>`, the copy is the source plus content-level print rules only.** Both components own their print geometry — never add an `@page` rule or reflow their layout. For `<deck-stage>` decks, set `data-deck-active` on **every** direct-child slide (not just the current one) so `[data-deck-active]`-keyed entrance styles resolve on every page — each slide is already one page. For `<doc-page>` documents there is nothing structural to do. **Otherwise, rebuild the content on the doc_page starter.** Call `copy_starter_component` with `kind: "doc_page.js"` (once per project — the component file persists), then decide the pagination UP FRONT: a FLOWING document (pour the content into `<doc-page margin="0.75in">` as one normal HTML flow; the print engine paginates it — the default for reports, memos, letters, long-form), or EXPLICIT pagination (one `<section class="page">` child per page — when the user asks for a page count or the design implies one: a one-page resume, a two-sided flier, a certificate, a brochure). If in doubt, ask the user. Keep the design's typography, colors, and imagery intact either way. For FLOWING documents the component pins no paper size — the print engine paginates onto the user's real paper. Explicitly paginated pages print at a FIXED page box with overflow hidden — letter by default (set size="a4" for a clearly metric user), the user's chosen paper when they export — and content that misses the box is clipped, never reflowed: design each page to FILL the page box and fit letter and A4 alike without overlap (no viewport units — they track the window, not the page). `orientation="landscape"` for landscape sheets. The component owns the sheet, the pagination, and all print geometry — do NOT write your own `@page` rule, print-CSS reset, page-card divs, hard-coded paper dimensions, or `break-after: page` fake sheets. In flowing documents use `break-before: page` only where a section genuinely starts a new chapter; long tables get a `<thead>` so the header repeats on every page. **A fixed-canvas design (poster, social graphic, infographic) also goes through the doc_page rebuild, with one decision: the page.** Print it at its true dimensions — `<doc-page width="18in" height="24in" margin="0">`, the page IS the design (use explicit width/height ONLY when the user gives or implies a real physical size) — or scale it onto standard paper — `<doc-page size="letter" content-width="960px" content-height="1440px">` (`size="a4"` when the user is clearly metric), where the cont
Deep research harness — fan-out web searches, fetch sources, adversarially verify claims, synthesize a cited report.
Author or improve the run-<unit> skill - a per-project skill that tells agents how to build, launch, and drive this project's app. Use when the user asks to set up the project, get it running, write run instructions, or verify build/run steps work from a clean environment.
Runtime capabilities a published Artifact page can be granted — behavior static HTML cannot provide on its own, such as the page reading live or connected data, remembering what people do on it (a poll, a sign-up sheet, a checklist, a document edited in place — it saves new versions of itself), keeping state shared across viewers, knowing who is viewing, asking Claude a question of its own, storing files people add, or handing the viewer a file to save. Serves this user's live capability roster and the typed call definitions. Load it whenever the user asks for an artifact needing any such runtime behavior.
Design guidance and fundamentals for Artifacts.
Diagramming know-how for Artifacts - when a picture earns its place, how to draw one that shows the real mechanism, and the inline-SVG mechanics that keep it legible in both themes.
Research and plan a large-scale change, then execute it in parallel across 5–30 isolated worktree agents that each open a PR.
Automates your Chrome browser to interact with web pages - clicking elements, filling forms, capturing screenshots, reading console logs, and navigating sites. Opens pages in new tabs within your existing Chrome session. Requires site-level permissions before executing (configured in the extension).
Review the current diff, or a PR number/branch/path target, for correctness bugs and reuse/simplification/efficiency cleanups at the given effort level (low/medium: fewer, high-confidence findings; high→max: broader coverage, may include uncertain findings; ultra: deep multi-agent review in the cloud); with no level given, it reuses the level you typed last. Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the review. For ultra on a GitHub.com PR target, --post asks to post the finished review’s findings to the PR as a single comment from the user’s GitHub account (not a review; the launch dialog still confirms in interactive sessions, while non-interactive mode posts on the flag alone) and --no-post hides that option.