Slides

All tools named below live on the slides MCP server: call them with the mcp tool using server: "slides" and the bare tool name (slides/present in this document means server: "slides", name: "present").

The Slides addon exposes presentation creation and live preview through its runtime MCP server. The working model is a tool-owned manifest with a per-slide lifecycle, structural edits through one organize tool, and a present-time completion gate. slides/present is the delivery gate for every mode; for pptx decks it additionally re-validates every XML file before delivery.

Skill files

This skill is a directory of three files. The two reference files live NEXT TO this SKILL.md, in the skill's own install directory — they are part of the skill, not of any deck, and are never found in a deck's project directory:

<skill install dir>/
├── SKILL.md            # this file — model, tools, lifecycle, workflow
├── html-syntax.md      # HTML mode authoring rules — read before writing any <id>.html
└── pptx-xml-syntax.md  # pptx mode rules & procedure — read before writing design.xml or any <id>.xml

Core rules

The manifest is tool-owned. NEVER hand-edit project.json. Slide order, outline, and per-slide state are managed by init_slides, generate_image_slide, organize_slides, and native file writes. For HTML decks author only the registered <id>.html files with the native file tool; for image decks author only through slides/generate_image_slide; for pptx decks author only design.xml and the registered <id>.xml files with the native file tool.
For HTML and pptx decks, page files reach the deck ONLY through the native file write / edit tools — write carries one complete page document per call; edit applies targeted fixes to an already-written page. Every such write/edit triggers the Slides file-edit hook, which is what actually registers the edit: it marks the slide edited, syncs content to the Studio, validates pptx XML, measures HTML height, and (for templated decks) injects the next page's template block. Shell commands (cat, echo, heredoc, sed), Python/Node scripts, or any single call that emits several pages bypass the hook entirely: a page never written through the file tools stays edit_pending and slides/present refuses the deck, while a shell/script change to an already-registered page is never validated, measured, or synced — the deck may keep serving the previous content or later sweep in the raw unchecked file, and for pptx decks slides/present re-validates every file from disk and fails on anything non-canonical. Never append to page files: appending re-registers the page as the concatenated (broken) document.
A session may contain multiple independent decks; each deck is initialized only once. A new slides/init_slides call creates another deck with a new project_id. Use slides/organize_slides for structural changes — never re-init an existing deck.
Interrupted call recovery: verify before re-running. If a Slides call fails with a transport error saying the operation MAY have already completed, do not immediately re-run it — a blind re-init creates a duplicate deck. First run ls /home/ubuntu/manus-slides/: each deck lives in one directory named by its project_id. If the deck's directory already exists, reconnect with slides/attach_slides("manus-resource://manus-slides/deck/<project_id>") and continue from its returned state; re-run slides/init_slides only when no directory for the deck exists, or when attach_slides fails because the Slides service does not know the deck — that means the interrupted init never finished registering remotely, so a fresh init is the correct recovery.
project_id is mandatory for every Slides operation on an existing deck. Persist the exact value returned by init/attach and pass it to every subsequent call for that deck.
Errors over fallbacks. The tools fail loudly on missing, empty, or unknown project_id, unknown slides, out-of-range slide numbers, incomplete reorder sets, and pending slides at present time. Read the error and self-correct; do not work around it.
Templates are id-driven. Only when the task context or the user provides an exact template_id (for example Template: <id> from the Slides New Session scene): call slides/get_template(template_id) once BEFORE slides/init_slides, tag each outline entry with a slide_template_key from the returned page catalog, and pass the same template_id to init_slides. No id — no template step: get_template cannot browse or search templates, and generic style wishes ("use a nice template") belong in style_request, not here.

Per-slide lifecycle

Each slide carries a state:

edit_pending — registered in the outline but not yet authored (the <id>.html / <id>.xml file does not exist until you write it). init_slides and organize_slides add create slides in this state.
edited — the page has been authored (HTML/pptx file written, or image generated). slides/present refuses to deliver while any slide is still edit_pending. In pptx mode edited does NOT mean valid: fix any XML validation issues the write result reports — slides/present re-validates everything and fails until all files pass.

"What's left to do" is always computable from the registered outline. Image-generation results return the deck id and generated image path, and explicitly say when the deck is ready to present; they do not nominate the next page.

