presentations

name	Presentations
description	Create or edit PowerPoint or Google Slides decks

Slides Skill

Use this skill as reference material when creating or editing presentation slide decks.

Important Instructions

• [HARD REQUIREMENT] Content quality and storytelling: before planning the deck, read and follow Content Quality and Narrative Rules. Ensure the deck covers everything the user requested and forms a coherent, audience-appropriate narrative rather than a collection of disconnected facts.

• [HARD REQUIREMENT] Audience-facing copy: visible slide content must be written for the intended audience, not for the person or model producing the deck. Do not expose planning notes, timing scaffolds, talk tracks, content-selection commentary, or other internal process language unless the user explicitly requests it.

• Info density: avoid cramming low-value details onto a single slide. Prefer lower-density slides with high-value content.

  • Title slide: keep the title slide minimal and simple. Avoid cramming in too much information.

• Layout: keep things clean and simple. Avoid low-quality visuals, but also avoid excessive white space. By default, use equal left and right margins on each slide.

• [HARD REQUIREMENT] Overlap: always pay attention to programmatic overlap warnings. Do not assume that overlapping elements in diagrams are intentional, and do not ignore overlap warnings without inspecting them. You MUST fix all unintended overlap errors before delivering the slides. This is critical.

• [HARD REQUIREMENT] Font size: when a template is provided, match its font sizes. When no template or style guidance is given, you MUST use at least 50pt for deck titles, 35pt for slide titles, 24pt for mid-level text such as subheadings, callout headers, and text-box titles, and 16pt for body text.

• Text layout: when there is too much text, shorten it before shrinking the font size. Inspect visually for unexpected text wrapping. NEVER allow a title/banner text box intended for one line to wrap to two lines.

• Narrative copy must fit the chosen layout: shorten it or change layouts rather than adding density or shrinking type.

