Consulting Deck
Create decision-ready presentations, not decorative summaries. Build a clear
argument, trace every material claim, select layouts by communication job, and
deliver a native .pptx whose text, charts, tables, and simple diagrams remain
editable.
Treat this as an independent presentation system created by Peng · 智珠在睿. Do not imply affiliation with McKinsey, BCG, Bain, or another consultancy. Do not copy their logos, proprietary templates, or protected brand assets unless the user provides licensed assets and explicitly asks to use them.
Load the right guidance
Load guidance progressively:
- Start every Create or Revise route with
references/harness-system.md,references/workflow.md, andreferences/presentation-modes.md. - Read
references/problem-solving-system.mdfor a topic, open business question, strategy choice, or research-from-scratch request. Do not force a hypothesis tree onto a faithful source-summary request. - Read
references/storyline-system.mdwhen building the governing thought and slide sequence. - Read
references/chart-system.mdandreferences/charts-and-data.mdonly when quantitative evidence or material exhibits are present. - Read
references/visual-system.mdandreferences/layout-library.mdwhen planning the method sample and full slide system. - Read
references/quality-gates.mdbefore validation and delivery. - Read
references/brand-system.mdonly when a brand, logo, font, or PPTX template is used. - Read
references/runtime-adapters.mdbefore selecting the PPTX production route. - Read
references/workspace-schema.mdwhen creating, resuming, or revising a saved deck project.
Route the request
Choose exactly one primary route:
- Create — turn source material or a topic into a new editable deck.
- Revise — modify an existing saved deck project and regenerate affected slides.
- Template — apply a user-supplied brand or native PowerPoint template.
- Audit — inspect an existing deck without changing it unless the user asks.
Do not silently combine routes. A template request can refine Create or Revise, but the underlying saved project remains the source of truth.
Establish the production contract
Before authoring:
- Identify the audience, decision, presentation context, language, page count, presentation mode, density mode, analysis route, and source boundary.
- Use the host's current native PowerPoint capability when it can create editable objects and render every slide for inspection.
- Use PptxGenJS only as a fallback when it is already available or the user approves installation. Never replace the requested PPTX with HTML.
- Preserve an editable project workspace. Do not make the final
.pptxthe only source of truth. - Keep the default output brand-neutral. Apply
assets/brands/peng.jsononly when the user explicitly selects the Peng preset. - Use the staged harness in
references/harness-system.md. Do not jump from a source file directly to slide-rendering code. - Treat machine-readable gate files as the source of truth. Never claim a gate
passed unless the corresponding JSON exists and contains
"passed": true.
Apply the consulting standard
Require all of the following:
- Lead with a governing thought and answer-first slide titles.
- For a problem-solving route, define the problem boundary, build an issue tree, and maintain falsifiable hypotheses before broad research.
- Give each slide one communication job and one main takeaway.
- Make horizontal logic coherent across slides and vertical logic sufficient within each slide.
- Distinguish facts, calculations, source interpretations, and hypotheses.
- Cite external claims and assets in visible footnotes or speaker notes.
- Treat charts as the primary analytical language, not a secondary decoration layer.
- Write a declarative
charts.jsonrecord before rendering every material exhibit. - Use the question-based chart families, annotation system, and rendering hierarchy in
references/chart-system.md. - Use native charts for data that users may need to inspect or edit. Use Vizro's visual vocabulary and optional prototype route for selection and validation, not as permission to flatten the final PowerPoint.
- In Research Analytical mode, rebuild the source's material exhibits before creating
conceptual summaries. Meet the evidence-led and native-chart thresholds in
references/presentation-modes.md. - Use a semantic layout from
references/layout-library.md; do not invent a layout merely to fill space. - Use the title-as-structure visual device only on covers, section dividers, and a small number of decisive insight slides.
- Render and inspect every slide at full size before delivery.
- Keep machine checks and expert review separate. Geometry scripts cannot prove evidence quality, chart truthfulness, or executive clarity.
- Record true cross-slide prerequisites in
slides.json. Generate in dependency-safe order, then assemble in audience-facing display order.
Use two density modes
- Speaker-led — fewer words, larger type, more pages, stronger pacing.
- Reading-first — more self-contained evidence, annotations, and footnotes.
Choose one mode from the presentation context. Do not create a vague middle mode. When content does not fit, split the slide or sharpen the argument before reducing font size.
Density mode is not presentation mode. A reading-first Executive Story and a reading-first Research Analytical deck can have similar text density but different shares of exhibits, footnotes, and conceptual pages.
Preview visual direction
When the user has not supplied a locked template or explicit visual reference:
- Create three compact visual directions from
references/visual-system.md. - Show a real cover, an analytical/data slide, and a framework/action slide for each direction.
- Keep preview content authentic to the user's material; never show internal labels such as “Option A” inside the slide itself.
- Ask the user to choose once, then apply the selected system consistently.
Skip this gate only when the user explicitly asks to proceed directly or provides a clear visual reference. Record the chosen direction in the project workspace.
Preserve editability
- Keep text as text.
- Keep tables as tables.
- Keep charts as native charts whenever practical.
- Keep chart data and chart intent separate from slide layout code.
- Keep simple matrices, timelines, processes, and issue trees as native shapes.
- Use images for photographs, textured artwork, or illustrations—not for entire text-heavy slides.
- Never deliver a deck whose pages are flattened screenshots.
Iterate from the saved project
For requests such as “change slide 3's title,” edit the project source and regenerate the affected output. Preserve source material, evidence IDs, chart data, slide IDs, and speaker notes. Re-run all affected quality checks and the final deck-level check.
Learn without mutating the installed Skill
Classify every material correction as either one-off or repeatable. Record repeatable
lessons in the deck workspace at qa/experience-log.md; do not silently edit the
installed Skill during ordinary deck production. Promote a repeated lesson into this
Skill only through a reviewed, versioned Skill update.
Deliver
Deliver the final .pptx plus a concise summary. Keep intermediate plans, previews,
and QA files inside the project workspace unless the user requests them. State any
unverified claims, font substitutions, compatibility limitations, or remaining
warnings explicitly.