Presentations

Presentations

Presentations is for serious, high-polish presentation work where "clean" is not enough. The target is an editable PowerPoint deck that feels like a strong editor, a strong analyst, and a strong designer built it together.

Use this skill for analytics narratives, investor/operating reviews, strategy stories, product/business performance decks, and any PPTX task where the user asks to beat a reference deck.

Operating Contract

Use artifact-tool presentation JSX only. The bundled Codex runtime provides @oai/artifact-tool version 2.7.3 or newer and exposes @oai/artifact-tool/presentation-jsx.

Do not require or import a separate presentation runtime package. PPTX export/render behavior must be accessed through artifact-tool.

For generated raster images or reference comps, use the Codex imagegen tool. Bundled scripts may write imagegen prompt files, but must not call external image APIs or read API keys.

Thread-scoped paths:

• SKILL_DIR=<absolute path to the installed Presentations skill>
• THREAD_ID=${CODEX_THREAD_ID:-manual-<timestamp-or-short-random-suffix>}
• WORKSPACE=${TMPDIR:-/tmp}/codex-presentations/$THREAD_ID/<task-slug>
• SLIDES_DIR=$WORKSPACE/slides
• PREVIEW_DIR=$WORKSPACE/preview
• LAYOUT_DIR=$WORKSPACE/layout
• ASSET_DIR=$WORKSPACE/assets
• QA_DIR=$WORKSPACE/qa
• OUTPUT_DIR=<user-provided output dir if any, otherwise $WORKSPACE/output>
• FINAL_PPTX=$OUTPUT_DIR/<relevant-deck-title-slug>.pptx

Use absolute paths in commands and handoffs. Keep all generated planning text notes, preview PNGs, contact sheets, layout JSON, imagegen prompt files, temporary reference images, and other scratch files inside this thread-scoped $WORKSPACE. Keep only final deliverables in $OUTPUT_DIR. If the user provides an external output directory, write or copy only final deliverables there; generated .txt plans, contact sheets, previews, layout files, prompt files, and generated scripts must still stay under $WORKSPACE. Name the final PPTX with a short, relevant title derived from the deck topic or requested deliverable. Do not use generic filenames such as output.pptx, deck.pptx, or deck.final.pptx.

Never use a shared scratch folder such as .presentation_workspaces, presentation-workspaces, presentation_workspaces, out, or a bare repo-local deck slug unless the path includes $THREAD_ID. If CODEX_THREAD_ID is unavailable, generate a manual id with timestamp plus a short random suffix.

North Star

The deck must win the contact-sheet test. At thumbnail size, it should show a coherent visual system, distinct slide rhythms, and evidence-led storytelling. At readable size, every slide should have a claim, a proof object, and no filler.

This skill rejects "serviceable" output. A deck can pass layout checks and still fail. If it looks like a generic SaaS dashboard, consulting card grid, or autogenerated template after replacing the company name, keep iterating.

Mandatory Workflow

1. Confirm the task mode.
2. Extract the source story.
3. Write the claim spine.
4. Lock the design system.
5. Plan the contact sheet.
6. Build editable artifact-tool presentation JSX slides.
7. Render previews and layout JSON.
8. Score against the comeback rubric.
9. Iterate the weakest slides.
10. Export the final PPTX only after the rendered deck beats the target or the remaining gap is explicitly documented.
11. Clean up generated planning text notes, QA scratch files, contact sheets, preview images, generated slide modules/scripts, layout JSON, manifests, prompt text files, and other temporary images before the final response.

Task Modes

• reference-beating: user supplied or named a deck to beat. This is the default when a reference PPTX is present.
• template-following: user supplied a source/template deck whose visual system must be inherited.
• create: no deck/template is supplied; build from prompt and sources.
• targeted-edit: small changes to an existing deck.

When both a source deck and a better reference deck exist, separate them:

• source deck: content, required sections, facts, existing material.
• reference deck: quality bar, rhythm, taste, and proof that a stronger output is possible.

