When to Use
User needs presentation slides created, edited, or automated. Agent handles tool selection (python-pptx, Google Slides API, reveal.js, Marp, Slidev), applies user's style preferences, generates visually consistent decks, and validates output.
Architecture
Projects and styles stored in ~/slides/. See memory-template.md for setup.
~/slides/
├── memory.md # HOT: active projects, preferred tools
├── styles/ # Brand guidelines per client/project
│ └── {name}.md # Colors, fonts, templates
├── projects/ # Project-specific context
│ └── {name}/
│ ├── context.md # Audience, purpose, constraints
│ └── versions.md # Version history
└── templates/ # Approved slide structures
└── {type}.md # pitch, lesson, report, etc.
Quick Reference
| Topic |
File |
| Memory setup |
memory-template.md |
| Programmatic tools |
tools.md |
| Visual design rules |
design.md |
| Deck structures by type |
formats.md |
Data Storage
All data stored in ~/slides/. Create on first use:
mkdir -p ~/slides/{styles,projects,templates}
Scope
This skill ONLY:
- Creates/edits presentations via declared tools
- Stores style preferences in local files (
~/slides/)
- Reads user's templates and brand guidelines
- Generates visual output for validation
This skill NEVER:
- Accesses email, calendar, or contacts
- Makes network requests without user action
- Reads files outside
~/slides/ and project paths
- Sends presentations to external services automatically
Self-Modification
This skill NEVER modifies its own SKILL.md.
Learned styles stored in ~/slides/styles/.
Project context stored in ~/slides/projects/.
Core Rules
1. Identify Context First
Before generating slides:
- Purpose: Pitch, lesson, report, demo?
- Audience: Investors, students, executives, clients?
- Tool: PowerPoint, Google Slides, web-based (reveal.js)?
- Load relevant style from
~/slides/styles/ if exists
2. Tool Selection by Output
| Need |
Tool |
When to use |
| .pptx file |
python-pptx |
PowerPoint required, offline |
| Google Slides |
Google Slides API |
Collaboration, cloud |
| Web presentation |
reveal.js, Slidev, Marp |
Dev talks, code-heavy |
| Quick PDF |
Marp |
Simple deck, fast export |
3. Visual Consistency Always
- Load user's style before generating
- If no style: ask for brand colors, fonts, or use neutral defaults
- Same typography hierarchy across ALL slides
- Maximum 3-4 colors per deck
- See
design.md for detailed rules
4. Content Density Limits
- Maximum 6 bullet points per slide
- Maximum 6 words per bullet (6x6 rule)
- One idea per slide
- If content overflows → split into multiple slides
5. Validate Before Delivery
- Generate preview/screenshot of key slides
- Check: readable text (24pt+ for body), proper contrast, alignment
- For important decks: show 2-3 slides to user before completing all
6. Learn User Preferences
| Event |
Action |
| User provides style guide |
Save to ~/slides/styles/{name}.md |
| User corrects design choice |
Update style file |
| User approves template |
Save to ~/slides/templates/ |
| New project started |
Create ~/slides/projects/{name}/ |
7. Version Management
- Each significant revision → log in
projects/{name}/versions.md
- Track: date, changes, audience variant
- Support quick comparison: "What changed since v2?"
Common Traps
- python-pptx units — Always use
Inches(), Pt(), Emu() from pptx.util, never raw numbers
- Marp frontmatter — Must start with
marp: true in YAML
- reveal.js separators — Use
--- for horizontal, -- for vertical slides
- Slidev syntax — Different from reveal.js; check docs for each framework
- Google Slides API quotas — Batch updates to avoid rate limits
- Image sizing — Always specify dimensions; auto-fit often fails
- Font availability — Stick to system fonts unless embedding confirmed
1---2name: slides3description: Create, edit, and automate presentations with programmatic tools, visual consistency, and project-based learning of user style preferences.4---56## When to Use78User needs presentation slides created, edited, or automated. Agent handles tool selection (python-pptx, Google Slides API, reveal.js, Marp, Slidev), applies user's style preferences, generates visually consistent decks, and validates output.910## Architecture1112Projects and styles stored in `~/slides/`. See `memory-template.md` for setup.1314```15~/slides/16├── memory.md # HOT: active projects, preferred tools17├── styles/ # Brand guidelines per client/project18│ └── {name}.md # Colors, fonts, templates19├── projects/ # Project-specific context20│ └── {name}/21│ ├── context.md # Audience, purpose, constraints22│ └── versions.md # Version history23└── templates/ # Approved slide structures24 └── {type}.md # pitch, lesson, report, etc.25```2627## Quick Reference2829| Topic | File |30|-------|------|31| Memory setup | `memory-template.md` |32| Programmatic tools | `tools.md` |33| Visual design rules | `design.md` |34| Deck structures by type | `formats.md` |3536## Data Storage3738All data stored in `~/slides/`. Create on first use:39```bash40mkdir -p ~/slides/{styles,projects,templates}41```4243## Scope4445This skill ONLY:46- Creates/edits presentations via declared tools47- Stores style preferences in local files (`~/slides/`)48- Reads user's templates and brand guidelines49- Generates visual output for validation5051This skill NEVER:52- Accesses email, calendar, or contacts53- Makes network requests without user action54- Reads files outside `~/slides/` and project paths55- Sends presentations to external services automatically5657## Self-Modification5859This skill NEVER modifies its own SKILL.md.60Learned styles stored in `~/slides/styles/`.61Project context stored in `~/slides/projects/`.6263## Core Rules6465### 1. Identify Context First66Before generating slides:67- **Purpose**: Pitch, lesson, report, demo?68- **Audience**: Investors, students, executives, clients?69- **Tool**: PowerPoint, Google Slides, web-based (reveal.js)?70- Load relevant style from `~/slides/styles/` if exists7172### 2. Tool Selection by Output73| Need | Tool | When to use |74|------|------|-------------|75| .pptx file | `python-pptx` | PowerPoint required, offline |76| Google Slides | `Google Slides API` | Collaboration, cloud |77| Web presentation | `reveal.js`, `Slidev`, `Marp` | Dev talks, code-heavy |78| Quick PDF | `Marp` | Simple deck, fast export |7980### 3. Visual Consistency Always81- Load user's style before generating82- If no style: ask for brand colors, fonts, or use neutral defaults83- Same typography hierarchy across ALL slides84- Maximum 3-4 colors per deck85- See `design.md` for detailed rules8687### 4. Content Density Limits88- Maximum 6 bullet points per slide89- Maximum 6 words per bullet (6x6 rule)90- One idea per slide91- If content overflows → split into multiple slides9293### 5. Validate Before Delivery94- Generate preview/screenshot of key slides95- Check: readable text (24pt+ for body), proper contrast, alignment96- For important decks: show 2-3 slides to user before completing all9798### 6. Learn User Preferences99| Event | Action |100|-------|--------|101| User provides style guide | Save to `~/slides/styles/{name}.md` |102| User corrects design choice | Update style file |103| User approves template | Save to `~/slides/templates/` |104| New project started | Create `~/slides/projects/{name}/` |105106### 7. Version Management107- Each significant revision → log in `projects/{name}/versions.md`108- Track: date, changes, audience variant109- Support quick comparison: "What changed since v2?"110111## Common Traps112113- **python-pptx units** — Always use `Inches()`, `Pt()`, `Emu()` from `pptx.util`, never raw numbers114- **Marp frontmatter** — Must start with `marp: true` in YAML115- **reveal.js separators** — Use `---` for horizontal, `--` for vertical slides116- **Slidev syntax** — Different from reveal.js; check docs for each framework117- **Google Slides API quotas** — Batch updates to avoid rate limits118- **Image sizing** — Always specify dimensions; auto-fit often fails119- **Font availability** — Stick to system fonts unless embedding confirmed