Deck model

A deck is a set of per-slide files plus a tool-owned project.json. Choose ONE authoring mode at init via generate_mode and do not mix them; pick by what the user needs. Each mode's authoring rules live in its own reference file — read that file before writing.

HTML mode (default) — hand-authored, self-contained HTML slides with full layout control; best for information-dense, precise, on-brand decks. Author each <id>.html with the native file write tool. Rules: html-syntax.md.
Image mode (generate_mode: "image") — each slide is a full-bleed AI-generated image produced by slides/generate_image_slide: the first page alone to lock the style, then the remaining pages in parallel; best for highly visual or illustrative decks. No native file writes; see the tool below.
PPTX mode (generate_mode: "pptx") — native, editable PowerPoint slides authored as manus-pptx XML; best when the user needs a real .pptx they can open and edit in PowerPoint. Author with the native file write tool. Rules and procedure: pptx-xml-syntax.md.

Use real, verifiable information; never fabricate data, citations, or authoritative claims.

Templated decks (official templates)

slides/get_template(template_id) returns the template's style description plus a per-page catalog {page ID, description}. HTML is intentionally not returned there: each template page's HTML is injected for you page by page — the cover page's template HTML arrives in the init_slides result, and each file write's hook result carries the NEXT pending slide's template HTML.
Read the template page before writing the page. For every page of a templated HTML deck, first read the injected template HTML for that slide's slide_template_key, then author <id>.html against it: the cover's template block is in the slides/init_slides result; each later page's block is in the result of the PREVIOUS page's file write; a page added with slides/organize_slides gets its block in that organize add result (tag every added slide with a valid slide_template_key — see Tools). Never author a templated page from the get_template catalog description alone or from memory of another page. Because injection runs one page ahead in outline order, author templated HTML decks sequentially — one file write at a time, reading each result's template block before writing the next page; the parallel authoring allowed for other decks does not apply. If no template block is available for a pending page (for example after slides/attach_slides in a later session), match the established layout, colors, and fonts of the deck's already-authored pages.
When authoring a templated HTML deck, only replace the content of the injected template page; strictly keep its layout, visual style, color palette, fonts, and special elements like logos. Do not add images where the template has none; only replace images that already exist in the template.
Template asset files are extracted to assets/ inside the deck project directory at init. The injected template HTML may contain relative ./assets/... references; rewrite every retained template asset reference to the corresponding absolute path under the exact project_dir returned by slides/init_slides, and never leave a relative asset path in an authored page.
Image-style templates require generate_mode: "image" and use their reference image as the sole template-style source. init_slides saves it under the deck's references/ directory and returns the exact path; include that absolute path in references for EVERY page. From the second page on, also include the first generated slide image for continuity (two references total).
Decks without a template (deck-stage-basic or no template context) are unaffected by all of the above.

Tools

