DeepTutor pptx Skill
Read, create, and edit PowerPoint decks with python-pptx — build slides from an outline, extract content, modify tables and charts, swap images, and export to PDF.
The skill declares only sandbox: shell, executes python-pptx code via exec to read/write pptx files; no network exfiltration, no credential access, no destructive defaults; it instructs honest reporting when export tools are missing rather than installing them, and the zip-surgery example uses defusedxml. Deductions: subprocess calls to soffice/pdftoppm run external processes without explicit user confirmation, and rollback behavior (overwriting existing files) is not documented.
Internally self-consistent with clear code paths and strong failure-feedback design: missing soffice/pdftoppm is reported honestly, outputs are re-opened to catch corruption, template leftovers are checked, and image replacement warns about encoding mismatches. Deducted for no committed runnable tests or boundary-case inventory specific to this skill path; static review caps this at 10.
Trigger conditions are precise (any pptx/ppt input/output or slide mention), boundaries are clear (.ppt unsupported by python-pptx, export requires LibreOffice, admits when visual inspection is unavailable). Deductions: no mention of Chinese font/layout rendering pitfalls, and export fails where LibreOffice/pdftoppm is unavailable with no alternative path offered.
Frontmatter includes name/description/tags/requires; docs are well layered (read/create/edit/export/OOXML escape hatch/verify); Apache-2.0 license is clear; python-pptx dependency is pinned in pyproject.toml (>=1.0.0). Deductions: the skill itself has no version or changelog, no FAQ, and skill-level maintenance ownership/update path is only inferable from the repository level.
Code examples are complete and directly usable across read/create/edit/charts/export/zip surgery, with strong self-verification steps; marginal value over hand-writing OOXML is clear. Deducted for lack of verifiable representative output evidence (samples or test results) and because design guidance depends on model execution; static review caps this at 7.
Claims (python-pptx preinstalled, default template layout indices) are partially checkable at source level (dependency confirmed in pyproject), and facts are mostly separated from inference. Deducted for absence of third-party execution evidence, committed tests covering the skill's key paths, or multi-source corroboration.
- This is a static source review; no code was executed. Claims such as 'python-pptx preinstalled' and default template layout indices are unverified at runtime.
- PDF/image export depends on host-side LibreOffice and pdftoppm; when absent, export is unavailable and the skill will not install them — confirm the environment beforehand.
- The skill runs Python via exec and spawns external processes via subprocess, overwriting output files; watch for same-named files in the workspace.
- The repository publisher is not verified by the FollowSkills registry and is treated as unknown; the skill has no independent version number or changelog.
- No specific guidance covers rendering of Chinese content (fonts, wrapping, overflow); manually inspect decks containing Chinese after generation.
What does this skill do, and when should you use it?
This is the PowerPoint-handling skill inside DeepTutor's built-in skill collection, located at deeptutor/skills/builtin/pptx/SKILL.md. It teaches the model to operate on .pptx files (ZIPs of XML parts) via the preinstalled python-pptx library: extracting slide text and speaker notes, building decks from outlines, run-level edits that preserve formatting, in-place image replacement, generating tables and charts, and exporting to PDF/images through LibreOffice. Raw OOXML surgery is a documented last resort for features the library can't express. It requires a shell sandbox to run Python code, which is on by default in every DeepTutor deployment shape.
Read: iterates slides, placeholders, shapes, table cells, and notes to output structured text. Create: builds decks from an outline against a template or default layouts, writing titles, bullets, text boxes, and pictures. Edit: replaces text at the run level to keep inline formatting, deletes surplus shapes, swaps image-part bytes in place, and generates tables and clustered-column charts. Design: applies explicit rules for palette, layout variety, and type scale, then demands a post-export inspection for overflow and overlap. Export: runs soffice --headless to convert to PDF and pdftoppm to JPEG for visual review; legacy .ppt must be converted via soffice first. Fallback: for features python-pptx can't do (exact-fidelity duplication, gradient fills), it edits OOXML directly with lxml or zipfile, listing critical invariants around [Content_Types].xml, relationships, and unique IDs. Before finishing, it reopens the output and asserts slide count and key text to catch corruption.
- Teachers and corporate users who need to batch-generate slide decks for weekly reports, lectures, or training materials from a Markdown-style outline
- Content teams archiving or indexing large numbers of existing decks who need slide text and speaker notes extracted
- Template-filling workflows: replacing {{NAME}}-style placeholder text across a .pptx template and swapping a logo image in place
- Analysts who need data tables and clustered column charts generated directly on slides
- Users exporting decks to PDF or per-slide images for review, publishing, or viewing without PowerPoint
- Anyone receiving legacy .ppt files that must be converted to editable .pptx (requires LibreOffice locally)
What are this skill's strengths and limitations?
- Highly specific instructions with complete runnable code samples covering read, create, edit, design, export, and OOXML fallback
- Documents easy-to-miss pitfalls: run-level editing to preserve formatting, same-encoding image replacement, and OOXML corruption invariants
- Built-in verification: reopen the output to assert structure, and inspect rendered slides for overflow/overlap before declaring done
- Honest about failure modes: reports missing soffice instead of faking a successful export
- PDF/image export and .ppt conversion depend on LibreOffice; functionality degrades when it's absent
- python-pptx cannot open legacy binary .ppt; conversion is mandatory
- Visual quality depends on how well the model executes the design guidance; wrong image-encoding bytes can corrupt the file
- No standalone test suite or cross-platform validation evidence for this skill is provided in the source
How do you install this skill?
The skill ships bundled with DeepTutor and needs no separate installation. Install DeepTutor itself: pip install -U deeptutor, then deeptutor init and deeptutor start; or clone https://github.com/HKUDS/DeepTutor.git from source and pip install -e .. The skill file lives at deeptutor/skills/builtin/pptx/SKILL.md in the repo. python-pptx is preinstalled; PDF/image export requires LibreOffice (soffice) on the system. Steps for using it as a standalone Agent Skill in other clients are not documented in the source material.
How do you use this skill?
The skill declares requires: sandbox: shell; the model sends complete Python source through the exec tool. Trigger: whenever a .pptx or .ppt file is an input or output, or the user mentions a deck, slides, or a presentation. Example prompts: "Generate a 5-slide .pptx from this outline", "Extract the title and notes from every slide of deck.pptx", "Replace {{NAME}} in the template with Frank and swap the slide-1 logo for new.png". After generation the skill requires reopening the file to verify slide count and key text; for visual checks it exports to PDF/images first. If soffice is missing, export is skipped and honestly reported rather than installed on the fly.
How does this skill compare with similar options?
Compared with having a model emit binary files or hand-write OOXML, this skill routes structure through python-pptx and drops to ZIP surgery only when necessary, sharply reducing file-corruption risk. DeepTutor's sibling office skills (docx, pdf, xlsx) follow the same pattern of model-written Python executed in a sandbox — they are family, not competitors.