skills/presentation-creator/SKILL.md
Creates bold, minimal, dark-first presentations with structured narrative arcs, punchy slide copy, high-contrast visual design, and conversational speaker notes. Covers live talks, async/recorded decks, and 10-slide investor pitch decks. Use when creating a presentation, structuring a deck, writing slides, building a pitch deck for investors, or asking "outline a presentation about...", "write slides for...", "design a deck for...", or "turn this doc into a deck". For long-form articles use blog-post; for marketing copy outside slides use copywriting; for product UI design systems use ui-design.
npx skillsauth add mblode/agent-skills presentation-creatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Bold, minimal, dark-first slide decks: narrative arc to final QA.
blog-post), marketing copy outside slides (use copywriting), or general visual systems for product UI (use ui-design).Track this checklist:
Presentation progress:
- [ ] Step 1: Gather context (audience, setting, format: live / async / pitch)
- [ ] Step 2: Outline narrative arc and slide sequence (references/outline-structure.md)
- [ ] Step 3: Write slide copy (references/writing-slides.md; pitch decks: references/pitch-decks.md instead)
- [ ] Step 4: Design visual layout and composition (references/visual-design.md)
- [ ] Step 5: Write speaker notes (references/speaker-notes.md); skip for pitch decks
- [ ] Step 6: QA pass, output the slide-by-slide review table
Establish three things (ask if not provided):
Route by format:
writing-slides.md for Step 3: do not load writing-slides.md on this path, its presented-deck copy limits contradict it. Skip Step 5 (no presenter); Steps 4 and 6 still apply.Read each step's reference when you reach it:
| Step | Reference | Covers | |------|-----------|--------| | 2. Outline | references/outline-structure.md | Narrative flow, 12 slide types, section colors, outline output format | | 3. Write | references/writing-slides.md, replaced by references/pitch-decks.md on the pitch path | Headline patterns, body text rules, copy per slide type, before/after examples | | 4. Design | references/visual-design.md | Typography scale, layout patterns, slide-type → layout mapping, visual elements | | 5. Notes | references/speaker-notes.md | Per-slide note structure, delivery cues, notes by slide type |
Review every slide and output a table. This is the deliverable that proves the deck is done, not a "looks good" sign-off:
| # | Slide | 3-sec test | One message | Layout | Section color |
|---|-------|-----------|-------------|--------|---------------|
| 1 | Title | pass | pass | full statement | teal |
Deck-level checks below the table:
Fix every flagged row and re-output the table before handing over.
Before: "An Overview of Our Q3 Performance Metrics and Results"
After: "Q3: Revenue Up 40%. Here's How."
blog-post: long-form articles and tutorials; use when the output is prose, not slidescopywriting: landing pages, CTAs, marketing copy outside a deckui-design: visual systems for product UI and landing pages; presentation visual rules live in references/visual-design.md insteaddevelopment
Fans out four concurrent review agents over the current diff, then APPLIES fixes directly to the working tree and verifies the build. Mutates code; it does not produce a report. Covers reuse (duplicate logic, hand-rolled stdlib, reinvented platform features), quality (hacky patterns, React/TypeScript hygiene, over-memoisation, exhaustive-deps, `any`, dead code, `CLAUDE.md`/`AGENTS.md` violations), efficiency (unnecessary work, missed concurrency, hot-path bloat), and test discipline (bug fixes without a repro test, useless tests to delete, missing tests only when they prevent a named failure). Use when the user says "tidy this up", "simplify", "clean up this diff", "polish my changes", "check for duplication", or "any reuse opportunities?", i.e. when the intent is to have the changes made automatically. For a read-only report that lists findings without touching files, use `pr-reviewer` instead. This skill edits code; for the PR's title, description, or commit history, use `pr-creator`.
development
Decides what an interface should do before UI is built or audited: interaction choice, action scope and consequence, reachable states, resilience, and accessibility as task completion. Works from a brief, spec, mockup, intent, or existing UI. Use when asked "is this the right interaction", "design the flow", "what control should this use", "what should this action affect", "which states should this have", "make this resilient", or "what breaks here". For building or styling use ui-design; for built-code audits use ui-audit; for copy wording use copywriting.
development
Builds and stress-tests implementation plans in two modes. Create mode scans code and docs, asks one question at a time with a recommended answer, runs a blindspot pass when the user is new to the area, then writes a plan file. Review mode scores completeness, feasibility, scope, testability, risk, and assumptions, verifies checkable claims, and writes resolutions back until every dimension reaches 5/5. Use when asked to "create a plan", "plan this feature", "I want to build X", "grill me", "think this through", "blindspot pass", "unknown unknowns", "this is new to me", "review my plan", "rubber duck this", "stress test this plan", "is this plan ready", "get this plan to 5/5", "what am I missing", "verify this claim", "prove this plan", "fact-check this plan", or when the user explicitly wants a plan artifact before implementation. For code review use pr-reviewer; for architecture briefs use define-architecture.
tools
Audits the smallest relevant developer-facing surface of a library, CLI, SDK, or npm package across API contracts, errors, CLI behavior, public types, onboarding, and config. Uses candidate-first rule loading, bounded local evidence, and compact root-cause findings. Use when asked to "audit my CLI", "make this CLI agent-friendly", "is this API ergonomic", "review the developer experience", "improve these errors", "simplify first run", or "review my SDK". For end-user UI use ui-audit, for agentic-app trust use ax-audit, for docs prose use docs-writing, for README work use readme-creator, and for repo architecture use define-architecture. Inside a product that also ships a UI, this is the skill for the developer-facing half, so pick it when the complaint is about an import, command, error string, exported type, or config rather than a screen.