• Visual assets:

  • [HARD REQUIREMENT] DO NOT use Python to draw images; DO NOT use programmatic vector shapes for visuals; DO NOT use programmatic drawings of any sort. Use image search or image_gen tool instead!
  • [HARD REQUIREMENT] Minimize the use of diagrams. Add them only when requested or when a single diagram materially improves the clarity of complex concepts. Diagram implementation rules: use native PowerPoint shapes for simple diagrams; use Graphviz for complex relational/topological/network-like diagrams; use image_gen for highly aesthetic, illustrative, or scientific infographic diagrams (e.g. chemical structures, circuit diagrams, etc.). When using native PowerPoint shapes with connectors, create connectors (arrows/edges) before creating entity nodes, so edges appear behind nodes and never cross through node shapes or labels. If this ordering is awkward during early iteration, you may create nodes first in the initial draft, then switch to connectors-first in the revised code.
  • Before sourcing or generating visuals, be mindful of the desired aspect ratio, placement, and cropping options on the slide. For example, if you intend to place text to the left of the image containing a person, you should ask image_gen to put the person on the right side of the image.
  • By default, DO NOT reuse the same image more than once (unless it's a background).
  • Prepare visuals for both the main concept and decorative support.

• Default styling: use one composition instead of a collection of UI panels. UI-like styling typically includes card grids, pills, badges, button-like text boxes, tab or navigation patterns, repeated modular panels, dense dashboard-style layouts, and other component-library aesthetics that imply interactivity. Use stylized text boxes sparingly, favoring a flat structure on the canvas.

Skill Folder Contents

Contents of the slides/ skill folder:

• container_tools/: Standalone python scripts for slides and relevant asset manipulation.
• references/: Additional workflow references for specialized presentation tasks.
• template_following_scripts/: Helper scripts for exact source-deck/template following.
• artifact_tool/: API documentation and coding examples for the artifact tool library.
• builtin_templates_support/: Checked-in guidance, manifests, prompts, and reusable scripts for built-in templates. Each template owns its ARTIFACT.md; shared runners live once under builtin_templates_support/scripts/.
• assets/builtin_templates/grid-layout-library/: Blob-managed static assets for the built-in Grid Layout template, including 26 rendered previews, a model-facing registry, structured content tokens, and 26 exact plain-JavaScript artifact-tool Compose reconstructions with no JSX. This directory contains no Markdown, prompts, or reusable runners.

Container Tools

The following helper scripts are located in the container_tools/ directory:

• ensure_raster_image.py: Ensure images are rasterized; convert to PNG if needed; quick usage --input_files <img_path1> ....
• render_slides.py: Render a PowerPoint file into a folder of PNG slides using default sizing; quick usage: <input.pptx>. Output files are named slide-1.png, slide-2.png, ... in a directory with the same name as the input file.
• create_montage.py: Build a tiled montage from images in a directory (for viewing multiple image assets or rendered slides at once); quick usage: --input_dir <imgs_dir> --output_file <montage.png>. It supports most image formats with auto conversion under the hood.
• slides_test.py: Detect content overflowing the original slide canvas; usage: <input.pptx>.

Grid Layout Artifact-Tool Compose Layout Reference

This skill variant does not include the Office template file. Use the distilled layout library as initial design and composition guidance when the user has not supplied a stronger template or brand system.

Before planning slides:

1. Read builtin_templates_support/grid-layout-library/ARTIFACT.md, assets/builtin_templates/grid-layout-library/design_tokens.json, and assets/builtin_templates/grid-layout-library/artifact-tool-compose/template-registry.json.
2. Inspect assets/builtin_templates/grid-layout-library/assets/previews/layout-library.png, then shortlist layouts by templateUse, layoutFamily, slots, densityBudget, and typographyBudget. Do not open all 26 implementation modules by default.
3. For each selected layout, inspect its generated preview and exact assets/builtin_templates/grid-layout-library/artifact-tool-compose/slide-XX.mjs reconstruction.
4. Use the selected module's layers(...), text(...), shape(...), image(...), and table(...) helper calls as the implementation reference. Keep the output as plain .mjs and use slide.compose(...); do not introduce JSX or a transpilation step.
5. Preserve the selected layout's content ownership, spacing, hierarchy, and media frames while replacing instructional sample text with the user's content. Vary silhouettes across the deck instead of repeating one pattern.

The shared builtin_templates_support/scripts/create-presentation.mjs runner can materialize any compatible built-in template for validation when passed that template's static asset root. It is not a request to emit every layout in the user's deck. User-provided templates, explicit brand guidance, and exact source evidence always override this default template.

Workspace

Use the chat mode supplied by Codex. If the chat is not projectless, use the project-backed layout.

Set:

• SKILL_DIR=<absolute path to this skill>
• THREAD_ID=${CODEX_THREAD_ID:-manual-<timestamp-or-short-random-suffix>}
• TASK_SLUG=<sanitized task/deck slug>
• TOPIC_SLUG=<sanitized final deck filename slug>

Select the remaining paths:

Chat	Scratch workspace	Final PPTX
Projectless	$PWD/work/presentations/$TASK_SLUG	User-requested path, otherwise $PWD/outputs/$TOPIC_SLUG.pptx
Project-backed	$SCRATCH_ROOT/codex-presentations/$THREAD_ID/$TASK_SLUG	User-requested path, repository convention, or <project-root>/outputs/$TOPIC_SLUG.pptx

For project-backed chats, use an external scratch directory supplied by the host. If none is supplied, compute SCRATCH_ROOT with node -p "require('node:os').tmpdir()"; do not hardcode a platform-specific temp path. Project-backed scratch must remain outside the repository.

An explicit user destination always wins. Set OUTPUT_DIR to the directory containing FINAL_PPTX. If a projectless final is outside outputs/, an optional copy under outputs/ may be created for app surfacing, but the requested path remains the primary result. Do not modify Git ignore settings to conceal scratch files.

Common workspace layout

After selecting WORKSPACE, set:

• TMP_DIR=$WORKSPACE/tmp
• SLIDES_DIR=$TMP_DIR/slides
• PREVIEW_DIR=$TMP_DIR/preview
• LAYOUT_DIR=$TMP_DIR/layout
• ASSET_DIR=$TMP_DIR/assets
• QA_DIR=$TMP_DIR/qa

Use absolute paths in scripts and handoffs. Put every generated file under $TMP_DIR except FINAL_PPTX and any additional deliverables explicitly requested by the user. Retain $WORKSPACE after delivery so follow-up turns can inspect and reuse the prior work.

Use .txt for every generated intermediate prose artifact in $TMP_DIR, including plans, source notes, prompt records, design notes, QA ledgers, and fallback reasons. Reserve .md for installed skill/reference files such as SKILL.md, references/*.md, and templates shipped with the skill. Do not create generated planning files such as slide-plan.md.

Route the Request Before Authoring

Choose the output path first:

1. Existing native Google Slides deck: use the Google Drive plugin's Google Slides skill. Do not round-trip it through a local PPTX unless the user asks.
2. Net-new native Google Slides deck: build and verify a local PPTX with this skill, then import it as described in Google Slides-Targeted Output.
3. PowerPoint or local deck: build or edit the PPTX with this skill.

For every deck built with this skill, choose exactly one visual route. The first matching route wins:

1. User reference or template skill: if the user supplies a reference deck, asks to follow an existing deck, or invokes a template skill, use only that file as the visual source. An existing PPTX being edited also counts as the reference. Do not mix in Grid Layout or another template.
2. Explicit custom formatting: if there is no reference and the user asks for a theme, brand treatment, visual style, mood, or custom formatting, create the deck from scratch. Do not use Grid Layout.
3. No visual direction: use the bundled Grid Layout Artifact.md layout library as the composition reference. Select and adapt layouts using the Grid Layout instructions above; do not run PPTX template-following mode.

User-provided references and explicit visual direction always take precedence over Grid Layout.

Google Slides-Targeted Output

For a net-new native Google Slides request, create and verify a local .pptx with this skill first. The native Google Slides deliverable must then be produced by the Google Drive plugin's presentation import action, mcp__codex_apps__google_drive_import_presentation, with upload_mode: "native_google_slides".

Do not use Computer Use, Browser Use, blank-Google-Slides creation plus Google Slides write APIs, or another direct-to-Slides construction path for net-new Google Slides unless the user explicitly asks for that alternate workflow. If the Google Drive plugin is unavailable, ask the user to install google-drive@officer-curated. If the plugin is available but presentation import is missing, ask the user to reinstall or refresh the Google Drive plugin before continuing with the native Google Slides deliverable.

The local .pptx creation and native import workflow above applies only to net-new Google Slides deliverables.

Implementation

You MUST use open-office-artifact-tool from JavaScript ES modules to implement the slide deck.

Read the local docs before coding:

• artifact_tool/API_QUICK_START.md
• artifact_tool/api/API_DOCS.md

For slide backgrounds, use the typed slide.setBackground(...) and slide.clearBackground() primitives documented in artifact_tool/api/references/slide.spec.md. Direct solid/style-reference backgrounds cross the canonical OpenChestnut PPTX path. Never flatten an inherited Layout/Master background or silently replace an advanced imported background graph; preserve it unchanged or let the export fail closed.

For compound objects that must retain one ownership tree and local coordinate space, use native slide.groups.add(...) and read artifact_tool/api/references/grouping.spec.md. Canonical recursive groups cross the OpenChestnut PPTX path; imported topology is fixed, and complex group shells remain one opaque read-only object rather than being flattened.

For imported deck order, slide.moveTo(existingZeroBasedIndex) changes only the retained source SlidePart order in p:sldIdLst; it does not copy or reconstruct slide graphs. slide.delete() is separate and intentionally much narrower: it performs a real OPC delete only for an isolated layout-only, non-final slide whose source part has exactly its layout relationship, no inbound relationship, and no custom-show/section/extension or presentation-level identity reference. It removes the source slide part and its relationship part while preserving every survivor. Media, notes, comments, charts, OLE, hyperlinks, data parts, or any other connected graph fail closed. Imported add and duplicate/clone remain unsupported until an explicit OPC graph-clone transaction is available.

When an imported top-level OLE object contains one uniquely bound XLSX package, read artifact_tool/api/references/ole-workbooks.spec.md before changing it. Only getEmbeddedWorkbook() and replaceEmbeddedWorkbook(...) are allowed: the latter replaces the validated workbook bytes while preserving the OLE shell, relationship topology, preview image, and every unrelated native part. Do not patch an embedding part directly or present a reconstructed OLE object as equivalent; ambiguous, shared, malformed, or source-tampered graphs must fail closed.

For review annotations, read artifact_tool/api/references/comments.md before calling slide.comments.addThread(...). Canonical PPTX export supports only one legacy slide-level comment with undefined target, one author, one text item, and an explicit coordinate. Modern threads, replies, reactions, resolved state, and element/text anchors must stay opaque/source-bound or fail closed; never flatten them into a legacy comment.

Before running any generated presentation module, initialize its workspace so Node.js can resolve the bundled open-office-artifact-tool package:

node "$SKILL_DIR/container_tools/setup_artifact_tool_workspace.mjs" \
  --workspace "$TMP_DIR"

Create the ES module source file (.mjs) under $TMP_DIR and export the final PowerPoint deck (.pptx) to $FINAL_PPTX. The generated source must be plain JavaScript that runs directly with node; do not require a transpiler or build step.

You MUST NOT use python-pptx or the old Python artifact_tool API.

Template Following

Use template-following mode only when a user-provided source PPTX supplies the layout, style, or template. Read references/template-following.md, use $TMP_DIR from the Workspace section, and set TEMPLATE_PPTX="<absolute path to the user-provided PPTX>".

Current availability: the reference starter-deck command below still needs an imported-slide duplicate graph clone and broad graph delete semantics, so it deliberately fails closed in the canonical codec. The isolated layout-only slide.delete() profile is not a substitute. Do not rebuild or share slide parts to emulate a clone. Until that milestone exists, use this mode only for source inventory, plan validation, and render/QA evidence; report the clone limitation before promising a derived starter deck.

Preserve the source deck's typography, palette, spacing, layout, placeholders, footers, page markers, and brand chrome unless the user explicitly asks to restyle. Do not use template-following mode for a deck created from scratch.

Create:

• $TMP_DIR/template-audit.txt
• $TMP_DIR/template-frame-map.json
• $TMP_DIR/deviation-log.txt

Keep $TMP_DIR/source-notes.txt for content and asset provenance.

Inspect the complete source deck:

node "$SKILL_DIR/template_following_scripts/inspect_template_deck.mjs" \
  --workspace "$TMP_DIR" \
  --pptx "$TEMPLATE_PPTX"

Map each output slide to an inherited source slide and identify element-level editTargets. Then validate the map. The later starter-deck command is retained for the future graph-clone milestone, but currently rejects before writing an output deck:

node "$SKILL_DIR/template_following_scripts/validate_template_plan.mjs" \
  --workspace "$TMP_DIR" \
  --map "$TMP_DIR/template-frame-map.json"

node "$SKILL_DIR/template_following_scripts/prepare_template_starter_deck.mjs" \
  --workspace "$TMP_DIR" \
  --pptx "$TEMPLATE_PPTX" \
  --map "$TMP_DIR/template-frame-map.json" \
  --out "$TMP_DIR/template-starter.pptx" \
  --preview-dir "$TMP_DIR/template-starter-preview" \
  --layout-dir "$TMP_DIR/template-starter-layout" \
  --contact-sheet "$TMP_DIR/template-starter-contact-sheet.png"

When a future graph-clone milestone enables template-starter.pptx, import it with open-office-artifact-tool and edit only inherited slides/objects unless the validated frame map explicitly allows an insertion. Today, if a source slide cannot support requested content without duplicate/delete or a parallel rebuild, report the blocker and the closest viable source-slide options.

QA Reminder

Before delivery, render every final slide and inspect each slide individually at full size. Use a contact sheet only to review deck-level flow and consistency, not as a substitute for full-size layout QA. Fix unintended overlap, clipping, wrapping, broken connectors, unresolved placeholders, inconsistent footers/page markers, and chart/data mismatches before exporting. Verify that researched claims and sourced assets are traceable, and cite sources if research was used.

Final Response

Return a short user-visible summary of the completed deck. Mention the sources cited or used if research informed the deck. Do not attach scratch plans, previews, layout JSON, or temporary assets unless the user asks for them.

Codex App final response citations

Use the inline form :codex-file-citation{...} and place each citation immediately after the claim it supports.

For read-only Q&A, cite the source deck. For a successful edit or creation, cite the final delivered deck. For a no-op edit, cite the inspected source deck.

For read-only Q&A, inspect the complete relevant slide, including callouts, the exact question or prompt, chart or table titles, displayed totals or sample sizes, and source or methodology footers. State the direct answer first and cite each distinct evidence-bearing object when exact IDs are available.

Unless the user requests an in-place edit, preserve the input PPTX and export a distinct edited copy. Cite every changed slide in the final response. If no requested content is found and no output is modified, cite the inspected source deck with a plain file citation.

For creation, include exactly one standalone Markdown link to the final delivered PPTX. Do not add a file, slide, or object citation.

Use slide citations when slide numbers come from the latest rendered or inspected cited deck:

:codex-file-citation{path="/abs/path/deck.pptx" artifact_kind="presentation" slide_number="3"}

Include slide_id only when artifact-tool inspection provides the exact stable sl/... ID and stable navigation matters:

:codex-file-citation{path="/abs/path/deck.pptx" artifact_kind="presentation" slide_number="1" slide_id="sl/gs5z1kshq0xv"}

For a concrete chart, table, image, diagram, or callout, include object_id only when inspection provides the exact ID and you can add a useful label:

:codex-file-citation{path="/abs/path/deck.pptx" artifact_kind="presentation" slide_number="1" slide_id="sl/gs5z1kshq0xv" object_id="ch/pz9t1r3ka8vn" label="ARR by segment chart"}

Do not cite internal previews, contact sheets, layout JSON, source notes, scratch files, builders, manifests, or QA outputs unless asked. If slide or object IDs are not reliable, cite the slide without object detail rather than guessing.