Html Slide

HTML Slide Presentation Generator

Overview

Generate standalone HTML slide files (1280×720px) following an academic defense design system. Each slide is a self-contained .html file with embedded CSS. The design features a navy-blue/gold color scheme, deep-blue keynote-style covers, full-height header logos, large white content cards, and professional typography.

Mandatory Generation Workflow

Support two entry modes:

• No outline provided — first create a slide-level content plan, present the page-by-page outline to the user for confirmation, save the confirmed outline, then generate HTML, then validate the rendered page.
• Outline already provided — if the user already provides a page-by-page slide-outline, slides/大纲.md, or an equivalent slide plan, skip outline planning and confirmation, normalize the outline if needed, then generate HTML directly from that outline and validate the rendered page.

1. Content Planning Layer — convert Markdown into a slide-outline when the user has not already provided one.
2. User Confirmation Layer — present the outline slide by slide and get user confirmation or revision requests when the outline is newly created from source material.
3. Outline Persistence Layer — save the confirmed or user-provided outline to slides/大纲.md.
4. Deck Rhythm Layer — plan page-to-page pacing so the deck alternates visual structures and does not overuse one layout skeleton.
5. Layout Decision Layer — choose page types and visual structure using the confirmed or user-provided outline, with a visual-first bias.
6. Visual Generation Layer — apply the selected visual mode and component system, prioritizing diagrams over text-heavy cards.
7. Acceptance Layer — validate typography, density, visual richness, overload risk, and deck-level rhythm before delivery.

Output policy:

• Generate one HTML file per slide by default.
• Put all slide pages under a slides/ directory.
• Save the confirmed or user-provided page-by-page outline to slides/大纲.md before HTML generation.
• Copy deck assets into slides/assets/, especially the required logo file at slides/assets/logo.png.
• Do not put the whole deck into one giant HTML file unless the user explicitly requests a single-file deck.
• Treat HTML as the primary artifact. Treat PPTX as a derived export generated from the completed slides/ directory.
• Add keyboard-only page switching after slide generation. Do not add visible navigation buttons or navigation overlays.
• When the user already has a usable outline, do not force a second outline-planning round before slide generation.

1. Content Planning Layer

For Markdown-based decks, first produce a slide-outline and use it as the source of truth:

- title: "Page title"
  core_argument: "The main argument or message this slide should communicate"
  points:
    - "Support point or explanation"
    - "Support point or explanation"
  evidence:
    type: "timeline | metric | comparison | quote | case | checklist | table | diagram | mixed"
    note: "How the chart, visual, data, case, or argument supports the core argument"
  visual_type: "cover | agenda | section | single-insight | timeline | comparison | checklist | q-and-a | closing"
  split_if_needed: true

Rules:

• Most content slides must have a clear core argument or communication purpose.
• Cover, section, agenda, Q&A transition, closing, and thank-you slides do not need a formal core argument as long as the page purpose is clear.
• Pair the core argument with suitable evidence: chart, metric, timeline, case, comparison, quote, diagram, or structured reasoning.
• Prefer diagram-first expression: if the idea contains process, causality, sequence, or hierarchy, convert it into a visual structure before adding supporting text.
• Support points are flexible; use as many as the layout can carry clearly, but keep hierarchy obvious.
• Multiple evidence forms are allowed when they serve the same core argument and do not compete for visual focus.
• Do not mix timeline + KPI + table + checklist on the same slide unless their relationship is clear and one visual hierarchy dominates.
• If the source content contains narrative and analysis at the same time, split it into separate story and insight slides.
• Keep text concise. Most content slides should retain only title, takeaway, labels, and short annotations rather than paragraph-style explanation.

1.5 User Confirmation Layer

Before generating any HTML:

• If the outline is newly generated from source material, output it to the user page by page.
• Ask the user to confirm the generated outline or request changes.
• Revise the generated outline until the user is satisfied.
• Do not start HTML generation before the generated outline is confirmed, unless the user explicitly asks to skip confirmation.
• If the user already provides a page-by-page outline, treat it as confirmed input unless the user asks for optimization or restructuring.

Recommended outline display format:

# 幻灯片大纲

## 第1页
- 标题：
- 核心论点：
- 内容要点：
- 证据/图表：
- 版式建议：

## 第2页
- 标题：
- 核心论点：
- 内容要点：
- 证据/图表：
- 版式建议：

1.6 Outline Persistence Layer

After user confirmation:

• Create the slides/ directory if needed.
• Save the final confirmed outline or the normalized user-provided outline to slides/大纲.md.
• Treat slides/大纲.md as the deck blueprint.
• Generate all HTML slides from slides/大纲.md, not from the original long Markdown directly.

When the user already has an outline:

• Accept slides/大纲.md, pasted Markdown, YAML, or a page-by-page structured list as the source of truth.
• Normalize field names if needed, but keep the original page order and intent.
• Only ask for clarification if the outline lacks the minimum information required to distinguish slide boundaries or page purpose.