Do not blindly clone the reference. Beat it by improving story precision, composition variety, chart clarity, whitespace, and final render quality.

Deck Profile Router

After task mode, choose exactly one primary deck-profile. This is a hard routing step, not a labeling exercise. The profile determines which proof objects, source rules, visual density, asset rules, and QA gates are blocking.

Profiles:

• finance-ir: earnings, investor relations, operating reviews, financial analysis. Requires exact reported figures, unit discipline, source footnotes, bridges, tables, and disclosure logic.
• product-platform: SaaS/platform/product narratives. Requires architecture maps, workflow diagrams, adoption proof, product-to-financial linkage, and no generic feature-card grids.
• gtm-growth: GTM, marketing, consumer growth, subscription ecosystems, mobility, customer engagement. Requires a visible growth loop, segment or cohort proof, monetization bridge, and brand-aware rhythm.
• engineering-platform: developer, AI, infrastructure, data, security, and technical platform decks. Requires accurate system diagrams, technical labels that survive executive simplification, and metrics tied to the architecture.
• strategy-leadership: investor-day, board, transformation, and market strategy decks. Requires chapter discipline, market framing, strategic bets, and transition slides that carry the thesis.
• consumer-retail: lookbooks, clienteling, luxury, consumer-brand, campaign, travel, lifestyle, food, fashion, beauty, people, places, animals, sports, playful/kids visual storytelling, and other image-led decks where the audience needs to visually inspect the subject. Requires real assets or explicit asset provenance, image quality, editorial hierarchy, and client-ready copy.
• template-following: user supplied a template/source deck whose style must be preserved. Requires template-audit.txt and deviation-log.txt before any redesign.
• targeted-edit-data: add or edit a data/comparison slide. Requires exact calculations before visual work and a native-looking insertion into the existing deck.
• targeted-edit-media: add headshots, logos, screenshots, or other media. Requires identity/source verification, consistent crops, and preservation of the source deck layout grammar.
• appendix-heavy: dense appendix, tables, disclosures, or source packs. Requires index/page markers, readable small-type thresholds, table grammar, and explicit source-density rules.

If more than one profile applies, pick the profile that creates the highest delivery risk as primary, then list secondary gates in the claim spine. Example: a finance investor deck with a supplied template is finance-ir primary and template-following secondary.

When a profile is selected, read its corresponding file under $SKILL_DIR/profiles/ if the task is substantial or unfamiliar:

• finance-ir.md
• product-platform.md
• gtm-growth.md
• engineering-platform.md
• consumer-retail.md
• template-and-edit.md
• appendix-heavy.md

Create $WORKSPACE/profile-plan.txt with:

• task mode
• primary deck-profile
• secondary profile gates, if any
• required proof objects
• source/asset requirements
• brand authenticity constraints for logos, icons, mascots, screenshots, and other identity assets
• profile-specific QA gates
• known missing inputs

Phase 0: Source And Reference Read

For every source or reference deck:

• Render it to PNGs or PDF pages.
• Make a contact sheet.
• Extract slide text.
• Identify which slides are content sources, which are visual targets, and which patterns are anti-patterns.

For source links:

• Browse or otherwise retrieve the actual source page.
• For finance/product narratives, exhaust official linked materials such as earnings decks, supplements, filings, and IR PDFs before omitting customer, cohort, module, bookings, retention, guidance, or mix metrics.
• Extract exact metrics and source dates.
• Keep links in source notes and in a quiet deck footer or appendix.
• Never invent missing metrics to make a chart prettier.

Brand authenticity gate:

• Treat logos, mascots, app icons, product UI, character marks, badges, partner marks, and customer marks as identity assets.
• Do not draw, trace, approximate, or stylize a company logo, mascot, app icon, or signature brand mark from scratch unless the user explicitly asks for an unofficial concept.
• Use a verified source asset with provenance, use a user-provided asset, or omit the identity asset entirely.
• When an official asset cannot be verified or embedded cleanly, rely on color, typography, layout, product language, and reported metrics as brand cues instead of inventing a pseudo-logo or decorative icon.
• Record every identity asset in $WORKSPACE/source-notes.txt with source, provenance, and why it belongs in the deck.
• For template-following and source-deck tasks, inspect which identity assets are official in the source. Preserve or borrow only verified assets; do not create lookalike marks to fill visual gaps.

