/editable-figure

name: editable-figure
description: Analyze source material, find relevant paper, README, or awarded-proposal references, and design concise figures as editable PowerPoint objects. Use for overview, mechanism, workflow, or hero figures when an editable PPTX is wanted, including simplifying dense drafts and combining a schematic with a compact result panel. Complements scientific plotting; does not replace screenshot capture, prompt-only work, or full slide-deck authoring. Completing a PPTX deliverable requires desktop PowerPoint on Windows or macOS for the native rendering and editing checks; the bundled export helper is Windows-only. Assessment and prompt-only requests need neither.

Editable Figure

Overview

Turn a document's central idea into a figure that a reader can understand quickly, then deliver a PowerPoint source that the author can actually edit. The common workflow is **analyze, find references, design, build native objects, inspect in context**. Paper, proposal, and README figures share this workflow but serve different reader decisions.

Choose the scope

Respect the requested deliverable. An assessment or prompt-only request does not require generating a deck. Once figure creation is authorized, use subsequent feedback to revise the artifact without repeatedly asking permission. Choose a reasonable composition and produce a reviewable draft when the source is sufficient.

Use this skill for the figure's editorial and design decisions. If an installed presentation skill applies, read it for the current authoring runtime and validation requirements. Without one, use an available PPTX library or native PowerPoint automation and the principles in [native-powerpoint.md](references/native-powerpoint.md). This workflow works with Codex, Claude Code, or another capable agent; it does not depend on one model or desktop plugin.

**Platform requirement.** Before starting a figure build, confirm that the session can use desktop PowerPoint on Windows or macOS for the rendering and editing checks in step 5. A PPTX library such as `python-pptx` or PptxGenJS can create native objects headlessly, and that is a real capability. It does not complete these checks: nothing on a headless machine can confirm the result opens, renders, and edits as intended, and an unverified figure is the failure this skill exists to prevent. The bundled `scripts/render_powerpoint.ps1` uses Windows COM automation; macOS requires an available native PowerPoint workflow instead.

Without that capability, explain the limitation before building. Assessment and prompt-only work can continue unaffected. Offer `ci-mockup-figure` when its output meets the user's needs. Preserve an explicit PPTX requirement unless the user agrees to another deliverable; do not silently substitute a flattened image and call it an editable figure.

Nearby workflows have distinct outputs:

• `figure-prompt-builder`: prompts and reference-guided concepts, when that is the requested endpoint.
• `ci-mockup-figure`: HTML mockups, screenshots, TikZ, or other code-native figure formats.
• A plotting workflow: scientific data plots with reproducible data and axes.
• A presentation workflow: complete decks. Here a slide is a canvas for a document figure, not a presentation with a cover.

Do not replace an explicitly requested SVG, Illustrator document, or screenshot with PPTX merely because this skill is available.

1. Analyze the source and the reader's decision

Read the relevant section and its neighboring prose, the document's purpose, existing figures, and primary artifacts behind any claims. Identify the intended placement and display width before allocating space. Read only enough of a large repository to establish the contribution, terminology, evidence, and constraints.

Write a short working brief, in scratch space or beside the figure source when it needs to persist:

| Decision | Record | |---|---| | Audience and placement | Who sees the figure, where, and at what size? | | Reader takeaway | One sentence the reader should remember after a quick look. | | Usefulness | What can the reader understand, evaluate, build, or decide because of this work? | | Necessary visual evidence | The example, relationship, mechanism, or measured result that supports that takeaway. | | Content allocation | What belongs in the drawing, caption, neighboring prose, or a table? | | Claim boundaries | Facts versus illustrative examples, proposed work, predictions, and measured results. |

Apply the relevant mode in [document-contexts.md](references/document-contexts.md). Do not require every figure to summarize the whole project.

For proposal figures, also read [proposal-figures.md](references/proposal-figures.md) for distinct figure roles, visible aim-name consistency, shared-graph semantics, and reading at manuscript width. It links the author's preferred examples. Keep lessons from compact integration figures separate from untested large-overview designs.

For a benchmark, distinguish the system producing the record from the method being evaluated. For a proposal, distinguish planned capabilities from completed results. For a README, show the actual user workflow and supported behavior.

2. Find and study references before designing

For a new figure or substantial redesign, run a focused reference search before choosing the composition. Read [reference-search.md](references/reference-search.md) and use the route that matches the document:

• **Paper:** related top-venue papers, typically NeurIPS, ICML, and ICLR for ML/AI. Inspect the actual figure, caption, and nearby prose.
• **GitHub README:** current relevant trending projects and related active repositories. Inspect the rendered README and its actual visual assets.
• **Proposal:** start with the author's [preferred examples](references/proposal-style-exemplars.md) when they fit the figure's job. Search the local awarded/funded collection further when needed, using figure purpose