Create OCI technical PowerPoint decks for instructor-led product overviews, service deep dives, workshop lessons, and technical briefings such as OCI networking, compute shapes, observability, storage, security, or architecture internals. Use when the user wants a technical slide deck, slide outline, or polished `.pptx` with presenter notes on every slide.
설치
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Create OCI technical PowerPoint decks for instructor-led product overviews, service deep dives, workshop lessons, and technical briefings such as OCI networking, compute shapes, observability, storage, security, or architecture internals. Use when the user wants a technical slide deck, slide outline, or polished `.pptx` with presenter notes on every slide.
OCI Technical Decks
Overview
Use this skill when the user wants a technical OCI PowerPoint deck that teaches how a service, architecture pattern, or platform capability works.
This skill is instructor-led by default:
every slide should include presenter notes
visible slide copy should stay concise enough for live delivery
the story should answer technical questions, not just market the service
diagrams, tables, and architecture views should carry the explanation when they can
design-director review is mandatory before sign-off on any PowerPoint output
This skill is not the right starting point when the user mainly wants:
an executive why OCI deck with business-outcome framing first
a single OCI architecture diagram or architecture slide
raw documentation rewritten as slides without presentation design
topic-based slide outlines, presenter notes, or full .pptx creation
Quick Routing
If the user provides an Oracle technical deck or a prior workshop deck, audit it first for pacing, technical depth, visuals, and internal-only markings.
If the deck needs conceptual technical diagrams such as layered host boundaries, control-plane versus data-plane views, comparison frames, annotated screenshot modules, or footprint visuals, read ../oci-diagram-patterns/SKILL.md before improvising shapes.
Ask only the smallest useful set of follow-up questions, usually 1-4, after the plan and any source-deck audit. Questions must come from real decision gaps, not a hardcoded checklist. Lead with the recommended assumption first.
If one or more slides need repeatable conceptual diagrams or editable technical motifs, read ../oci-diagram-patterns/SKILL.md and create a Pattern Brief before slide authoring.
Draft the deck slide by slide. For each slide, include:
title
core message
supporting points
recommended visual
presenter_notes
optional demo cue or transition
If the user wants an actual .pptx:
keep the deck instructor-led rather than document-like
put presenter coaching, transitions, caveats, and deeper explanation into notes on every slide
keep visible slide copy audience-facing and compact
use subtitles only for audience-facing context; if the line reads like speaker guidance, a teaching cue, a transition, a recommendation caveat, or a workshop instruction, put it in presenter notes instead
do not add bottom footer strips for presenter interpretation in instructor-led decks unless the user explicitly asks for a leave-behind slide
size eyebrow pills for one clean line, or shorten the label; never allow eyebrow labels to wrap or escape the pill
keep compact service tiles to service-name labels only, normally 1-2 lines; put descriptions such as "search and patterns" or "trend and capacity" in presenter notes or a larger explanatory card
preserve Oracle-native technical deck feel without copying source-deck text
use ../oci-diagram-patterns/SKILL.md for editable conceptual diagrams instead of ad hoc shapes whenever the same motif could recur
export a preview and review for clipping, overlap, leaked notes, pacing problems, and any text escaping its intended card or container
treat text that spills outside a card, box, or summary strip as a hard blocker, not a polish item
if PowerPoint-native shrink makes a card technically fit but visibly cramped, rewrite the copy or enlarge the container instead of accepting the slide
use the renderer quality output as a hard gate and rerender until there are no unresolved text-overflow or text-cramped findings, using the renderer's --fail-on-text-overflow mode for final deck passes
Before sign-off, explicitly record:
that presenter notes exist on every slide
whether the deck is internal-only or customer-safe
that design-director review passed, or the findings that were fixed
Default Deck Sizes
Product overview: 8-12 slides
Service-family overview: 6-10 slides
Comparison deck: 6-9 slides
Customer-safe technical briefing: 8-14 slides
Workshop lesson deck: 10-20 slides
Increase slide count only when the teaching objective really needs step-by-step explanation or appendix detail.
Technical Deck Guardrails
Lead with the technical question, architecture problem, or operational challenge first.
Keep one teaching point per slide.
Prefer diagrams, comparisons, and annotated visuals over bullet-heavy narration.
Every slide should include presenter notes. Do not treat notes as optional.
Keep visible slide copy concise enough for instructor-led delivery.
Use customer-safe language by default unless the user explicitly asks for Oracle-internal or restricted material.
Remove inherited confidentiality labels, safe-harbor pages, internal reminders, or product-direction language unless the user explicitly wants that internal deck behavior.
Verify precise OCI facts against official Oracle sources when correctness materially matters.
Separate what is known, assumed, and recommended.
Avoid service-catalog dump slides. Group services by job-to-be-done, architecture role, or operator workflow.
State tradeoffs honestly on comparison slides.
Do not drop dense screenshots or terminal output onto the slide without cropping, scaling, or framing them so they are readable.
Reduce table rows before shrinking the font into clutter.
Keep presenter prompts, transition cues, and explanations in notes, not on the canvas.
Keep spoken recommendations, teaching cues, and transition lines out of subtitles, footer bars, and summary strips unless the text is truly meant for the audience to read.
Use one architecture diagram, one comparison frame, or one hero visual per slide when possible.
If the deck covers networking, observability, or another control-plane-heavy topic, be explicit about data path, control path, and where the service sits.
Treat visible text escaping its intended card, chip, callout, strip, or container as a blocker.
Treat compact icon tiles as labels, not explanation boxes. If the label needs both a service name and a description, the tile is too small or the explanation belongs elsewhere.
Do not accept a deck just because PowerPoint can auto-fit the text; if the box becomes cramped or visibly strained, revise the slide.
Review Checklist
Before sharing the deck or outline, check:
Is the teaching goal explicit?
Does each slide answer one technical question?
Are presenter notes present on every slide?
Is the visible copy concise enough for instructor-led delivery?
Did the deck pass design-director review?
Did any presenter notes, speaker coaching, or author prompts leak into visible slide text?
Do subtitles, footer strips, and bottom callouts read as audience-facing slide content rather than presenter notes?
Are all eyebrow and section pills single-line labels that fit inside their boxes?
Do compact service tiles stay to short labels without wrapped descriptive copy pushing toward the card edge?
Did any internal-only label, safe-harbor text, or confidentiality footer remain unintentionally?
Are any comparisons or product statements outdated, overstated, or missing key caveats?
If diagrams are present, did architecture and visual review pass?
Does any visible text clip, overlap, or collide with a border?
Did the final render pass the hard text-containment gate with no unresolved text-overflow or text-cramped findings?
Did the generated .pptx open and export cleanly through a PowerPoint-native path?
Deliverables
Default to producing:
A short planning summary.
A source-deck audit summary when a source deck exists.
The recommended deck type and why it fits.
The slide-by-slide outline.
Presenter notes for every slide.
Diagram-pattern handoff notes when conceptual diagrams are needed.
Architecture-slide handoff notes when OCI diagrams are needed.
A final .pptx when the user asks for an actual deck.
Read ../oci-diagram-patterns/SKILL.md when the deck needs layered system diagrams, packet or control flows, comparison motifs, annotated screenshots, or other reusable conceptual visuals.
