Skip to main content Accueil Créateurs akillness jeo-skills presentation-builder
presentation-builder Build real deck artifacts when the user needs editable slides, not just prose: investor decks, roadmap/QBR decks, launch decks, architecture/demo decks, workshop/training decks, and game pitch or milestone decks. Use when the job is to choose one deck mode, one smallest useful artifact packet, and one honest handoff surface (HTML review, PPTX, PDF, Google Slides, or Figma Slides). Triggers on: presentation, slide deck, slides, pitch deck, roadmap deck, investor deck, launch deck, architecture review deck, demo deck, workshop slides, keynote, board deck, QBR deck, and game pitch deck. Route long-form docs to `technical-writing`, end-user tutorials to `technical-writing`, research manuscripts to `research-paper-writing`, and broad marketing planning to `marketing-automation`.
Aller à l'installation Skills Marketplace Découvrez et explorez les compétences IA créées par la communauté.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Afficher les détails du prompt Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/akillness/jeo-skills --skill presentation-builderLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Télécharger Zip Téléchargement... Plus depuis ce dépôt Drive Godogen (htdt/godogen), the MIT-licensed publish-time generator that turns a game description into an autonomous Claude Code or Codex build for Godot 4 C#, Bevy Rust, or Babylon.js TypeScript. Route one request to one mode: preflight the toolchain and API keys; publish a fresh game repository or safely refresh a matching existing runtime with `./publish.sh --engine ...`; run the build and prove it from the live game or a 15-20s recording; budget paid Gemini, Grok, and Tripo3D asset generation; apply engine-specific build and capture rules; troubleshoot rendering and capture failures; or contribute through the issue-first upstream process. Use when the user wants an agent to build a playable game end to end with Godogen. Triggers on: godogen, htdt/godogen, publish.sh --engine, autonomous game development, Godot C# agent build, Bevy agent build, Babylon.js agent game, asset-gen, Tripo3D rig, proof video.
Install, route, and operate zenstory-ai/drama-skills, the MIT-licensed 10-skill creator-first suite for Chinese short dramas and motion comics. Use when the user wants to import or troubleshoot the suite; initialize or resume a filesystem project; analyze a novel; develop an adaptation; write episodes; build visual assets; produce image prompts, storyboards, or video prompts; review a project; open its local Dashboard; or run confirm-gated image, video, TTS, or music production. Route each request to the correct `short-drama-*` owner while preserving the five-document episode contract. Triggers on: drama-skills, zenstory-ai/drama-skills, short-drama, Chinese short drama, motion comic, creator-first drama workflow, 剧本, 视觉设定, 分镜, 图片提示词, 视频提示词. Route generic programmable-video work to `video-production`, webtoon panel production to `webtoon-harness`, and the OpenStory codebase to `openstory`.
Drive Mole (`mo`), tw93's GPL-3.0 macOS maintenance CLI that cleans caches and app leftovers, uninstalls apps with their remnants, purges rebuildable project artifacts, removes downloaded installers, explores disk usage, runs bounded system optimization, and reports live health. Routes one request to one mode: run a command safely (`--dry-run` first, the user runs the destructive step), consume the JSON/NDJSON agent surfaces (`mo analyze --json`, `mo status --json` / `--watch`, `mo history --json`, `~/.config/mole/clean-list.txt`), install/update/remove on the right channel, configure whitelists and scan paths, troubleshoot, or contribute to the repo. Use when a user wants to free Mac disk space or fully uninstall a Mac app. Triggers on: mole, `mo clean`, `mo uninstall`, `mo analyze`, `mo purge`, `mo status`, tw93/Mole, mole.fit, clean my Mac, what is eating my disk, CleanMyMac / AppCleaner / DaisyDisk alternative, brew install mole.
Métiers associés SOC
Basé sur la classification professionnelle SOC
Explorateur de fichiers
7 fichiers name presentation-builder description Build real deck artifacts when the user needs editable slides, not just prose: investor decks, roadmap/QBR decks, launch decks, architecture/demo decks, workshop/training decks, and game pitch or milestone decks. Use when the job is to choose one deck mode, one smallest useful artifact packet, and one honest handoff surface (HTML review, PPTX, PDF, Google Slides, or Figma Slides). Triggers on: presentation, slide deck, slides, pitch deck, roadmap deck, investor deck, launch deck, architecture review deck, demo deck, workshop slides, keynote, board deck, QBR deck, and game pitch deck. Route long-form docs to `technical-writing`, end-user tutorials to `technical-writing`, research manuscripts to `research-paper-writing`, and broad marketing planning to `marketing-automation`.
allowed-tools Read Write Edit Glob Grep compatibility Best when the environment can run `slides-grab` with Node.js 18+ and Chromium. The skill assumes an HTML-first editable deck workflow with browser review, then export or downstream cleanup in PPTX/PDF/Slides surfaces after approval.
license MIT metadata {"tags":"presentation, slides-grab, pitch-deck, roadmap-deck, investor-deck, demo-deck, pptx, pdf, html-slides, storytelling","platforms":"Claude, ChatGPT, Gemini, Codex","version":"2.1.0","modernization":"2026-04-15T00:00:00.000Z","hardening":"2026-04-18T00:00:00.000Z"}
Presentation Builder
Use this skill when the deliverable is a deck artifact people will review, present, or hand off as slides , not just an outline or narrative document.
presentation-builder is the documentation/publishing-cluster anchor for:
investor, fundraising, board, and executive decks
roadmap, QBR, status, and decision-review decks
launch, GTM, and sales-enablement decks
architecture walkthroughs, demo decks, and technical presentations
workshop, training, and keynote decks
game pitch, publisher, and milestone-update decks
Read these support docs before choosing the workflow:
When to use this skill
The user needs an actual slide deck, not just bullets or a memo.
The workflow needs slide planning, visual iteration, and deck-specific evidence.
The work must survive browser review before export or downstream office/design-tool cleanup.
The output needs an editable or shareable slide surface such as HTML viewer, PPTX, PDF, Google Slides, or Figma Slides.
The request names a deck artifact directly or clearly implies a presentation deliverable for review, pitching, enablement, or decision-making.
When not to use this skill
The main job is a technical spec, ADR, runbook, migration guide, or internal implementation document → use technical-writingThe main job is an end-user tutorial, onboarding guide, FAQ, or screenshot-heavy help-center flow → use technical-writingThe main job is a research paper, rebuttal, or academic manuscript → use research-paper-writingThe main job is broad launch planning, campaign strategy, positioning, or messaging without a concrete deck artifact → use marketing-automationThe main job is only an outline, memo, or planning artifact and no deck file is actually needed → use the relevant planning or writing skill first
Instructions
Step 1: Classify one deck mode, one artifact packet, and one handoff surface Normalize the request before drafting.
presentation_builder_mode:
deck_mode: investor | roadmap-review | launch-gtm | architecture-demo | workshop-training | game-pitch | other
audience: executives | investors | customers | internal-team | mixed | unknown
source_material: brief | doc | spreadsheet | screenshots | charts | prototype | mixed | unknown
review_need: outline-approval | visual-approval | export-ready | mixed
artifact_packet: outline-brief | storyboard | review-ready-html | export-handoff | sync-packet | unknown
handoff_surface: html-viewer | pptx | pdf | google-slides | figma-slides | mixed | unknown
Choose exactly one primary deck_mode for the run:
investor → fundraising, board, strategic pitch, or executive narrative deckroadmap-review → roadmap, QBR, planning, KPI, status, or decision-review decklaunch-gtm → launch briefing, sales-enablement, product narrative, or GTM deckarchitecture-demo → technical walkthrough, architecture review, developer talk, or demo deckworkshop-training → workshop, training, keynote, or enablement deckgame-pitch → publisher pitch, game concept, milestone update, or studio BD deck
Step 2: Lock the promise, evidence, and downstream editor Before generating slides, answer these three questions:
What should the audience understand, approve, or decide by the end? What evidence must appear on the slides? Screenshots, charts, metrics, citations, links, footage, or product visuals.Where will the final cleanup happen? Browser-only viewer, PPTX, PDF, Google Slides, or Figma Slides. Do not pretend the handoff surface is irrelevant. Real deck workflows often start in HTML or Markdown but still end with office/design-tool cleanup.
Step 3: Route out non-deck work early Use the smallest honest boundary:
If the request is mainly about... Use technical specs, rollout docs, ADRs, migration details technical-writingtutorials, help docs, onboarding, screenshot walkthroughs technical-writingacademic papers, rebuttals, manuscript sections research-paper-writingmessaging, launch strategy, campaigns, content calendars marketing-automationa reviewable or handoff-ready deck artifact presentation-builder
Many “make slides” requests are really document or messaging requests. Confirm the artifact before building slides.
Step 4: Choose the smallest artifact packet Default to the smallest output that makes progress:
outline-brief → slide-by-slide outline with takeaway + evidence + risk notesstoryboard → stronger slide sequence and rough content plan before visual polishreview-ready-html → browser-reviewable deck source with visual iteration still openexport-handoff → approved deck plus explicit PPTX/PDF/Slides handoff statussync-packet → deck plus short list of downstream artifacts or cleanup follow-ups Do not jump straight to exported binaries when an outline or storyboard is the real next step.
Step 5: Build the deck from a stable source workspace Default to a dedicated workspace such as:
decks/<deck-name>/
slide-outline.md
slide-01-cover.html
slide-02-...
assets/
keep the editable source in the deck workspace
keep raw evidence/assets close to the deck
revise the source slides, not the exported PPTX/PDF
keep spreadsheet/chart dependencies explicit if numbers may refresh later
treat PowerPoint / Google Slides / Figma as last-mile surfaces, not the hidden source of truth
Step 6: Use the mode packet, then review visually After creating or editing slides:
slides-grab build-viewer --slides-dir decks/<deck-name>
slides-grab validate --slides-dir decks/<deck-name>
slides-grab edit --slides-dir decks/<deck-name>
every slide should have one clear takeaway
screenshots, charts, and footage must remain legible
unsupported claims or placeholder visuals must be called out
if async review matters, plan for PDF readability, not only live presentation flow
if the deck will be edited outside the browser workflow, note the likely cleanup surface explicitly
Step 7: Export or hand off honestly Only export after the chosen packet is ready.
slides-grab convert --slides-dir decks/<deck-name> --output decks/<deck-name>.pptx
slides-grab pdf --slides-dir decks/<deck-name> --output decks/<deck-name>.pdf
source workspace path
artifact packet selected
validation status
review status (outline approved / visually approved / export-ready)
handoff surface and likely cleanup location
output file paths
remaining manual-polish risks such as fonts, layout drift, chart refresh, or office-tool cleanup
Step 8: Return the deck status in the right shape Preferred response structure:
deck mode + audience
artifact packet selected
source workspace path
evidence used and review findings
export / handoff status and remaining risks
Core commands slides-grab edit
slides-grab build-viewer
slides-grab validate
slides-grab convert
slides-grab pdf
slides-grab list-templates
slides-grab list-themes
All commands support --slides-dir <path>.
Examples
Example 1: Investor deck with explicit PPTX handoff Turn this product brief into a 10-slide investor deck. Show me the outline first, then generate the deck in decks/series-a and hand off an editable PPTX after visual review.
Example 2: Architecture review deck for async review Build an 8-slide architecture review deck for our browser automation service. Use screenshots, flow diagrams, and one slide on failure handling. I need a reviewable HTML deck first and a PDF for async review.
Example 3: Launch planning that should route out Help me figure out the launch messaging, channel plan, and owners for next month's release.
Good direction: route to marketing-automation unless the user also needs a concrete deck artifact.
Best practices
Treat deck work as a narrative + evidence + handoff problem, not just a styling task.
Pick one deck mode, one packet, and one last-mile surface first.
Prefer a stable HTML source and regenerate exports instead of editing binaries directly.
Keep docs, spreadsheets, screenshots, and other upstream evidence explicit.
Call out where manual cleanup is likely instead of hiding fidelity limits.
Use the smallest packet that keeps progress honest.
Keep route-outs sharp: many “slides” requests are really docs, research, or marketing work.
References
Upstream tool: https://github.com/vkehfdl1/slides-grab
Figma Slides: https://www.figma.com/slides/
Marp: https://marp.app/
Slidev: https://sli.dev/
Google Slides: https://workspace.google.com/products/slides/
Microsoft PowerPoint: https://support.microsoft.com/en-us/powerpoint
