Consulting Deck

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:

1. Start every Create or Revise route with references/harness-system.md, references/workflow.md, and references/presentation-modes.md.
2. Read references/problem-solving-system.md for a topic, open business question, strategy choice, or research-from-scratch request. Do not force a hypothesis tree onto a faithful source-summary request.
3. Read references/storyline-system.md when building the governing thought and slide sequence.
4. Read references/chart-system.md and references/charts-and-data.md only when quantitative evidence or material exhibits are present.
5. Read references/visual-system.md and references/layout-library.md when planning the method sample and full slide system.
6. Read references/quality-gates.md before validation and delivery.
7. Read references/brand-system.md only when a brand, logo, font, or PPTX template is used.
8. Read references/runtime-adapters.md before selecting the PPTX production route. When production_runtime resolves to ppt-master-adapter, also read references/ppt-master-adapter.md and enforce its security, handoff, and content-lock boundaries.
9. Read references/workspace-schema.md when creating, resuming, or revising a saved deck project.
10. Read references/native-exhibits.md when using executable native exhibit components, bound content, capacity-compatible candidates, or actual chart data reconciliation. Do not force other layouts into the component subset.

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:

1. Identify the audience, decision, presentation context, language, page count, presentation mode, density mode, analysis route, and source boundary.
2. Use the host's current native PowerPoint capability when it can create editable objects and render every slide for inspection.
3. Use an independently installed PPT Master adapter only when deeper native PowerPoint behavior is required, the exact version has an approved security record, and the user has selected or approved that runtime. Never install it automatically or allow it to replace the approved evidence and storyline.
4. Use PptxGenJS only as a fallback when it is already available or the user approves installation. Never replace the requested PPTX with HTML.
5. Preserve an editable project workspace. Do not make the final .pptx the only source of truth.
6. Keep the default output brand-neutral. Apply assets/brands/peng.json only when the user explicitly selects the Peng preset.
7. Use the staged harness in references/harness-system.md. Do not jump from a source file directly to slide-rendering code.
8. 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.json record before rendering every material exhibit.
• Use the executable exhibit subset where it fits the analytical task. Keep copy bindings and numeric data canonical, render difficult-page candidates from the same content, and verify exported chart caches and embedded workbook values. A self-declared reconciliation status is not actual data verification.
• 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:

1. Create three compact visual directions from references/visual-system.md.
2. Show a real cover, an analytical/data slide, and a framework/action slide for each direction.
3. Keep preview content authentic to the user's material; never show internal labels such as “Option A” inside the slide itself.
4. 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.