slides/get_template(template_id) — fetch an official template's style description and page catalog by exact id, once per deck before slides/init_slides. Usage gate: see Core rules.
slides/init_slides(title, outline, generate_mode?) — create a new independent deck and register ALL pages up front. generate_mode is html (default), image, or pptx; image mode always uses gpt-image and init_slides has no model parameter. Pass outline: [{id, title, summary, slide_template_key?}] to register one page per entry (<id>.html, or <id>.xml in pptx mode), each edit_pending; no page files are written at init — for HTML and pptx decks you author each file afterwards with the native file tool, for image decks each page is produced by slides/generate_image_slide. In pptx mode design is a reserved id; write design.xml first (see pptx-xml-syntax.md). Unless the user explicitly asks for more, use at most 12 slides. The result's project_id identifies only this deck; the tool itself does not accept a project_id. For HTML and pptx decks initialized WITHOUT a template, the result also includes a deck-level <design_brief> (design concept, palette and typography tokens, per-slide layout patterns, guardrails): follow it verbatim when authoring every page — in pptx mode encode its color/font tokens as the design.xml variables. A copy is saved at <project_dir>/design.md; it is context, not a slide file — do not read it again, edit it, or register it. The brief is session-local: slides/attach_slides in a later session does not restore it — study the deck's existing pages and stay consistent with their established style instead. If the result instead notes the brief was unavailable, proceed with this skill's default design guidance. Templated decks get no design brief — their design guidance is the injected template block, which always wins.
Native file write / edit tools — the ONLY authoring channel for HTML and pptx decks: write one complete document per call to the exact absolute registered path; use edit for targeted follow-up fixes. Shell commands and Python/Node scripts bypass the file-edit hook (see Core rules), and append is never appropriate for page files. For pptx decks, each .xml write/edit is validated against the manus-pptx schema (see pptx-xml-syntax.md); validation problems come back in the tool result and MUST be fixed before presenting.
slides/generate_image_slide(project_id, slide_id | slide_number, content_prompt, references) — generate or regenerate any registered page of an image deck with fixed gpt-image. Generate page 1 ALONE and wait for its result: it locks the deck's visual style (enforced for a new deck). Then generate ALL remaining pages by issuing one call per page in a single response (parallel tool calls, at most 10 per response; if more pages remain, send the next batch after these return) — the calls run concurrently, out-of-order calls are accepted, and an already generated page may be regenerated. For a templated image deck, include the absolute template reference-image path returned by init_slides on EVERY page; for an untemplated image deck, use references: [] on page 1. On every later page, include page 1's absolute generated_image_path in references for visual continuity (when omitted, the tool falls back to it automatically). References accept 0–2 absolute sandbox PNG/JPEG/WebP paths. Invalid, missing, oversized, upload-failed, or expired references fail the call and are never silently dropped. A failed page does not affect other pages — re-send just that page's call. If a call fails with [INSUFFICIENT_CREDITS], STOP: do not retry and do not generate the remaining pages; tell the user they need more credits.
slides/organize_slides(project_id, operation, …) — structural changes to the identified existing deck. Use this tool, not another init call, to add pages to that deck:
- operation: 'add', slide_data: [{slide_id, page_title, summary, slide_template_key?, position?}] — register new edit_pending slides (1-based position, default append); author each added page afterwards through the deck's authoring path. On a templated deck give every added slide a valid slide_template_key: the add result injects the next pending slide's template HTML, and a keyless page gets no template block. Rejects duplicate ids.
- operation: 'delete', slide_data: [{slide_id}] or [{slide_number}] — remove slides. Errors on unknown slide.
- operation: 'reorder', slide_data: [{slide_id}, ...] — rebuild the order. Requires the COMPLETE active set exactly once (precise error lists Missing / Extra / Duplicate).
slides/write_notes(project_id, notes) — write or update speaker notes for authored slides of the identified deck, notes: [{slide_id | slide_number, note}]. Partial update: slides not listed keep their notes; note: "" clears one. Errors on unknown slides and on slides still edit_pending (author content first). See the Speaker notes section for when and how to write them.
slides/present(project_id, title?) — completion gate + delivery for the identified deck. Errors and lists the pending slides if any slide is still edit_pending; for pptx decks it additionally re-validates design.xml and every <id>.xml and fails with the file list + errors until all pass; otherwise returns its stable base resource_uri. Call this last for each deck.
slides/export(project_id, format, version_id?, output_dir?) — export the deck to pdf/pptx; saves the file into the sandbox and returns its absolute path. Use only when the user explicitly asks for a PDF/PPTX file. Export after slides/present. An in_progress result means conversion continues server-side — retry the same call after ~30s.
slides/attach_slides(resource_uri) — materialize an existing deck by its manus-resource://... URI and return the project_id required for later operations. Attaching it does not replace or select another local deck.

Workflow

Research comes BEFORE slides: gather enough verified content (facts, figures, sources) to fill every planned page before initializing the deck — never start authoring on thin material. If while authoring a page you find it needs a visual element you don't have, search for or generate the image first, then write the page.

