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---5
6## When to Use
7
8User 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.
9
10## Architecture
11
12Projects and styles stored in `~/slides/`. See `memory-template.md` for setup.
13
14```
15~/slides/
16├── memory.md # HOT: active projects, preferred tools
17├── styles/ # Brand guidelines per client/project
18│ └── {name}.md # Colors, fonts, templates
19├── projects/ # Project-specific context
20│ └── {name}/
21│ ├── context.md # Audience, purpose, constraints
22│ └── versions.md # Version history
23└── templates/ # Approved slide structures
24 └── {type}.md # pitch, lesson, report, etc.
25```
26
27## Quick Reference
28
29| 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` |
35
36## Data Storage
37
38All data stored in `~/slides/`. Create on first use:
39```bash
40mkdir -p ~/slides/{styles,projects,templates}
41```
42
43## Scope
44
45This skill ONLY:
46- Creates/edits presentations via declared tools
47- Stores style preferences in local files (`~/slides/`)
48- Reads user's templates and brand guidelines
49- Generates visual output for validation
50
51This skill NEVER:
52- Accesses email, calendar, or contacts
53- Makes network requests without user action
54- Reads files outside `~/slides/` and project paths
55- Sends presentations to external services automatically
56
57## Self-Modification
58
59This skill NEVER modifies its own SKILL.md.
60Learned styles stored in `~/slides/styles/`.
61Project context stored in `~/slides/projects/`.
62
63## Core Rules
64
65### 1. Identify Context First
66Before 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 exists
71
72### 2. Tool Selection by Output
73| 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 |
79
80### 3. Visual Consistency Always
81- Load user's style before generating
82- If no style: ask for brand colors, fonts, or use neutral defaults
83- Same typography hierarchy across ALL slides
84- Maximum 3-4 colors per deck
85- See `design.md` for detailed rules
86
87### 4. Content Density Limits
88- Maximum 6 bullet points per slide
89- Maximum 6 words per bullet (6x6 rule)
90- One idea per slide
91- If content overflows → split into multiple slides
92
93### 5. Validate Before Delivery
94- Generate preview/screenshot of key slides
95- Check: readable text (24pt+ for body), proper contrast, alignment
96- For important decks: show 2-3 slides to user before completing all
97
98### 6. Learn User Preferences
99| 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}/` |
105
106### 7. Version Management
107- Each significant revision → log in `projects/{name}/versions.md`
108- Track: date, changes, audience variant
109- Support quick comparison: "What changed since v2?"
110
111## Common Traps
112
113- **python-pptx units** — Always use `Inches()`, `Pt()`, `Emu()` from `pptx.util`, never raw numbers
114- **Marp frontmatter** — Must start with `marp: true` in YAML
115- **reveal.js separators** — Use `---` for horizontal, `--` for vertical slides
116- **Slidev syntax** — Different from reveal.js; check docs for each framework
117- **Google Slides API quotas** — Batch updates to avoid rate limits
118- **Image sizing** — Always specify dimensions; auto-fit often fails
119- **Font availability** — Stick to system fonts unless embedding confirmed