SkillCDN 팩

Slides from a document, in the deck's own design

A document (a PDF) and a link to a Figma Slides deck go in; new slides come out, one per page of the document, in a row of their own, built from the deck's existing slides' measured specs: its type scale, colors, margins, title treatment, bullet marks, cards and shadows. The document's words, line breaks and images are kept as they are; only the design is the deck's. Every slide is checked before it is shown: content edges against the margins, one spec per element role, no text outside a card's padding, no word broken mid-way, and the alignment of glyphs, not boxes, on zoomed renders. Slides that existed before, and any slide the user edits during the run, are never rebuilt. Nothing is spent and nothing is deleted.

How the user is involved

• Questions: only for the document and the deck link, and only when the request lacks one. Everything else is derived and stated at the plan checkpoint.
• Checkpoints: the slide plan (page to slide, layout type each, the type scale, the font substitution, the row) and the audit (a screenshot of every new slide with the element inventory). Each is one short message; "OK" continues.
• Go-ahead: when the user says to go ahead alone, both checkpoints are skipped; the delivery still shows every slide's screenshot.
• Changes mid-run: a correction ("the bars differ", "the base size should be 22") re-enters at the audit and is applied to every new slide, not only the one named; the run then re-audits all of them.

Requirements

Check the tools before the first message. Without the Figma server, stop and ask the user to connect it; without a shell, stop and say that the document cannot be read. get_metadata does not work on Slides files: read the deck with use_figma only. Optional: get_screenshot for a slide the user wants to see at a chosen size; inline screenshots inside use_figma cover the run. How these tools behaved in this skill's own phases is in tool-notes.md; read it before phase 3.

Inputs

Workflow

Each phase produces a named artifact, written in a scratch folder outside any repository; the delivery says where. Phases stop only at the two checkpoints.

Phase 1: Intake

Produces the intake record: the document, the file key, the scratch folder, the tools found, and the deck's slide grid as it is now.

1. Both inputs in the request: say in a line what happens next and go on. One missing: ask for it and stop. "Which document and which deck? A PDF path and the deck's link."
2. Load Figma's guidance with get_figma_skill: the index, figma-use, figma-use-slides, and that skill's references for gotchas and the slide lifecycle. Pass the skill names in use_figma's skillNames as the guidance says.
3. Install the PDF reader in the scratch folder, and run every script from that folder as the working directory (document-reading.md "Setup").
4. List the slide grid with a read-only use_figma script: rows with their names, slides with id, name and child count. Every slide in that listing is protected; the audit compares against it.

Phase 2: Read the document

Produces the content map and the assets folder (document-reading.md; the map's shape in content-map.example.json).

1. Extract every text run with its font size, position and end-of-line flag, page by page; group runs into lines and lines into blocks; rank the sizes on each page and across the document into hierarchy levels (title, lead, heading, sub-heading, body, caption, page furniture) by document-reading.md "Hierarchy levels"; a bold run at the body size is a label inside its body block, not a level. Keep the document's line breaks in each block's text.
2. Render each page to an image and read it: assign each page a layout type from the catalogue in document-reading.md (cover, lead and cards, tiles with descriptions, numbered rows, device mockups with captions, timeline, two columns, closing), and note which blocks go into which region.
3. Extract the images (logos, mockups, photos): embedded images where the PDF has them, crops of a high-resolution page render otherwise; make page-colored margins transparent so that a crop does not show as a box on a colored slide.

Phase 3: Read the deck

Produces the deck spec (deck-spec.md; the JSON shape in deck-spec.example.json).

1. From the intake record's grid, take the content slides: every slide with running text below a title (deck-spec.md "Which slides to measure").
2. Measure them as deck-spec.md says: slide size, content margins, the title group (bar, title, subtitle, each with position and size), the body size, line height and color, the bullet mark (size, color, opacity, gap to text, offset from the first line's top), cards (fill, radius, shadow), tiles and accent shapes, the page-number treatment, and each text style combination with the slides it appears on.
3. List the fonts in use and check which load (deck-spec.md "Fonts"); record the substitution for any that do not.
4. Screenshot two representative content slides inline, to see what the numbers describe.

Phase 4: Slide plan

Produces the slide plan and the first checkpoint.

1. One slide per page, in the document's order: the page's layout type, the deck's layout that carries it (an existing slide's layout re-created at its coordinates where one matches the type, else the spec's parts composed as deck-spec.md "Layouts" says; a protected slide is never cloned), the blocks it holds and their hierarchy levels, the images it places, and the expected count of each element role (marks, cards, numbers, captions) that the audit will check.
2. The type scale from the base: the deck's sizes for the roles the deck has; a step down the deck's own ratios for the rest; line heights from the spec. A layout taken from a slide that holds fewer items than the page does gets its type one step down and its spacing refitted, before it is built.
3. The fit of each slide, estimated from line counts: each block's lines times its line height in pixels, plus the spec's gaps and paddings, against the content height. A page that does not fit at the scale is split into two slides that carry the same title, at a block boundary, and the plan says so; the type is not shrunk below the scale for it.
4. The preamble for the build: the spec as a constants object, the font loading, the helpers of deck-spec.md "The preamble", every spec value read from the object and none typed into a slide.

Checkpoint, in plain words: the page-to-slide list with each layout type and any split; the scale (base, and each role's size); the font substitution if any; the row the slides go in; that existing slides stay. "OK" builds.

Phase 5: Build

Produces the slides.

1. Create the row and the slides with the lifecycle guidance, re-reading the grid at the start of every call; move a slide that landed in another row with the row's appendChild (tool-notes.md "Slide rows").
2. Build three to five slides per use_figma call, each call starting with the preamble verbatim. Every node gets a name that says its role (Title bar, Card, Bullet bar, Number, Caption): the audit counts by name, and a later call addresses nodes by name, never by a size or font filter (tool-notes.md "Addressing nodes"). A slide itself keeps no name (Figma numbers slides), so a slide is found by its row and its index in it.
3. Text is created as deck-spec.md "Text" says: the characters with the document's breaks, the width set first and the auto-resize set to height after it, the vertical position computed from the box's height only after that order.
4. Upload the images with upload_assets, one node per image, and post the files one after another (tool-notes.md "Uploads").
5. Return the created node ids and each slide's child count from every call; screenshot the first batch's slides inline before the next batch.

Phase 6: Audit

Produces the audit report and the second checkpoint (audit.md).

1. Numeric, over every new slide: content edges within the deck's margins; the inventory of each element role by node name with one spec each and its count; the table of text style combinations against the scale; the overflow and overlap check from Figma's guidance; every text box's height against its font size (a collapsed box is repaired, tool-notes.md "Text sizing").
2. Visual: a full screenshot of every new slide, and a zoomed render of one instance of each element role (a bullet row, a numbered row, a title group, a timeline node, a caption) at three to four times, read for the glyphs against the mark or the shape they align with.
3. Fix what fails by the verdicts below and run both parts again, until nothing fails. A fix to one element role is applied to