| name | deep-ppt |
| description | Use when creating research-style PowerPoint decks for lab meetings, journal clubs, defenses, weekly reports, or conferences, especially Chinese or English academic slides that need the deepPPT blue title system, evidence-led layouts, selective red key findings, package checks, and rendered visual review. |
| license | MIT |
| metadata | {"version":"0.1.3"} |
deepPPT
Produce a new .pptx in the deepPPT visual system and prove that the delivered
file survives both deterministic checks and a rendered review.
Start from the source material
Collect the topic, audience, language, target slide count, and any required
figures or citations. Derive an argument before arranging slides: each
substantive page should make one claim and show the evidence that supports it.
If the input is an existing PPTX, treat it as a content source rather than an
editable template. Extract its text first:
.venv/bin/python scripts/extract_pptx_text.py source.pptx
Then rebuild a separate deck. Do not alter the supplied package in place.
Apply the deepPPT system
Read style_guide.md for the locked palette, type scale, grid,
and signature elements. Choose page compositions from
slide_patterns.md. Use
references/example_pptx/build_deepppt_examples.js
as the maintained implementation example.
The non-negotiable visual rules are:
- 16:9
LAYOUT_WIDE pages with one font family per deck;
- the two-block title marker and 60-piece segmented rule on content slides;
- navy chevron labels for sections inside a slide;
- a red key-finding statement only when the slide earns extra emphasis; it is
optional rather than a default content-slide footer;
- evidence figures placed on white without decorative outer frames;
- no model names, build traces, local paths, or internal provenance labels in
visible slide content.
Decide on the red key-finding box while planning the outline. Default to no
box. Add one only when the slide contains a decision-worthy result, section
synthesis, recommendation, or final take-home; the sentence adds interpretation
that is not already stated by the action title or chevron; and it fits on one
line without aggressive shrinking. Omit it on cover, outline, routine
background, definitions, methods, workflows, architecture, references, and
thank-you pages. Avoid consecutive uses; qa_layout.py rejects runs of three
or more bottom key-finding boxes.
Use PptxGenJS 4.0.1 and follow pptxgenjs.md for the small set of
project-specific generation conventions. Optional generated imagery is only
appropriate when the active runtime provides an image tool and the visual adds
meaning; otherwise use native shapes, charts, and supplied figures.
Run the delivery gate
Confirm the toolchain before building:
.venv/bin/python scripts/check_env.py
After generation, run every check below. normalize_pptx.py corrects a known
PptxGenJS package-order issue; check_pptx.py is a focused structural checker,
not a full OOXML schema validator.
.venv/bin/python scripts/normalize_pptx.py output.pptx
.venv/bin/python scripts/check_pptx.py output.pptx
.venv/bin/python scripts/extract_pptx_text.py output.pptx
.venv/bin/python scripts/qa_layout.py output.pptx
.venv/bin/python scripts/render_preview.py output.pptx --out preview
Read the extracted text in slide order. Inspect every rendered page for
overlap, clipping, weak contrast, unreadable labels, inconsistent spacing, and
figure distortion. Fix the builder and regenerate instead of patching the
PPTX package manually.
Hand off
Deliver the rebuilt PPTX and state which renderer was used for review. If a
native PowerPoint render was unavailable, say that the visual check used the
LibreOffice fallback. Do not claim a completed visual QA pass when no rendered
pages were actually inspected.