2. Split Rules

Split the source content into multiple slides when any of the following is true:

• Multiple core arguments compete with each other.
• Support points cannot be grouped into a clear hierarchy.
• Evidence forms compete for attention rather than supporting the same argument.
• A table has more than 4 rows or 4 columns.
• A timeline has more than 6 nodes.
• A checklist has more than 6 items.
• Main body text becomes dense enough that the slide would need small fonts or crowded spacing.
• The slide tries to both tell a personal story and make a structured comparison.

When splitting, optimize for single-slide clarity, not for fewer pages.

2.5 Visual-First Mapping Rules

When choosing how to express content, prefer the following mappings:

• Process / method / workflow / implementation sequence → process-flow
• Causal chain / mechanism / research framework / decision path → logic-map
• Stage evolution / milestones / chronological progression → timeline-sequence
• Architecture / system composition / hierarchy / layered modules → structure-diagram
• Before-after / alternatives / trade-offs / stage comparison → comparison-matrix
• One key chart and one takeaway → one-chart-one-message

Do not default to text cards when a diagram would communicate the structure more clearly.

3. Page Type Selection

Use page types deliberately:

| Page Type | Best For | Avoid | |-----------|----------|-------| | Cover | Opening, chapter title, major transition | Dense body text | | Agenda | 4–8 modules with short labels | 10+ detailed items | | Section | Chapter transition and mental reset | Tables or long lists | | Single Insight | One strong claim with 2–3 proofs | Multiple unrelated claims | | Timeline | Process, milestones, journey | More than 6 nodes | | Comparison | Before/after, stages, alternatives | Long paragraph cells | | Checklist | Action items, pitfalls, review criteria | More than 6 items | | Q&A | Defense preparation and likely questions | Long answer paragraphs | | Closing | Summary, final call-to-action | New arguments |

Preferred advanced page types for stronger expression:

| Page Type | Best For | Key Principle | |-----------|----------|---------------| | Process Flow | Workflow, method, implementation path | Arrows and sequence dominate; text becomes labels | | Logic Map | Mechanism, causal chain, analytical framework | Nodes + relationships dominate; keep prose minimal | | Timeline Sequence | Stage evolution, milestones, roadmap | Time order is primary; 3–6 nodes preferred | | Structure Diagram | Architecture, layered system, module hierarchy | Show containment and levels before explanation | | Comparison Matrix | Scheme trade-offs, stage contrast, before/after | Use a matrix, not repeated paragraph cards | | One Chart One Message | One key figure plus one takeaway | Let the visual own most of the slide |

3.5 Deck Rhythm Rules

• Do not let 3 consecutive slides share the same main skeleton.
• Adjacent slides should differ in at least one of: dominant visual form, information structure, or evidence type.
• Diagram-centric pages should appear regularly across the deck, not just once or twice.
• Avoid using hero + banner + two-column cards as the default for most content slides.
• Treat deck-level rhythm as part of quality, not a cosmetic extra.

Recommended V2 Templates

Use these templates first for new academic-defense or professional-sharing decks. They are more spacious and formal than the legacy component library.

| Template | Use | File | |----------|-----|------| | V2 Grand Cover | Opening slide / section title with strong visual presence | templates/v2-cover-grand.html | | V2 Grand Content | Main content slide with full-height top-right logo, hero summary, main card, side panel, and bottom metrics | templates/v2-content-grand.html |

V2 Design Principles

• One visual center per slide — use a strong cover title, hero insight, or main argument as the dominant focus.
• Deep blue + restrained gold — keep gold for title highlights, key numbers, dividers, and status accents only.
• Fewer borders, stronger layering — prefer soft shadows, glass panels, and large white cards over many thin bordered boxes.
• Larger hierarchy gaps — use 27–56px display titles, 18–21px lead text, and 14–15px body text.
• Full-height logo header — on V2 content slides, the top-right logo block must be the same height as the header and aligned to the top-right corner.

Visual Modes

Academic Defense Mode

Use this mode for thesis defense, research reporting, and formal academic presentations. Keep the design calm, precise, and institutionally credible.

Tech Share Mode

Use tech-share for experience-sharing decks, AI workflow talks, product thinking, engineering practice, or any presentation where the user asks for a more technological / futuristic look.

Style direction:

• Use deep navy, cyan-blue, and restrained purple gradients.
• Add glassmorphism panels, subtle glow, fine grid or HUD-style decorative lines.
• Use metric strips, status chips, data badges, and illuminated timeline nodes.
• Prefer layered backgrounds: background layer + content layer + decorative technology layer.
• Avoid exaggerated cyberpunk neon; keep it as academic technology premium, not game UI.

Every tech-share slide should include:

• One clear core argument or communication purpose.
• A dominant visual module.
• Supporting evidence or argumentation that reinforces the core argument.
• One visual enhancement layer, such as glow grid, data chips, gradient rings, or HUD dividers.

Avoid plain white-card-only pages in tech-share mode.

V2 Header Logo Rule

