business-html-ppt

Business HTML PPT

Overview

Turn scattered workplace materials into an HTML presentation that can be used directly for reporting. The final output should be a complete, standalone .html file that can be opened in a browser, projected in meetings, forwarded as a file, or screenshotted for colleagues to preview.

The default effect should be close to a professional consulting report, an education/career planning report, or an internal company strategy report: deep navy business style, light gray page background, white information cards, conclusion first, clear hierarchy, and practical hidden speaker notes.

Workflow

1. When information is missing, first fill in the reporting context:
   • Reporting topic and business scenario
   • Who the audience is, and who the key decision-makers are
   • Target page count or reporting duration
   • Existing materials, key data, risk points, and the desired outcome

1. Restructure the materials first, then write the pages:

   • Distill the core business question this report needs to answer.
   • Write a one-sentence core conclusion.
   • Consolidate the supporting materials into 3-5 sections.
   • Remove duplicate, low-value, or overly detailed process information.
   • Prefer "conclusion -> evidence -> impact -> action"; do not mechanically unfold it as a chronological running account.

2. Generate the following pages by default:

   • Cover page
   • Table of contents page
   • Core conclusion or executive summary page
   • Add section divider pages when necessary
   • 5-12 content pages by default
   • Risks, decision items, and next steps page
   • Closing page
   • Hidden speaker notes on each page

3. Output a complete single-file HTML:

   • All CSS and JavaScript are inline.
   • Use a fixed 16:9 canvas, centered display, and hide non-current pages.
   • Use a fixed presentation shell:deck-shell, a 3px progress bar fixed at the top, a table of contents button in the upper left, a left-side table of contents drawer, circular previous/next page buttons on the left and right, a keyboard hint in the lower left, and a page number in the lower right.
   • Support keyboard, left/right buttons, mouse click, and mouse wheel page navigation; the left/right keys/buttons turn pages directly and show the full-page card, while the up/down keys/space reveal cards one by one.
   • Show only one slide at a time.
   • Multi-card pages reveal one by one by default; the table of contents page displays all by default.
   • Do not rely on external resources, build tools, or the network.

Default structure

Use this structure unless the user's scenario is clearly unsuitable:

1. Cover: title, subtitle, presenter, date
2. Table of contents: 4-6 sections, with corresponding page numbers marked
3. Executive summary: one-sentence conclusion + 3 key supporting points
4. Current status: background, facts, baseline data
5. Key progress or key insights: what changed, and why it matters
6. Evidence pages: metrics, comparisons, trends, user/customer feedback, or case details
7. Problems and risks: priorities, impact, owners, mitigation actions
8. Recommended solutions: options, benefits, costs, risks, and recommended path
9. Action plan: timeline, owners, milestones
10. Decisions needed: items you want the audience to approve, decide, or align on
11. Closing page: use "Conclusion" as the title, give a one-sentence conclusion and the next checkpoint

If it is a weekly or monthly report, reduce solution justification pages and strengthen progress, blockers, next-stage plans, and support needed.

If it is a project retrospective, strengthen goals, results, root causes, lessons learned, and mechanism improvements.

If it is a performance review or promotion defense, strengthen scope of responsibility, business impact, evidence, leadership performance, and next-stage planning.

Business expression rules

• Page titles should state conclusions, not just empty titles like "Background," "Analysis," or "Problem."
• Write for busy managers: short sentences, quantified impact, clear asks.
• Distinguish facts from judgments; do not present subjective speculation as fact.
• Use MECE grouping as much as possible.
• When information suits structured presentation, change long bullet paragraphs into tables, timelines, metric cards, or decision matrices.
• Chinese input defaults to Chinese business expression; English input defaults to English.
• Avoid slogans, exaggerated expressions, jokes, emoji, and vague platitudes.

HTML design rules

When generating HTML, follow references/html-deck-spec.md the page contract and visual specifications in

Core constraints:

• 16:9 slides, each logical page corresponds to one section.slide, and is wrapped in a fixed deck-shell structure.
• There must be a table of contents page, and ensure the table of contents chapters match the left-side table of contents drawer; the footer only contains the page number and does not show chapter names.
• The top progress bar is fixed at the very top of the viewport, 3px high, using a dark navy gradient; do not add another progress bar at the bottom.
• There must be a table of contents button in the upper left corner; clicking it opens a full-height left-side outline that supports page jumps.
• There must be circular page-turn buttons on the left and right sides; keep a faded keyboard hint in the lower left corner; display in the lower right corner current / total。
• The visual style uses a dark navy business style: light gray background #f5f6fa, primary color #2d3a6e, dark graphite body text, white cards, restrained shadows, 12px card corner radius.
• The information density should be suitable for screen presentation; do not make full-screen long text.
• Detailed explanatory text must be suitable for screen reading; body explanatory text should be no smaller than 18px by default.
• Do not set the main page title too narrow max-width; do not wrap early when there is still space on the right.
• Reuse CSS classes to express cards, grids, KPIs, timelines, charts, tags, callout blocks, and tables.
• Keep animations restrained; use progressive reveal for cards, and have lightweight animations for page transitions and card appearances.
• A screenshot of a single page should also make it clear what the page is about.

Output format

When the user needs the final deliverable, prioritize:

• Write the complete HTML file in the current workspace and return the file path.
• Only when the user explicitly asks "just give me the code" should you output a fenced html code block in chat.

Suggested local file name:

html-ppt/<topic-slug>/index.html

Quality Check

Pre-finish check:

• Whether the HTML includes a cover, table of contents, core conclusions, actions/next steps, and a closing page.
• Whether each page has a clear title and a single main message.
• Whether there is no visible text on the page such as "how to use this deck" or explanations of the design.
• Whether the page navigation does not depend on external resources.
• If conditions allow, open a browser or render screenshots to check the layout, overflow, and readability.