| name | design-consulting-slides |
| description | Design, build, revise, or review professional consulting slide decks in fixed-canvas HTML, PDF, or native PowerPoint. Use after the central answer and storyline are approved, or for a bounded visual edit with approved content. Select the visual system from a supplied PPTX/template first, then authorized brand or explicit direction, otherwise the bundled Default Executive Consulting System; derive tone, density, page archetypes, proof objects, and assets from the content and audience. Produce the requested artifact and verify rendered comprehension, not merely a page map or clean text blocks. |
Design Consulting Slides
Turn an approved storyline into a visual argument and finished artifact. Own visual reasoning, composition, production, and rendered QA; do not adjudicate hypotheses or silently change the answer.
Confirm the handoff and format
Require approved answer/title spine; Audience/Onboarding Contract locator; presented or read_ahead; canonical page job | message/title | proof | source locator briefs; delivery mode; template/brand/permission/source constraints; and resolved or explicitly narrowed decision-material hypotheses. Return a defective title, proof, source, claim state, or reader assumption upstream instead of decorating it.
Choose:
html_preview for a fast fixed-canvas proof;
html_final for a final standalone browser deck;
pptx_native for editable PowerPoint, template control, or requested PPTX; or
dual when both are required or materially useful.
For PDF delivery without native-editability or template-control requirements, build the approved page in fixed-canvas HTML first and treat that HTML as the visual production master. Export PDF only as a uniformly scaled frozen render of the same 1600×900 composition; never maintain or repair a separate PDF layout.
Never substitute HTML/PDF for requested PPTX. Follow pptx-production-handoff.md and presentations:Presentations for native work; follow html-and-dual-render-production.md for HTML/dual.
Keep one visual owner and a lightweight page map
Assign one deck owner and one owner per page. Contributors return content, evidence, corrections, or defects—not competing layouts. Never create per-page design subagents.
Add only:
page owner | expression/layout | QA note
Use one conditional exhibit_spec when the page depends on comparison, flow, hierarchy, causality, thresholds, trade-offs, or another material relationship. A simple fact, definition, divider, reference, or direct edit may declare exhibit_spec: simple with a reason.
Select the visual system
Use this precedence: user PPTX/template → authorized brand or explicit direction → bundled Default Executive Consulting System. Derive tone, palette, typography, density, media, silhouette, and variation from the reader, delivery context, communication job, evidence type, subject, and authorized cues. Avoid generic card grids. Consulting icons default to transparent, single-color, line-only SVG; keep containers as separate slide objects.
On the bundled-default HTML route, load the generated assets/default-executive-consulting/deck-default.css and declare each page's role and one allowed silhouette. On native PPTX, map the same tokens and composition family into editable objects. Treat the 16 archetypes as cognitive jobs, not fixed shells.
When no visual source controls a consequential new deck and two systems would materially change credibility or positioning, render exactly two directions using the same approved, evidence-bearing key page. Otherwise choose directly. Reject cover-only choices, three-option galleries, and mandatory approval gates.
Make the proof object govern the page
Give every page one cognitive job and one governing content/proof object populated with an exact fact, number, example, mechanism, bounded comparison, or explicit gap.
data/content → message → exhibit spec when applicable → governing exhibit → display form → craft → reconcile
Use charts/tables for quantitative proof, diagrams only for material relationships, authentic assets for concrete context, and restrained text/list/definition layouts when they are clearer. Analytical exhibits normally occupy most of the usable body; attach scope, annotation, interpretation, caveat, and source to the exhibit. Reject title-plus-boxes, miniature proof beside prose, decorative relationships, unsupported status/causal cues, and objects that remain generic after swapping the case nouns.
Build a clear claim → proof → support hierarchy. Use page-role scale rather than one title size everywhere; reserve hero scale for one supported decisive figure or short verdict. Create intentional whitespace around the proof, not equal padding around many boxes. A right rail must earn its space with a structured second object.
Set presented or read_ahead as an executable reading mode before composition. Keep substantive body in its reading tier; labels, captions, metadata, and sources may be smaller but may not carry the argument. Use a consistent spacing rhythm so related items sit closer than separate groups. Every filled or bordered field must earn its existence through grouping, status, comparison, emphasis, or operating containment; reject a small top-aligned payload floating in a large background field.
Lock the entry path before styling: first read → governing proof → attached implication. Put the page's takeaway, evaluative lesson, or decision in the action title or another high-positioned message—not only in takeaway/source furniture. On before/after or explanatory comparison pages, state why the comparison matters before the alternatives. On process, roadmap, and decision pages, bind an explanation to the exact stage, gate, threshold, or outcome it explains; detached prose and unexplained lower whitespace are defects.
Prove only representative summary, hardest-evidence/analysis, pivotal transition, or decision pages where composition can change comprehension. Render real production proofs before scaling. If no supported composition makes the message understandable, loop upstream.
Review actual renders
For Standard work: inspect key pages full size; render the complete artifact; inspect every page; read the title stack/montage; cold-read with the received reader profile; apply 5–10 second, title-hidden, entry-path, or bullet-replacement tests only where meaningful; repair and rerender. Treat awkward or apparently incomplete title wrapping, a key lesson hidden below the main content, and explanatory copy whose governed object is unclear as comprehension defects even when nothing is clipped.
For html_final/dual, run scripts/render_html_deck.mjs on the locked 1600×900 canvas. Resolve structured defects[] for furniture entry, text/object collisions, font floors, small-text burden, widow/fill, container-content detachment, vertical balance, default-token conformance, and missing executable-system inputs. When PDF is requested, require the renderer's screen/print layout-parity gate to pass; title wrapping, governing-object geometry, reading order, or furniture position may not change. Treat automatic container-fit, proof dominance, type-scale range, and repeated silhouette as page-role-aware diagnostics; judge whether the dominant object is the decisive proof. Use reason-bearing data-qa-allow-* attributes narrowly; repair the page, then recheck the full artifact.
For pptx_native/native dual, run scripts/inspect_native_pptx_geometry.py as an advisory preflight for explicit-geometry coverage, off-canvas, title/body, furniture-band, and vertical-balance risks. Use strict mode only deliberately. OOXML cannot prove z-order, fonts, contrast, editability, or comprehension; presentations:Presentations still renders and checks every page.
Fail release when the body does not support/qualify the title; proof exceeds its evidence entitlement; a material relationship becomes bullet-equivalent boxes; facts/numbers/sources do not reconcile; first-use concepts are undecodable; a visual implies unsupported meaning; hierarchy, contrast, type, crop, alignment, reading order, or whitespace fails; required content is clipped/hidden; a cold reader cannot recover one case-specific learning per material section; or native editability/template fidelity is lost. Object-tree, OOXML, DOM, or PDF text existence is not rendered evidence.
Finish the requested artifact
Do not stop at direction, storyboard, page map, or proof page. Completion requires the requested HTML/PDF/PPTX; approved title spine/order; reconciled proof and sources; applicable format QA; complete rendered review for the reader; and no decision-changing or P0/P1 defect.
Load detail only when needed
Before the first composition, load only the reference that controls the unresolved choice:
Reusable icon-family maintenance, formal dual governance, and authorized local method distillation require separate permission-cleared resources; they are not bundled public defaults.