/skill-deck

name: skill-deck
description: "Generate slide deck presentations from briefs — use when you need slides, pitch decks, or visual summaries"
disable-model-invocation: true

> **Host: Codex CLI** — This skill was designed for Claude Code and adapted for Codex. > Cross-reference commands use installed skill names in Codex rather than `/octo:*` slash commands. > Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. > For host tool equivalents, see `skills/blocks/codex-host-adapter.md`.

Slide Deck Generator

Generate slide decks from briefs with optional research, stakeholder red teaming, outline approval, rendering and slide-by-slide verification. Invoke the installed `skill-deck` with `--red-team <brief>` to request the stakeholder pass, which makes additional provider calls. Claude Code users can also use the deck slash command.

EXECUTION CONTRACT (MANDATORY for --red-team)

When `--red-team` is selected, run the readiness and budget checks below before dispatch. Use actual provider artifacts for the objection pass and obtain approval of the revised outline before rendering. Without the flag, skip the provider pass. Simulating seats, bypassing consent, or claiming a completed pass with missing outputs is prohibited.

Prerequisites

Inspect the current session's advertised skills. A standalone `pptx` or another plugin's `pptx` skill is sufficient; plugin ownership is not a prerequisite. An explicit renderer such as a house-template or Google Slides skill must also be advertised. Do not infer availability from files on disk.

Set `OCTO_ROOT` to the installed Octopus root identified by this loaded skill or the host's plugin-root metadata. Verify that it contains `scripts/helpers/document-renderer.py`. Pass `--format pptx`, one `--available-skill NAME` for each advertised skill, and `--renderer NAME` or `--template PATH` when the user supplied them. Quote each argument as data. For example, when `pptx` is exposed:

python3 "$OCTO_ROOT/scripts/helpers/document-renderer.py" --format pptx \
  --available-skill pptx

The helper reads `~/.claude-octopus/document-renderers.json` for saved choices. Use its returned `skill` and `template`. An unavailable selection or ambiguous discovery needs correction before rendering; do not silently substitute another skill. When no renderer is advertised, explain what format capability is missing and offer installation guidance without installing it automatically. An outline can still be prepared. See `docs/DOCUMENT-RENDERERS.md` for configuration and selection precedence.

Pipeline (5 Steps)

Step 1: Gather Brief

Parse the user's topic and description. Use **AskUserQuestion** to clarify:

**Question 1 - Audience:**

• Executives / Board
• Engineers / Technical
• Investors / Fundraising
• General / Mixed

**Question 2 - Slide count target:**

• Short (5-10 slides)
• Standard (10-20 slides)
• Extended (20+ slides)

**Question 3 - Tone:**

• Formal / Business
• Technical / Detailed
• Casual / Conversational

If the user already provided clear context (e.g., "10-slide investor pitch deck about our Series A"), skip questions where the answer is obvious.

For `--red-team`, also gather an audience map: each stakeholder's role, whether they are a decision-maker or influencer, their priority, and the question they are likely to ask. Use supplied details; clarify missing priorities with the user instead of inventing stakeholder positions.

Step 2: Research (Optional)

If the topic needs external research or context gathering:

• Use the **host subagent tool** with `Explore` or `general-purpose` subagent to gather relevant information
• For deeper multi-AI research, suggest: "For comprehensive multi-provider research, run `/octo:discover [topic]` first, then `/octo:deck` to build slides from the results"
• If the user provides their own content, notes, or a research file, skip this step entirely

This step is OPTIONAL. Many decks are built from the user's own knowledge or existing documents.

Step 3: Generate Outline

Build the outline as an answer-first storyline before choosing slide layouts. Keep the brief's audience, purpose and approved slide-count target.

1. Define one **governing question** from the brief. For a decision deck, state the decision, the threshold for yes and an out-of-scope list. For an informational brief, state the question the audience needs answered and what would count as a useful answer. Do not invent a decision or approval ask for an informational update. Confirm the governing question with the user before building the skeleton, using **AskUserQuestion**. Reuse an already explicit confirmation of that exact question; an unanswered question is not approval. 2. Write an **SCQA opener** with the situation, complication and question. The question must match the confirmed governing question. Keep the opener brief and use supplied or sourced facts; mark evidence gaps rather than inventing context. 3. Write a **working hypothesis**: a one-sentence answer with two to four pillars that must be true. For executive and board decision briefs, use two or three pillars so the hypothesis matches the executive summary. Tie each pillar to available evidence or label it as an assumption to validate. An informational deck's answer can be a conclusion about results rather than a recommendation to approve something. 4. Build the **sentence skeleton** with one declarative sentence per storyline slide, in order. Exclude the cover slide from this skeleton; keep its presentation name, subtitle, date and presenter as metadata. The cover still counts toward the approved slide-count target. Each storyline title must make a claim that advances the answer. Under each claim, record its supporting evidence and intended visual. Keep unverified claims marked as assumptions; do not turn