Create:

• $WORKSPACE/source-notes.txt
• $WORKSPACE/reference-audit.txt
• $WORKSPACE/data.json when metrics/charts are used
• $WORKSPACE/template-audit.txt for template-following or targeted-edit modes
• $WORKSPACE/deviation-log.txt when inheriting a source deck visual system

For template-following and targeted-edit modes, template-audit.txt must include:

• preserve: visual rules that must survive
• improve: weak spots that can be upgraded
• do not imitate: source artifacts that should not be copied
• brand/assets: logos, colors, imagery, type, and crop language
• insertion contract: how new slides or objects join the existing deck

Phase 1: Narrative Spine

Before designing, write the story as slide claims. This is binding.

Every non-appendix slide must have:

• a kicker: 1-3 words that names the role, e.g. EXPANSION DRIVERS
• a claim title: a conclusion, not a topic label
• a proof object: one chart, table, timeline, diagram, or visual comparison
• a support note: concise, factual, and source-backed

For finance/product narratives, a slide with only one thin chart usually fails. Prefer one dominant proof object plus a compact context rail, variance table, or callout stack when it improves the argument. Reject proof objects whose metric movement is too small to carry the claim unless they support a larger bridge. Product maps must show product-to-business linkage: module or workflow, adoption signal, expansion/monetization logic, or efficiency impact.

Bad title: Revenue and margin trends

Good title: Growth slowed, but the margin engine kept expanding.

Bad title: Expansion drivers

Good title: Backlog is compounding faster than revenue.

If a title can be used after swapping the company name, sharpen it.

Create $WORKSPACE/claim-spine.txt with:

• thesis
• audience
• one-line arc
• slide list with claim, proof object, source, and omission notes

Phase 2: Design System Lock

Create $WORKSPACE/design-system.txt before writing slide modules.

The design system must define:

• slide size, usually 1280x720
• background system
• typography pair using installed fonts only
• color palette with usage rules
• chart grammar
• diagram grammar
• connector grammar
• container / box grammar
• source/footer grammar
• page marker grammar
• title/kicker grammar
• data-label grammar
• brand asset policy and identity-asset provenance
• allowed brand cues versus forbidden logo/icon/mascot approximations
• allowed layout families
• banned motifs

For premium analytics decks, prefer:

• warm paper or deep ink backgrounds, not default pale dashboards
• a display serif or refined display face for claims
• a utilitarian sans for labels
• hairline rules instead of box outlines
• open composition instead of repeated cards
• direct labels on charts instead of heavy legends
• fewer objects with stronger hierarchy
• Kickers must align as one optical unit: marker center and label center share the same y-axis, and letter-spaced all-caps labels must be vertically centered in a box with enough breathing room to avoid low-looking baselines.
• Use a canonical kicker construction rather than hand-tuning each slide:
  • marker and label must be named as a pair, e.g. kicker-marker and kicker-label, or kicker-01-marker and kicker-01-label
  • marker and label boxes should share the same vertical center within <= 1px
  • the label box must use middle vertical alignment and enough height to avoid low-looking glyphs after render/export
  • if multiple kicker rows appear on a slide, suffix the pair names consistently so QA can verify each row

Do not use a one-note palette. Do not let teal, navy, beige, purple, or gray dominate without a deliberate secondary contrast.

Phase 3: Contact-Sheet Plan

Before building slides, create $WORKSPACE/contact-sheet-plan.txt.

For a 10-slide deck, use at least 5 distinct macro-layout families, such as:

• cover with metric rail
• editorial product map
• horizontal bar proof with margin notes
• donut or mix proof with ranked evidence table
• line chart with right-side KPI stack
• sequential bar chart with side summary rail
• two-series cash chart with margin callout
• roadmap timeline
• dense appendix table
• dark appendix/source page

