Skip to main content

codexkit-presentation-outliner

Structure presentations, pitch decks, and internal slide decks from rough ideas into clear outlines with slide-by-slide content guidance, key messages, and data callouts. Use when the work is organizing thoughts into a presentation structure. Do not use for visual design, slide layout, or graphic creation.

Source facts

Repository
hoavdc/CodexKit
Last source activity
March 22, 2026 at 17:03
Detected SKILL.md language
English
Stars
26
Forks
12

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
2 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
codexkit-presentation-outliner
description
Structure presentations, pitch decks, and internal slide decks from rough ideas into clear outlines with slide-by-slide content guidance, key messages, and data callouts. Use when the work is organizing thoughts into a presentation structure. Do not use for visual design, slide layout, or graphic creation.
version
1.0.0
category
knowledge
# Presentation Outliner ## Purpose Turn unstructured thoughts into a clear presentation outline with slide-by-slide guidance that makes the actual slide creation fast. ## When to use - planning an internal presentation, team update, or all-hands talk - structuring a client pitch deck or business case presentation - building a board deck, QBR presentation, or project review - organizing scattered notes into a coherent narrative arc ## When not to use - creating actual slides (this produces the outline, not the deck) - graphic design or visual layout decisions - writing a document (use report-summarizer or executive-brief-writer) ## Inputs - topic and purpose of the presentation - target audience (internal team, executives, clients, investors) - time limit or slide count constraint - key data points, facts, or arguments to include - desired outcome (inform, persuade, request decision, celebrate) - any corporate constraints (template, required sections) ## Procedure 1. Clarify the one-sentence purpose: what should the audience do or believe after? 2. Choose a narrative arc: - **Inform:** Context → Findings → Implications → Next steps - **Persuade:** Problem → Evidence → Proposal → Ask - **Decide:** Situation → Options → Recommendation → Decision ask 3. Outline each slide with: title, key message (one sentence), supporting points, and data/visual callout. 4. Ensure the first slide hooks attention and the last slide has a clear call to action. 5. Flag slides that need data, charts, or visuals the user must prepare. 6. Suggest speaker notes for complex slides. ## Output - slide-by-slide outline (title, key message, supporting points, visual notes) - narrative arc summary - preparation checklist (data, charts, approvals needed) - estimated presentation time ## Definition of done - every slide has one clear key message - the deck tells a coherent story from slide 1 to the last - there is a clear call to action on the final slide - any required data or visuals are flagged in a preparation checklist ## Examples - "Outline a 10-slide pitch for our new product feature to the leadership team." - "Structure a board deck for Q1 results — we need to explain the revenue miss and recovery plan." - "Plan a 15-minute all-hands presentation about the engineering reorg." - "Create an outline for a client QBR — highlight adoption gains and renewal ask." ## Quality Criteria - [ ] All claims reference specific frameworks, standards, or quantifiable data - [ ] Content matches the stated audience's expertise level - [ ] Recommendations are actionable — each includes a concrete next step - [ ] No unsupported assertions or generic filler language ## Verification (4C) | Check | Question | |-------|----------| | **Correctness** | Do referenced frameworks and standards match their official definitions? | | **Completeness** | Are all key concepts covered without significant gaps for the stated audience? | | **Context-fit** | Would this be useful for someone new to this domain, or is it too advanced/too basic? | | **Consequence** | If a stakeholder acted on this immediately, what could they misinterpret? | ## Edge Cases - **Conflicting frameworks** — State which framework takes precedence and why. Document the trade-off explicitly. - **Rapidly changing domain** — Note information currency date. Flag sections likely to need updates. - **Audience has mixed expertise levels** — Provide a glossary and mark advanced sections as optional. ## Changelog - v1.0.0 — Initial release
View on GitHub