| name | oci-diagram-patterns |
| description | Create reusable editable PowerPoint-native diagram patterns and visual motifs for OCI decks, such as layered system diagrams, control-plane and data-plane views, comparison frames, annotated screenshot layouts, packet-flow diagrams, and footprint visuals. Use when another deck or design skill needs a conceptual diagram pattern rather than a full OCI architecture topology. |
OCI Diagram Patterns
Overview
Use this skill when a slide needs a reusable diagram pattern like:
- layered host and control-boundary diagrams
- control-plane versus data-plane diagrams
- side-by-side technical comparison frames
- annotated screenshot or terminal layouts
- lifecycle, packet, or processing flows
- coverage, footprint, or region-presence visuals
- component stacks, trust boundaries, or subsystem maps
This skill is a pattern-builder, not a full deck skill and not a full OCI topology generator.
It should usually work with one or more sibling skills:
What This Skill Owns
This skill owns:
- pattern selection
- diagram motif structure
- editable PowerPoint shape language
- boundary, lane, and module relationships
- geometry recommendations for reusable conceptual diagrams
- optional JSON fragments that reuse the PowerPoint renderer primitives when appropriate
It does not own:
- full deck storyline
- OCI product fact validation
- full OCI architecture topology
- final deck sign-off by itself
Workflow
- Start with a short plan:
- what the slide needs to explain
- whether the diagram is conceptual, comparative, architectural, or operational
- who will read it
- whether it must be customer-safe or can remain internal
- Extract the semantic parts of the diagram:
- boundaries
- modules
- actors
- flows
- labels
- annotations
- Choose the closest pattern from references/pattern-catalog.md.
- Read references/shape-language.md to map the pattern to editable PowerPoint primitives.
- Produce a
Pattern Brief using references/integration-contract.md:
- pattern name
- diagram objective
- element inventory
- geometry plan
- connector plan
- label strategy
- When the sibling skill is PowerPoint-native, prefer editable shapes over pasted images:
shapetextedge- OCI icon groups only when the diagram truly needs native OCI services or logos
- If the pattern can be expressed through the PowerPoint renderer’s existing shape and edge primitives, provide an optional JSON fragment the sibling skill can drop into its slide spec.
- If the desired look depends on decoration the renderer does not support well, such as gradients, soft shadows, or bespoke vector art, first approximate it with editable shapes. Use flattened or external art only when the editable approximation would be misleading or visibly poor.
- Hand back integration notes to the sibling skill:
- what stays visible on the canvas
- what belongs in presenter notes
- what spacing or symmetry rules are non-negotiable
Pattern Guardrails
- Prefer editable PowerPoint shapes over screenshots or flattened illustrations.
- Use one dominant diagram idea per slide.
- Keep boundary hierarchy obvious.
- Keep connectors orthogonal unless a different route is materially clearer.
- Keep labels short and audience-facing.
- Put explanation, caveats, and transitions into presenter notes before adding extra on-canvas text.
- Use restrained color coding: one meaning per color family.
- Do not let decoration overpower the logic of the diagram.
- Avoid overlapping modules, crossing arrows, or labels sitting directly on connector lanes.
- When a sibling skill can already render OCI-native architecture honestly, do not replace it with a conceptual pattern.
Deliverables
Default to producing:
Pattern SelectionPattern BriefElement InventoryGeometry PlanConnector Plan- Optional
PowerPoint JSON Fragment
Integration Notes for the sibling skill
Resources