Hard gates:

• no more than 2 card-grid slides in a 10-slide deck
• no 3 consecutive slides may share the same macro layout
• no repeated title + subtitle + boxed panel grid cadence
• no rounded card default unless the data relationship requires containment
• no decorative boxes around prose

The contact sheet must look authored before details are read.

Phase 4: Editable Build

Build one ESM slide module per slide in $SLIDES_DIR, exporting numbered functions such as:

export async function slide01(presentation, ctx) {
  const slide = presentation.slides.add();
  // editable artifact-tool presentation JSX content
  return slide;
}

Prefer native editable shapes, lines, text, tables, and chart-like constructs. For charts, native chart helpers are allowed, but authored editable chart systems built from shapes are acceptable when they give better label placement and visual polish.

Structured Visual Precision Contract

Charts, diagrams, connectors, boxes, tables, and flows are high-risk proof objects. Treat them as geometry systems, not decoration.

Before authoring any structured visual, define:

• what the visual must prove
• the primary reading order
• each node / mark / series and what it means
• each edge / connector and what relationship it encodes
• each container / box and what grouping or containment it means
• the intended alignment, spacing, and label attachment rules

Hard build rules:

• Connected series must be rendered as one continuous editable path or as a verified native chart series. Do not fake a line with separately rotated rectangles, disconnected strokes, floating slashes, or decorative arrows.
• Every connected series must pass through its intended markers and preserve the correct point order after render/export.
• In diagrams, connectors must visibly attach to the correct source and target, follow the intended direction, avoid unrelated objects, and terminate cleanly without ambiguous crossings.
• Do not use arrows unless directionality matters. If direction matters, arrow heads must be consistent, legible, and semantically meaningful.
• Boxes must imply a real grouping, comparison, lane, stage, or containment relationship. Remove containers that only decorate prose.
• Equal-role boxes must share exact height, alignment, padding, border logic, and text treatment unless the hierarchy intentionally differs.
• Text inside boxes must have enough padding and never sit against edges, collide with rules, or rely on shrink-to-fit as the default.
• Use a minimum 12px vertical interior padding for boxed prose / callouts and 16px when the box carries 2+ lines or dark-background copy. If a box only looks correct with near-zero bottom room, enlarge the box or shorten the copy.
• Any text that starts inside a filled callout / metric container and spills past that container edge is a hard failure, even if the overflowed line is no longer classified as an in-box child by a layout script.
• Labels must anchor to the mark, series, box, or connector they describe. A viewer should never need to guess which label belongs to which object.
• Repeated metric rails / KPI stacks must preserve their full grammar on every item: if the pattern is value + label + context, every item must visibly render all three pieces with adequate contrast against its background.
• Preview-visible defects override layout-script silence: orphan labels, missing values in a repeated metric pattern, markers sitting on top of copy, or any object that looks obviously accidental at full size must be treated as a build failure even when export and layout checks succeed.
• Tables and matrices must preserve row/column grammar under thumbnail review: headers, baselines, alignment, and emphasis must remain visually consistent.
• If a chart or diagram requires too many exceptions to remain clear, rebuild it with a simpler visual rather than patching around geometry defects.

artifact-tool presentation JSX chart caveat:

