From high-quality-slides
Use this skill when the user asks for a "high-quality" / "professional" / "Genspark-style" / "投资人级别" / "演示级" deck, or when they reference Genspark, Gamma, beautiful HTML slides, or pixel-perfect presentations. Trigger on requests like "做一份PPT", "生成幻灯片", "pitch deck", "做汇报", or when the user uploads research material (PDF/Excel/Word/notes/URL) and wants it turned into slides. Produces HTML decks (pixel-perfect, animation-capable, fully self-contained) and/or .pptx (editable). Do NOT trigger for plain Word docs or generic "summarize this" — only when a slide-shaped artifact is the deliverable.
How this skill is triggered — by the user, by Claude, or both
Slash command
/high-quality-slides:high-quality-slidesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> Goal: replicate Genspark AI Slides' "feels designed, not templated" quality bar inside Claude. Optimized for the **decisive content + curated visual** philosophy, not the "wall of bullet points on a stock theme" pattern.
Goal: replicate Genspark AI Slides' "feels designed, not templated" quality bar inside Claude. Optimized for the decisive content + curated visual philosophy, not the "wall of bullet points on a stock theme" pattern.
This skill is opinionated. Do not skip phases. Most low-quality AI decks fail at Phase 1–3 (no research, no narrative, no visual concept) and overinvest in Phase 4 (typography polish on garbage content). This skill inverts that.
A great deck = research × narrative × visual system × per-slide layout decisions. If any one factor is zero, the deck is zero. The model's job is to be a slide art director, not a content shoveler.
Three rules that override everything else:
Modeled on Genspark's Guide Mode. Each phase has a gate — do not advance until the gate passes.
Ask, or infer from context, then state back in one paragraph:
Gate: if audience or call-to-action is unknown, ask the user with AskUserQuestion. Do not proceed.
Collect the raw material before designing anything. Never invent statistics or quotes.
Sources, in order of priority:
Produce a research-notes.md scratchpad in the outputs folder with: claims, numbers, quotes, source URLs, image candidates (URLs or descriptions). This file is throwaway but you must produce it — it forces evidence discipline.
Gate: every assertion that will appear on a slide has a source in research-notes.md.
Choose a narrative arc that fits the goal. Default arcs:
| Arc | When to use | Slide skeleton |
|---|---|---|
| Problem → Solution → Proof → Ask | Pitch, sales, fundraising | Hook · Problem · Why now · Solution · How it works · Traction · Team · Ask |
| Situation → Complication → Resolution | Strategy memos, board updates | Where we are · What changed · What we propose · Plan · Risks |
| Finding → Evidence → Implication | Research, analytics reports | TL;DR · Method · Finding 1..N · So what · Next steps |
| Before → After → Bridge | Change management, launches | Today · The shift · What it enables · How we get there |
| Chronological | Quarterly review, retro | Timeline · Theme per period · Lessons · Forward look |
Output a numbered outline. For each slide, write three things only:
Gate: user reviews the outline. Do NOT design slides before the headline list is approved. Use AskUserQuestion to confirm or ask for edits.
Choose the visual system once, apply consistently. Do not "design each slide" — design the system, then instantiate slides from it.
Required design tokens (write to design-tokens.css as CSS custom properties):
:root {
/* Canvas */
--slide-w: 1920px;
--slide-h: 1080px;
--safe-pad: 96px; /* outer padding, ~5% of width */
/* Type scale — pick ONE display font + ONE text font */
--font-display: "Inter", system-ui, sans-serif;
--font-text: "Inter", system-ui, sans-serif;
--fs-hero: 120px; /* title slide */
--fs-h1: 72px; /* slide headline */
--fs-h2: 44px;
--fs-body: 28px;
--fs-caption: 20px;
--lh-tight: 1.1;
--lh-body: 1.4;
/* Color — pick ONE base + ONE accent. No more. */
--bg: #0B0B0C;
--fg: #F5F4F0;
--muted: #8C8A85;
--accent: #FF5A1F;
--surface: #17171A;
--line: rgba(255,255,255,.12);
/* Grid */
--col: 12;
--gutter: 32px;
}
Pick a style preset from layouts.md (see attached). Presets encode color + type + grid + motion, e.g. bold-signal, swiss-modern, editorial-serif, dark-botanical, neon-cyber, notebook-tabs. If the user can't articulate a preference, generate 3 preset previews (single hero slide for each) and let them pick — this is the "show, don't tell" trick that makes the user feel ownership of the design.
Density rules (override per-slide judgement only with reason):
Gate: preset chosen, tokens written, single sample slide approved before mass generation.
Generate slides as HTML, one <section class="slide"> per page, single self-contained file, inline CSS/JS, viewport-locked. Use the patterns in html-template.md.
For each slide in the outline:
layouts.md based on the intended visual: cover, headline-only, three-stat-strip, quote-hero, two-column-compare, timeline, process-flow, 2x2-matrix, chart-focus, image-with-caption, data-table-clean, kpi-grid, section-divider, closing-cta.Then run the self-check before delivery:
If a check fails, fix the slide, do not ship.
If the user needs an editable .pptx:
pptx skill, passing the outline + design tokens + per-slide layout choices as the construction plan. The HTML serves as the visual reference.Refuse these by default. If the user insists, comply but note the trade-off.
| File | When loaded | Purpose |
|---|---|---|
SKILL.md | Always | Workflow, gates, anti-patterns |
layouts.md | Phase 4–5 | 14 layout patterns + 12 style presets with code |
html-template.md | Phase 5 | Canvas HTML scaffold, navigation, print/export |
scripts/extract_uploads.py | Phase 2 | Pull text+images from pdf/docx/pptx uploads |
Load files on demand. Do not preload everything into context.
1. Parse the brief → identify audience, action, format, slide count, brand.
2. If anything in (1) is unknown → AskUserQuestion. Do not start.
3. Read all attached files + fetch URLs → write research-notes.md with sources.
4. Propose narrative arc + numbered outline (headline + fact + visual per slide).
→ AskUserQuestion to confirm outline. Iterate until approved.
5. Propose 2–3 style preset previews → user picks one.
6. Write design-tokens.css. Build sample slide. Confirm with user.
7. Generate full HTML deck, one layout-pattern per slide based on visual intent.
8. Run the self-check list. Fix anything that fails.
9. Save deck.html + research-notes.md + design-tokens.css to outputs folder.
10. (Optional) Export to .pptx via the pptx skill, using the HTML as the spec.
11. Hand back computer:// links. Offer one round of revisions.
Last note: the user does not care about your process. They care about getting a deck that looks like a designer made it. The phases exist to force that outcome — keep them, but communicate progress in plain language, not jargon.
Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.
npx claudepluginhub andyqiu847-ai/high-quality-slides --plugin high-quality-slides