/deck-import

name: deck-import
description: Convert any PDF or PPTX deck into a self-contained interactive HTML deck, one file, one link, shareable. Auto-detects input file extension (.pdf or .pptx) and routes to the matching extraction path. Detects which of the 5 deck types the source is (pitch, sales, launch, keynote, all-hands) and hands off to the matching deck-* skill. Trigger when the user uploads a .pdf or .pptx of any deck type, or says any variation of "convert this PDF to HTML", "turn this PPTX deck into HTML", "import this deck", "upgrade my deck", "make my deck interactive", "migrate my deck from PDF/PPTX". Mirrors source palette, typography, and slide structure 1-to-1 (no redesign), preserves slide count, uses extracted screenshots on demo slides where applicable, auto-extracts key fields, then confirms with the user before building. Reuses deck-builder core pipeline and per-type spines as role-labeling taxonomy. Fastest path from cold PDF or PPTX to warm shareable link.

Deck Import (PDF or PPTX, HTML Deck, generic across 5 deck types)

**Keep your process invisible.** Do not narrate the skill architecture (the "type pack" and "core" split) or announce which files you are reading. Skip preambles like "I'll start by reading...". Gather what you need, then build the deck.

You are converting a **PDF or PPTX deck** into an **interactive HTML deck**, the entry point for users who already have a deck and want the upgrade (shareable link, scale-to-fit canvas, navigation shell) without a redesign.

**Core principle**: the user's deck is already the deck. Your job is to faithfully reproduce it in HTML, not to redesign it. Mirror the palette. Mirror the typography where possible. Preserve slide count and order. Keep their words. The "upgrade" is the delivery medium, not the content.

**Two build modes, page-image is the default.** The skill ships two Phase 3 implementations:

• **Mode A, page-image (DEFAULT)**: each slide is rendered as a full-bleed background image of the source page. The HTML provides only the shell, role-meta pill on interior slides, progress bar, nav arrows, counter, scale-to-fit canvas, touch swipe. **Pixel-faithful by construction**, no palette drift, no typography mismatch, no source-text ghosting, no logo recreation. One-shot quality on virtually every deck. See `references/page-image-mode.md`.
• **Mode B, reconstruction (OPT-IN)**: every slide is rebuilt in HTML/CSS/SVG. Editable, but risk-prone: palette guessing, source-text ghosting on photo backgrounds, content rewriting, layout drift. Use only when the user explicitly asks to be able to edit slides later, or to upgrade specific visual components. The user opts in during Phase 2 by replying "reconstruction" or "rebuild".

Default Mode A. Switch only on explicit opt-in.

This skill is generic across 5 deck types, **pitch, sales, launch, keynote, all-hands**. It is NOT a general document converter. PDFs or PPTX files that aren't decks (whitepapers, resumes, research papers, portfolios) should be redirected to a doc-builder skill.

Conceptually, deck-import is **a type-pack-like layer in front of `deck-builder` + the matching `deck-<type>` skill** (Mode B only, Mode A doesn't need the handoff skill for build, only for role-label vocabulary). Mode A adds three front-end phases (Extract, Analyze, Confirm) plus a thin Mode A shell build. Mode B adds the same front-end phases then hands off to the standard reviewer gates per `references/review-adaptations.md`.

If the user has not installed `deck-builder` or the relevant `deck-<type>` skill for the detected type, surface the gap early and ask them to install.

---

Auto-detect (Phase, 1, file-extension routing)

Before any extraction runs, examine the input file extension:

input_path = <user-supplied file path>
ext = lowercase suffix of input_path

if ext == ".pptx":
    → PPTX-only path (Phase 0p)
elif ext == ".pdf":
    → PDF path with optional sibling .pptx check (Phase 0)
else:
    → ask the user: "deck-import handles .pdf and .pptx files only. What did you mean?"

The PPTX-only path skips PDF rasterization entirely and uses `scripts/extract-pptx-only.py` (see Sub-phase C). It produces a JSON manifest with per-slide text, embedded images, speaker notes, and slide order. The PDF path runs the established extraction pipeline and OPTIONALLY uses sibling PPTX assets when available for higher fidelity.

Both paths converge at Phase 1 (Analyze) using the same `classification.json` shape, so everything downstream (Confirm, Build, Review, Release, Learn) is identical regardless of input format.

---

When this skill runs (trigger anatomy)

The trigger description (in YAML frontmatter above) is deliberately broad because this is the primary adoption ramp for users who already have a deck. If the user uploads a PDF or PPTX that could plausibly be any of the 5 deck types AND mentions HTML, interactive, conversion, import, migration, or "upgrade" in any form, this skill is right.

**Edge cases**:

• File ambiguous between two deck types (e.g., reads like an all-hands OR a keynote): the Phase 1 classifier surfaces both in the confirmation block with scores. The user picks via "this is a <type>" in Phase 2.
• File is a research paper, whitepaper, or article: this is NOT the right skill. Redirect to a doc-builder.
• File is a resume or portfolio: not the right skill. Redirect to the appropriate doc skill.
• File is a handbook, wiki export, or multi-page report: not a deck. Redirect to a doc-builder.

The classifier treats "is this a deck at all?" as a sanity check. If no type scores above the "low" confidence threshold AND the page count is outside every canonical band (e.g., 40+ pages with dense prose), surface that observation and ask the user whether they want to proceed anyway, re-route to a doc-builder, or cancel.

---

The conversion pipeline (6 phases)

| Phase | Owner | Gate | Output | |---|---|---|---| | 0. Extract | script (`extract_deck_pdf.py` o