Skip to main content
ClaudeWave
ES, Spanish
Skill70.1k estrellas del repoactualizado 5d ago

save-as-pdf

Print-ready PDF export

Instalar en Claude Code
Copiar
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-pdf
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.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
3d-objectSkill

three.js model, downloadable as OBJ or GLB

animated-videoSkill

Timeline-based motion design

artifact-capabilitiesSkill

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.

artifact-designSkill

Design guidance and fundamentals for Artifacts.

artifact-diagrammingSkill

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.

batchSkill

Research and plan a large-scale change, then execute it in parallel across 5–30 isolated worktree agents that each open a PR.

claude-api-in-prototypesSkill

Call Claude from your HTML artifacts via window.claude.complete

claude-in-chromeSkill

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).