.topbar { height:86px; padding:0 0 0 58px; position:relative; }
.chapter { padding-right:300px; }
.topbar-logo {
  position:absolute; top:0; right:0;
  width:268px; height:86px;
  background:rgba(255,255,255,.96);
  display:flex; align-items:center; justify-content:center;
}
.topbar-logo img {
  width:100%; height:100%;
  object-fit:contain; object-position:center;
  padding:0 14px; border-radius:0;
}

Design System

Theme & Color Palette

:root {
  /* Primary */
  --navy:    #003366;    /* Header, headings, dark backgrounds */
  --blue:    #004488;    /* Secondary blue */
  --accent:  #3498db;    /* Links, highlights, borders */
  /* Semantic */
  --teal:    #0abde3;    /* Category C / formulas */
  --gold:    #7fb3d5;    /* Decorative highlight, soft blue accent */
  --red:     #c0392b;    /* Alerts, negative values */
  --orange:  #e67e22;    /* Warnings, secondary emphasis */
  --purple:  #6c5ce7;    /* Category B / SGI */
  --green:   #27ae60;    /* Positive values */
  /* Neutral */
  --text:    #1f2937;    /* Primary text */
  --sub:     #5b6472;    /* Secondary text */
  --muted:   #8a94a6;    /* Labels, captions */
  --border:  #d8e2ee;    /* Card borders */
  --soft:    #f4f6f9;    /* Light backgrounds */
}

Slide Shell

.slide {
  width: 1280px; height: 720px;
  background: #ffffff;
  background-image: radial-gradient(#e0e0e0 1px, transparent 1px);
  background-size: 20px 20px;            /* Dot pattern */
  display: flex; flex-direction: column;
  overflow: hidden;
  box-shadow: 0 10px 30px rgba(0,0,0,.15);
}

The outermost .slide container should not use rounded corners. Keep the slide edge rectangular; rounded corners are allowed only for internal cards, chips, and panels.

Page Structure

.slide  1280×720px
├── .slide-header   72px  (left: navy gradient + title / right: 268px logo area)
├── .slide-body     flex:1, padding 12px 28px, gap 9px
└── .slide-footer   34px  (left: paper title / right: defense occasion)

Logo

Logo file inside the generated deck: slides/assets/logo.png (230×65px, object-fit: cover)

The logo is mandatory on every content slide. Place it in the header-right area:

> Deck asset rule: when outputting a slide deck, always copy the bundled logo into slides/assets/logo.png, then reference it from every slide with src="assets/logo.png". Do not rely on assets outside the slides/ directory.

HTML Template (Full Boilerplate)

Slide Title

:root {
  --navy:#003366; --blue:#004488; --accent:#3498db;
  --teal:#0abde3; --gold:#7fb3d5; --red:#c0392b;
  --orange:#e67e22; --purple:#6c5ce7; --green:#27ae60;
  --text:#1f2937; --sub:#5b6472; --muted:#8a94a6;
  --border:#d8e2ee; --soft:#f4f6f9;
}
* { margin:0; padding:0; box-sizing:border-box; }
body {
  font-family: 'PingFang SC','Microsoft YaHei',sans-serif;
  background: #dcdcdc;
  display: flex; flex-direction: column; align-items: center;
  gap: 48px; padding: 48px 0;
}

/* ── Slide Shell ── */
.slide { width:1280px; height:720px; background:#fff;
  background-image:radial-gradient(#e0e0e0 1px,transparent 1px);
  background-size:20px 20px; display:flex; flex-direction:column;
  overflow:hidden; box-shadow:0 10px 30px rgba(0,0,0,.15);
  flex-shrink:0; }

/* ── Header ── */
.slide-header { height:72px; display:flex; align-items:stretch; flex-shrink:0; overflow:hidden; }
.slide-header .header-left {
  flex:1; background:linear-gradient(90deg,var(--navy) 0%,var(--blue) 100%);
  color:#fff; padding:0 32px 0 38px; display:flex; align-items:center;
  position:relative; overflow:hidden;
}
.slide-header .header-left::after {
  content:''; position:absolute; bottom:0; left:0; right:0; height:3px;
  background:linear-gradient(90deg,var(--accent) 0%,rgba(52,152,219,.2) 72%,transparent 100%);
}
.slide-header .deco-ring {
  position:absolute; right:40px; top:-28px; width:110px; height:110px;
  border-radius:50%; border:18px solid rgba(255,255,255,.05); pointer-events:none;
}
.slide-header h1 { font-size:22px; font-weight:700; letter-spacing:.6px; }
.slide-header .header-right {
  width:268px; flex-shrink:0; background:#fff;
  border-left:1px solid var(--border); display:flex; align-items:center;
  justify-content:center; padding:0 16px;
}
.slide-header .logo { width:230px; height:65px; object-fit:contain; }

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [WEN-JY](https://github.com/WEN-JY)
- **Source:** [WEN-JY/academic-research-skills](https://github.com/WEN-JY/academic-research-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.