Plan one deck's complete outline, then call slides/init_slides({title, outline, generate_mode}) to register every page as edit_pending. Save the returned project_id as, for example, deck_a_id. Templated decks only (exact template_id in context — see Core rules): slides/get_template comes first, and the template's generate mode carries into init_slides.
Author every page following the chosen mode's rules (read its reference file first): HTML — write each <id>.html with the native file write tool (html-syntax.md); pptx — write design.xml, then each <id>.xml with the native file write tool (pptx-xml-syntax.md); image — call slides/generate_image_slide for page 1 alone, then the remaining pages in parallel (out-of-order accepted; see the tool entry below). Before writing a page, think through design, continuity, layout, key content, and canvas fit. HTML and pptx pages are independent files, so you may author several in parallel by issuing multiple native file write calls in one turn — one page per call, and never author through shell commands or scripts (see Core rules). Templated HTML decks stay sequential because each page's template HTML arrives in the previous write's result; read it before writing that page (see Templated decks). For image mode, follow the registered outline rather than relying on each result to nominate the next page.
Call slides/organize_slides({project_id: deck_a_id, operation: 'add' | 'delete' | 'reorder', slide_data}) for any structural change. Adding pages to deck A must use organize with deck_a_id; do not init again.
Call slides/present({project_id: deck_a_id}) — it gates on pending slides (and, for pptx decks, on design.xml + every page passing validation), then returns deck A's resource. Deliver it (see below).
To create deck B in the same session, call slides/init_slides({title, outline}) again, save the new result as deck_b_id, and use that exact ID in every operation on B. Calls for A and B may be interleaved safely.
To continue an existing resource, call slides/attach_slides({resource_uri}), save the returned project_id, then continue with the deck's authoring path (native file writes for HTML and pptx, slides/generate_image_slide for image) plus explicit-ID organize / present calls. Other local decks remain intact.

Speaker notes

Notes are opt-in: do NOT write speaker notes unless the user (or a host message) explicitly asks for them — creating a deck never implies notes. When asked, use slides/write_notes for every request about speaker notes, presenter scripts, or talking points — generating, rewriting, restyling, shortening, or clearing them. This includes host messages like "Generate speaker notes for this presentation" or "Generate speaker notes for page N" sent by the studio's generate button (page N is 1-based, matching slide_number).

Notes attach to authored slides only — author a slide's content first, then write its note based on that actual content. Notes save live into the studio speaker-notes panel and presenter view and are included in PPTX exports; no re-present is needed for notes to appear.
Regenerate, never refuse: when the user asks to (re)generate notes, always rewrite and replace the requested slides' notes. Treat an existing note as a draft — keep its strong lines, tighten the rest. Current notes are echoed in slides/write_notes and slides/attach_slides results.
Ground every note ONLY in that slide's actual content and the deck outline. Never fabricate data, quotes, or visuals; explain what a chart or image means instead of describing it.

Default writing style (apply the user's own style/tone/length instructions when given):

Natural speech for delivery, not formal prose: contractions, "you/we", active voice, concrete verbs; vary sentence length for rhythm and keep every sentence under 25 words.
Per slide: open with a 1–2 sentence hook framing the key message; deliver 2–3 crisp points that interpret the content (insights over description); optionally add one connecting sentence from the previous slide and a transition toward the next (skip on the first/last slide).
Plain text only — no Markdown, bullets, or headings. At most 200 words per slide. Write in the user's language.
Never use meta or boilerplate openers like "This slide shows…", "As you can see…", "Today we'll…", "In this presentation…".

Delivery contract (REQUIRED — read before finishing)

The user-facing deliverable for a Slides task is the resource, not images. slides/present returns the deck's stable base resource_uri like manus-resource://manus-slides/deck/<project_id> so the deck always opens the latest version.

Your final message MUST link every delivered deck as a Markdown link — one [<deck title>](manus-resource://...) per deck, using each slides/present result's resource_uri verbatim as the href. Always use Markdown-link form; never paste a bare manus-resource://... URI as plain text. If you omit a link, old clients do not receive the Slides attachment.
Deliver exactly one resource URI per deck. A short completion sentence plus one link per deck is enough.

Boundaries

Structural changes flow through Slides tools; page content flows through native file write/edit calls (HTML: <id>.html; pptx: design.xml and <id>.xml) or, for image decks, only through slides/generate_image_slide — never through shell commands or scripts.
Widget actions such as refresh are host/UI actions; do not describe them as model-visible deck editing tools.
Do NOT hand-edit project.json. For HTML decks write only registered slide HTML paths with the native file tool; for pptx decks write only design.xml and registered slide XML paths; for image decks never write slide files by hand; use slides/organize_slides for add/delete/reorder.

slides

Files3

SKILL.mdskills/slides/SKILL.md