• Try native slide.charts.add(...) when the API can represent the chart.
• Always verify the exported PPTX package for ppt/charts/chart*.xml.
• If native chart parts are not preserved, or export throws toProto / setChangeHandler errors, switch to authored editable chart primitives rather than shipping weak native charts.
• Do not style chart.yAxis.majorGridlines unless freshly verified; it can fail export with this[#h].toProto is not a function.
• Do not fake per-point bar colors by adding zero-valued helper series. If native charts cannot express the visual cleanly, rebuild the chart with editable shapes and direct labels.
• For line, trend, or connected-series visuals, prefer a verified native line chart when the API can express the chart cleanly. If authored with primitives, draw the series as one continuous editable custom path / polyline through the data points.
• Do not construct a line series from individually rotated rectangles or short segment shapes; these can export as detached slashes or broken pseudo-arrows.
• Record the choice in $WORKSPACE/qa/comeback-scorecard.txt.

Use helper scripts copied with this skill:

node "$SKILL_DIR/scripts/render_artifact_slide.mjs" \
  --workspace "$WORKSPACE" \
  --slide-module "$SLIDES_DIR/slide-01.mjs" \
  --output "$PREVIEW_DIR/slide-01.png" \
  --layout "$LAYOUT_DIR/slide-01.layout.json"

node "$SKILL_DIR/scripts/build_artifact_deck.mjs" \
  --workspace "$WORKSPACE" \
  --slides-dir "$SLIDES_DIR" \
  --out "$FINAL_PPTX" \
  --preview-dir "$PREVIEW_DIR" \
  --layout-dir "$LAYOUT_DIR/final" \
  --contact-sheet "$PREVIEW_DIR/contact-sheet.png" \
  --slide-count <n>

Presentation JSX source must resolve through artifact-tool. Do not bypass the bundled runtime with unrelated package imports.

Editable primitives are encouraged for charts, diagrams, and abstract product flows. They are not a license to fabricate brand marks. Do not create brand-like icons, mascots, app marks, partner marks, or pseudo-logos as decoration or to fill whitespace. If the asset is not verified, solve the slide with stronger hierarchy, data, copy, or abstract shapes instead.

Phase 5: Comeback Rubric

Score the rendered contact sheet and full-size slides in $WORKSPACE/qa/comeback-scorecard.txt.

Each dimension is 0-5:

• story: titles are claims; sequence has a real arc
• specificity: deck would fail the noun-swap test
• rhythm: contact sheet has varied macro layouts
• whitespace: slides breathe without feeling empty
• chart clarity: charts prove one sentence, labels are direct, and geometry is continuous / correctly attached
• typography: type feels intentional, not default
• restraint: no filler boxes, badges, or decorative clutter
• precision: metrics and source notes are exact
• coherence: one visual system across the deck
• reference delta: visibly better than the target reference, when supplied

Required minimum before delivery:

• total score >= 44 / 50 when a reference is supplied; otherwise >= 40 / 45
• no dimension below 4
• reference delta >= 4 when a reference is supplied; otherwise mark it n/a and do not claim reference-beating

Profile gates are pass/fail and sit above the numeric rubric. A deck fails even with a high visual score if the profile gate fails. Common profile blockers:

• finance-ir: invented or unsupported metrics, mixed units, missing footnotes, or charts that look good but do not reconcile to sources.
• product-platform: generic feature cards, architecture boxes that say nothing, module lists without adoption or monetization proof, or missing adoption/business linkage.
• gtm-growth: funnel labels without progression logic, weak brand fit, fabricated brand marks, or monetization claims unsupported by proof.
• engineering-platform: technically vague diagrams, labels stripped of real meaning, or developer details that overwhelm the executive story.
• strategy-leadership: chapter dividers without thesis movement or a market frame that never returns in the operating plan.
• consumer-retail: stock-looking imagery, weak crop quality, unverified asset provenance, or client outreach copy that feels generic.
• template-following: style drift from the source deck without an explicit deviation reason.
• targeted-edit-data: calculation mistakes, wrong ranking, or a new slide that looks pasted in.
• targeted-edit-media: unverified identities, inconsistent headshot crops, or local layout damage.
• appendix-heavy: unreadable tables, missing index, or source density that hides the answer.
• brand authenticity: fabricated logo, mascot, app icon, signature mark, unverified product UI, or pseudo-official mark used as decoration.

If a reference deck is supplied, write a blunt slide-by-slide comparison:

• where this deck beats the reference
• where the reference still wins
• what changed after iteration

Phase 6: Mechanical Verification

Before final delivery:

• Confirm the final PPTX exists and is non-empty.
• Confirm the expected slide count in the package.
• Confirm no empty media files.
• Confirm chart package parts when native charts are required, or document why authored editable chart primitives were used instead.
• Render every final slide to PNG through artifact-tool.
• Inspect the artifact-tool contact sheet at thumbnail size and the full-size PNG renders for visual errors.
• During full-size render review, explicitly verify repeated UI grammars such as KPI rails, step sequences, legends, and forecast strips for completeness and contrast: no blank value slots, no same-color-on-background text, and no decorative marks that collide with the reading path.
• For every chart, diagram, matrix, connector system, and box system, inspect the rendered slide at full size and verify the intended geometry:
  • connected lines are continuous and pass through the correct markers
  • bars / dots / labels align to the same baseline or axis logic
  • arrows and connectors attach to the intended objects and do not float
  • arrows point in the intended reading direction
• boxes that share a role line up, carry equivalent padding, and do not clip or crowd text
• kickers / eyebrow rows align optically: icon, rule, and label sit on one centerline rather than a low or drifting text baseline
• Use the kicker naming convention so layout QA can verify centerline alignment; un-named kicker rows are a QA gap, not a pass.
• boxed prose and callouts keep visible top/bottom breathing room, especially on dark fills and multi-line statements
  • grouped objects read as a coherent system at thumbnail size
• Inspect the contact sheet and full-size renders for unofficial logos, app icons, mascots, product UI, partner marks, and customer marks. Confirm each identity asset is verified in source notes or remove it.
• Do not require, bundle, or assume LibreOffice or any other external renderer. If a compatible renderer is already available and the user asks for it, it may be used as non-blocking extra QA only.
• Run layout checks and fix all errors. Warnings may remain only when they are known false positives from intentional table/axis/label construction and the rendered slide is clean.
• Deficient box padding and text overflow out of filled callouts are errors, not acceptable warnings.

Phase 7: Final QA Ledger

Create $WORKSPACE/qa/comeback-scorecard.txt with:

• final score by rubric dimension
• primary deck-profile and profile gate pass/fail
• reference-deck comparison
• tool/runtime caveats
• package checks
• render checks
• accepted warnings or tradeoffs

Do not leave the scorecard as vague praise. It should name the remaining weak spots if any exist.

Blocking Anti-Patterns

Fix these before delivery:

• title states a topic instead of a conclusion
• slide uses more than one dominant evidence object
• chart has a legend when direct labels would work better
• chart displays data but does not prove the title
• connected-series chart is rendered as detached strokes, floating slashes, pseudo-arrows, or a path that misses its markers
• line or connector geometry changes meaning after render / export
• connector floats, attaches to the wrong object, crosses unrelated structure, or points in an ambiguous direction
• arrows are decorative rather than semantic
• box system implies grouping that the content does not support
• equal-role boxes are visibly misaligned, inconsistently padded, or styled as if they have different meanings
• label appears visually detached from the mark, series, connector, or box it describes
• a repeated KPI / metric rail omits a required value, label, or context line on any item
• a marker, node, glyph, or accent shape visibly sits on top of readable copy
• a value is technically present but visually lost because it has insufficient contrast against the background
• table or matrix loses its row / column grammar at thumbnail size
• proof object is too thin to carry the claim
• product or architecture diagram lacks adoption, monetization, expansion, or efficiency linkage
• visible containers are louder than the content
• rounded cards are used as default scaffolding
• three slides in a row share the same composition
• contact sheet reads as a template pack
• contact sheet has clean slides but weak information architecture
• body copy exists only to fill space
• appendix is clean but unreadable
• artifact-tool render has obvious wrapped labels, collisions, awkward vertical text, or cramped callouts
• footer/source/page marker changes style
• kicker icon and label are not optically centered on the same row
• kicker rows are hand-built without named marker/label pairs, preventing QA from verifying their alignment
• boxed prose appears pinned to the bottom edge or lacks visible vertical breathing room
• typography falls back to default without intent
• low-resolution logo or rough image crop
• fabricated or approximated official logo, mascot, app icon, product UI, or signature brand mark
• brand-like icon used just to fill whitespace
• unprovenanced partner/customer logos, product screenshots, or brand badges
• unsupported metric or vague source label
• output only matches the reference instead of beating it

Iteration Rule

Do not stop after the first export unless the comeback rubric passes. Iterate the weakest 2-4 slides first, then rerender the full deck. Prefer a bold rebuild of a weak slide over cosmetic nudge work.

If a model or tool cannot reach the reference quality, say exactly why and name the remaining weakest slides. Do not call the deck done because a PPTX exists.

Subagents

Subagents are allowed when the user explicitly asks for them. Use them for:

• source metric extraction
• reference deck critique
• QA scoring
• appendix implementation from a fixed spec
• alternate prototype generation in a separate workspace

The main agent owns final story, visual system, integration, and QA. Never ship a raw stitched deck from independent slide workers.

Matrix Battle Harness

Use this harness when validating or improving the skill across many prompts. It creates deck-quality probes, not source-complete final decks, unless all attachments and source data are available. The probe output is for stress testing profile routing, visual grammar, proof-object quality, and QA gates.

Command:

node "$SKILL_DIR/scripts/run_prompt_battle.mjs" \
  --prompts "$WORKSPACE/batch-prompts/slides_prompts_first25.json" \
  --workspace "$WORKSPACE/batch-runs/full-25" \
  --limit 25 \
  --scale 0.55

The harness writes:

• one editable PPTX per prompt
• PNG previews for every slide
• per-prompt contact sheets
• aggregate first-slide and proof-object contact sheets
• battle-summary.json
• battle-summary.txt

After a battle run:

• run layout checks across every layout/ directory
• confirm every PPTX has the expected slide count
• confirm no empty media files
• inspect aggregate contact sheets for sameness
• update this skill when repeated failures show a missing gate

Do not confuse a battle probe with a final customer deck. For final delivery, rerun the normal workflow with the actual source attachments, exact metrics, real imagery, and full reference comparison.

Final Delivery

After the final PPTX is exported and verified, run the cleanup helper:

node "$SKILL_DIR/scripts/cleanup_presentation_workspace.mjs" \
  --workspace "$WORKSPACE" \
  --output-dir "$OUTPUT_DIR"

The cleanup helper preserves final .pptx deliverables in $OUTPUT_DIR and deletes scratch artifacts from the current thread-scoped $WORKSPACE:

• Delete generated planning and QA text notes such as profile-plan.txt, source-notes.txt, reference-audit.txt, claim-spine.txt, design-system.txt, contact-sheet-plan.txt, battle-summary.txt, and $WORKSPACE/qa/*.txt.
• Delete generated reference/imagegen prompt text files such as *.imagegen.txt and reference-imagegen-prompts.txt.
• Delete rendered review artifacts such as contact-sheet.png, preview PNGs, temporary reference PNGs, and other temporary images that are not deliberately embedded in the final deck.
• Delete generated per-run scripts and slide modules, including files under $SLIDES_DIR. Do not delete the installed skill helper scripts under $SKILL_DIR/scripts.
• Delete generated layout JSON, build manifests, and other per-run scratch metadata.
• Do not delete user-provided source files, source decks, or assets that are intentionally embedded in or required to regenerate the final deck.
• If the user explicitly asks for QA artifacts, keep only the requested artifacts and mention that they were retained.
• Never delete sibling folders under ${TMPDIR:-/tmp}/codex-presentations/ or any other thread's workspace.

If $OUTPUT_DIR is outside $WORKSPACE, the cleanup helper deletes $WORKSPACE and does not clean the external output directory. That external directory must contain only final deliverables, not scratch artifacts.

Do not attach or link contact-sheet.png, preview PNGs, generated scripts, planning docs, JSON manifests, layout JSON, imagegen prompt files, or temporary images unless the user explicitly asks for QA artifacts. Do not mention that scratch or QA artifacts were cleaned up in the final response; the final response should focus on the user-facing deck only.

Deliver:

• final .pptx with a relevant deck-title filename, not a generic name such as output.pptx or deck.final.pptx
• brief scorecard summary
• note any residual gap against the reference

The final response should be short and artifact-focused.