Why Claude Code is useful for slide decks in 2026: the orchestration checklist before opening PowerPoint

Claude Code is useful for slide decks before the deck becomes a deck.

That is the practical 2026 point.

If you open PowerPoint too early, you start solving layout problems before you have solved the talk.

If you ask an AI tool for a finished 40-slide presentation too early, you get a deck-shaped object.

Sometimes it looks fine.

Often it has no operating memory.

The title slides look polished.

The middle slides drift.

The speaker notes do not match the visual hierarchy.

The examples were written for three different audiences.

The generated images are attractive, but the talk would still work better without half of them.

That is not a PowerPoint failure.

That is an orchestration failure.

The reason I like Claude Code for slide work is not that it is secretly a presentation designer.

It is not.

The reason is that slide decks are usually surrounded by files.

There is a brief.

There are source links.

There are old talks.

There are screenshots.

There are code examples.

There are audience variants.

There are speaker notes.

There is a review checklist.

There is a PDF export.

There may be a blog post, a workshop handout, or a follow-up newsletter.

Claude Code is good at turning that messy project folder into a repeatable workflow.

That matters more than one more pretty template.

This field note is about that workflow.

Not “how to make AI generate slides.”

Not “how to replace PowerPoint.”

Not “how to make every slide look like a consulting deck.”

The useful question is smaller and more operational.

What should happen before opening PowerPoint?

My answer:

make Claude Code split the deck job into design scaffolding, parallel drafting, visual briefs, and review gates.

Then use PowerPoint for the thing PowerPoint is still good at: final visual editing, presenter mode, brand templates, animations, and exports people can actually open.

That split sounds boring.

Good.

Most reliable workflows are a little boring.

The fireworks come later, preferably after the speaker notes stop contradicting the slide titles.

The practical answer

Do not ask Claude Code to make the final deck first.

Ask it to make the deck system first.

For a serious presentation, that system should have at least four files:

• brief.md
• deck_style.md
• slides_outline.md
• deck_review.md

For a workshop, add two more:

• speaker_notes.md
• audience_variants.md

For a visual-heavy talk, add one more:

• visual_brief.md

Those filenames are not sacred.

The separation is.

The brief says why the talk exists.

The style file says what kind of slides are allowed.

The outline says what happens in what order.

The speaker notes say what the presenter will actually say.

The audience variants say what changes when the room changes.

The visual brief says which images are worth generating, and which images should not exist.

The review file says whether the talk survives rehearsal.

That is the deck before the deck.

Claude Code is useful because it can keep those files visible, editable, and reusable.

PowerPoint is useful after those files stop arguing with each other.

Tiny workflow joke, but true:

PowerPoint should not be the place where you discover your audience.

Why slide decks are not just slides

A deck is a compressed operating system for a talk.

It has state.

It has dependencies.

It has failure modes.

It has exports.

It has users.

The presenter is one user.

The live audience is another user.

The person reading the PDF later is another user.

The teammate reusing five slides next month is another user.

Most AI slide workflows ignore that.

They treat the deck as a final artifact.

That is why the first output can look surprisingly good, and the second use can feel surprisingly painful.

A reusable deck workflow needs memory outside the .pptx.

It needs to remember why a slide type exists.

It needs to remember which examples were cut.

It needs to remember which claims need sources.

It needs to remember which images are decorative and which ones explain something.

It needs to remember why a presenter note was shortened.

A PowerPoint file can contain some of that.

But it is a poor place to operate that logic.

Markdown files are better for the planning layer.

Claude Code is better around that planning layer.

That is the core pattern.

Use Claude Code for orchestration.

Use PowerPoint for final presentation craft.

Do not confuse the two.

When teams confuse the two, they end up with a beautiful deck that no one can safely reuse.

That is presentation debt.

It is like technical debt, except the interest is paid during Q&A.

What Claude Code contributes

Claude Code’s official documentation describes several project-level building blocks that matter here.

Skills and command-style workflows can store repeatable prompts and supporting files.

Subagents can handle bounded side tasks in separate contexts.

Hooks can run checks around events in the workflow.

Settings can limit access to sensitive files.

None of these features says “presentation designer” on the label.

That is fine.

The deck problem is not only a design problem.

It is a coordination problem.

The value is in the way these pieces help you separate work.

Use a skill or command for a repeatable deck setup prompt.

Use a subagent for noisy research or source cleanup.

Use another subagent for audience-specific examples.

Use a hook or script later to check obvious problems, such as missing source links, oversized sections, or forbidden placeholder text.

Use settings to keep private customer files out of the AI-readable project area.

That is a realistic use of Claude Code.

It is not glamorous.

It also survives Tuesday afternoon, which is more important than being glamorous.

The four-lane slide deck workflow

Here is the workflow I trust.

Lane	Question	Output	Human review
Design scaffold	What kinds of slides are allowed?	deck_style.md	Does the deck have a consistent grammar?
Draft lanes	What should each audience hear?	slides_outline.md, speaker_notes.md	Can the presenter say this naturally?
Visual briefs	Which visuals are worth making?	visual_brief.md	Would the slide still work without the image?
Review gate	Can this survive rehearsal?	deck_review.md	What breaks live?

This table is intentionally simple.

If it needs a 40-box architecture diagram, the workflow is probably too heavy for most talks.

A deck workflow should reduce the number of places where decisions hide.

It should not create a small bureaucracy with nicer filenames.

The goal is not to automate taste.

The goal is to make taste inspectable.

That is a different thing.

When a slide feels wrong, you want to say:

the slide type is wrong.

The audience variant is wrong.

The image brief is weak.

The presenter note is too long.

The source is missing.

That beats saying:

“Can you make it better?”

AI can respond to “make it better.”

It just responds with vibes.

Vibes are not a review system.

Lane 1: design scaffolding

Design scaffolding is not choosing a template.

It is deciding what the deck is allowed to do.

A useful deck_style.md might include:

• audience
• talk length
• slide types
• information density
• visual rules
• table limits
• code block rules
• screenshot rules
• forbidden patterns
• export requirements

For example:

# deck_style.md

## Purpose
- audience: product managers and engineering leads
- length: 40 minutes plus 10 minutes for questions
- mode: 60% explanation, 25% workflow demo, 15% decision checklist

## Slide types
- problem: one operational pain, no more than two supporting bullets
- workflow: four steps or fewer
- demo: include fallback screenshot
- checklist: only actions the audience can take this week

## Visual rules
- no decorative images
- no generated text-heavy diagrams
- no tables with more than five rows
- screenshots must include source path or capture date

This file makes the deck less random.

It also makes feedback less personal.

Instead of saying, “This slide looks messy,” you can say, “This slide violates the five-row table limit.”

That is easier to fix.

It is also easier to teach to an AI assistant.

The design scaffold becomes a local operating rule.

If you make a lot of talks, this is where the compounding starts.

The next deck does not start from zero.

It starts from a grammar you have already tested.

Lane 2: parallel drafting

Deck drafting usually fails because too many concerns are mixed.

The outline wants structure.

The speaker notes want rhythm.

The examples want relevance.

The audience variants want judgment.

If you ask for all of them at once, the model tends to average the room.

That is how you get a talk that is not quite for developers, not quite for executives, not quite for operators, and very much for no one.

Claude Code subagents can help if the work is independent and bounded.

The official subagents documentation frames subagents as specialized assistants with separate contexts.

That matters because slide research can be noisy.

One lane can inspect prior notes.

One lane can gather examples.

One lane can draft Q&A.

One lane can pressure-test the flow.

The main session should not swallow every source snippet, every screenshot note, and every rejected example.

It should receive the summary.

That is the value.

But do not over-delegate.

For a 15-minute internal talk, subagents are often unnecessary.

For a paid workshop or conference session, they can save the main thread from drowning.

My rough threshold:

• 10-minute update: main session only
• 30-minute talk: main session plus one research lane
• 60-minute workshop: outline lane, examples lane, review lane
• multi-audience training: audience variants become their own lane

The task has to earn delegation.

Otherwise you are holding a committee meeting with your own tools.

No one needs that before coffee.

The three draft files I want

For serious decks, I want three drafting files.

First, slides_outline.md.

This is slide-by-slide structure.

Each slide gets:

• title
• purpose
• core sentence
• slide type
• expected time
• source need

Second, speaker_notes.md.

This is what the presenter will say.

It should include transition lines.

A deck without transitions often looks fine and sounds broken.

Third, audience_variants.md.

This is where the deck becomes reusable.

For example:

## Engineering audience
- show: folder structure, failure logs, test command, review gate
- reduce: market framing and abstract productivity claims
- risk to emphasize: permissions, context pollution, tool sprawl

## Marketing audience
- show: content calendar, approval flow, brand voice checks
- reduce: implementation detail
- risk to emphasize: unsupported claims, source drift, tone mismatch

## Executive audience
- show: cost center, ownership, rollout path, failure fallback
- reduce: prompt examples and internal tooling detail
- risk to emphasize: governance, security, quality accountability

This is where many AI deck workflows become useful.

The trick is not making a brand-new deck every time.

The trick is changing the right variables.

Audience changes should not destroy the entire deck.

They should modify examples, depth, and risk framing.

That is a workflow problem.

Claude Code is good at workflow problems.

Lane 3: image briefs

Generated images are tempting in presentations.

They make a deck feel alive.

They can also create a false sense of substance.

My rule is simple:

do not generate an image until the slide has a job.

The image should explain, compress, or make a concept memorable.

It should not decorate a weak argument.

For most technical or operational decks, generated visuals are useful in only a few situations:

• before-and-after workflow scenes
• abstract concepts that need a visual metaphor
• process maps with very short labels
• workshop section dividers
• non-literal memory anchors

They are risky in other situations:

• numeric charts
• legal or financial claims
• product UI mockups that must be accurate
• screenshots
• logos
• source-heavy diagrams
• slides where small text must be correct

That is why visual_brief.md matters.

It should exist before the image prompt.

Example:

# visual_brief.md

## Target slide
- slide 9: why one prompt should not produce the whole deck

## Purpose
- show the difference between "one large prompt" and "four workflow lanes"

## Labels
- brief
- style
- draft
- review

## Constraints
- no logos
- no numeric claims
- no tiny text
- no fake app interface

## Alt text
- Four separated workflow lanes feeding a final presentation deck.

This brief does two jobs.

It makes the image generation request safer.

It also gives you permission not to generate the image.

If you cannot explain what the image is for, skip it.

The best generated image is sometimes the one you did not add.

That sentence sounds like productivity incense, but it is painfully practical.

Fewer images mean fewer review failures.

Lane 4: review gates

Slide decks need rehearsal-based review.

Not file-based review.

A deck can look good and still fail live.

The titles can be clear.

The visuals can be polished.

The sequence can still make the presenter stumble.

That is why deck_review.md should ask live-use questions.

I like these:

• Can the talk fit the time limit?
• Does each slide have one job?
• Does each transition sentence exist?
• Does the demo have a fallback?
• Are sources attached to claims?
• Would the PDF reader understand the deck without the presenter?
• Are generated images necessary?
• Are there any placeholders left?
• Are private notes separated from export files?
• Is there a clear next action?

Later, some of this can become automation.

Claude Code hooks can run scripts around workflow events.

The official hooks reference describes events such as tool use, subagent start and stop, file changes, session start, and stop events.

For deck work, a lightweight script could check:

• missing source links
• too many slides
• forbidden placeholder text
• missing visual_brief.md
• missing fallback screenshot for demo slides
• private folder references in export notes

Do not start there.

Start with the checklist.

Then automate the boring failures that repeat.

Automation before repetition is usually theater.

It feels sophisticated.

It also produces very elegant waste.

A practical folder structure

Here is a folder structure I would actually use.

ai-workflow-slide-deck/
├── brief.md
├── deck_style.md
├── slides_outline.md
├── speaker_notes.md
├── audience_variants.md
├── visual_brief.md
├── deck_review.md
├── sources/
│   ├── official-links.md
│   └── examples.md
├── assets/
│   ├── screenshots/
│   └── generated/
├── private/
│   └── not-for-ai.md
└── exports/
    ├── slides.pptx
    ├── slides.pdf
    └── handout.pdf

The private/ folder is not decorative.

Deck projects often contain sensitive material.

Customer names.

Internal numbers.

Roadmap notes.

Contract details.

Student information.

Claude Code settings can be used to deny access to sensitive patterns.

The official settings documentation describes denying reads for files such as environment files or secrets.

The same idea applies to slide projects.

Decide what the AI can read.

Decide what it cannot read.

Decide what must be summarized manually.

Do that before the deck grows.

Security problems are annoying in code.

They are also annoying in presentation files, just with nicer fonts.

The prompt sequence

The bad prompt is:

Create a 40-slide deck about AI workflow orchestration.
Make it professional and engaging.
Add speaker notes and images.

That prompt is not evil.

It is just too much.

It asks for strategy, structure, writing, design, image planning, and review in one breath.

Use a sequence instead.

Step one:

Read brief.md.
Create deck_style.md for a 40-minute talk.
Limit the deck to 8 slide types.
For each slide type, define purpose, allowed content, and forbidden patterns.

Step two:

Using deck_style.md, create slides_outline.md.
Keep the deck under 24 slides.
For each slide, include title, purpose, slide type, core sentence, expected time, and source need.

Step three:

Create speaker_notes.md from slides_outline.md.
Each slide should be speakable in 60 to 90 seconds.
Add transition sentences between slides.
Mark any slide that sounds like a document instead of a talk.

Step four:

Create audience_variants.md for engineering, marketing, and executive audiences.
Do not rewrite the whole deck.
Only list which examples, risks, and depth should change.

Step five:

Create visual_brief.md.
Only select slides where an image or diagram improves comprehension.
For each selected slide, define purpose, labels, constraints, and alt text.
Also list slides where an image should be skipped.

Step six:

Create deck_review.md.
Review the deck as a live presentation, not as a document.
Check timing, transitions, source needs, demo fallback, audience fit, export risks, and generated image risk.

This sequence does not guarantee a great talk.

Nothing does.

But it makes the weak points visible earlier.

That is the real win.

When to use PowerPoint

Use PowerPoint when the deck needs presentation craft.

That includes:

• brand templates
• final layout
• typography
• animations
• presenter mode
• comments from non-technical teammates
• PPTX delivery
• PDF export checks
• projector-specific fixes

Claude Code does not replace that.

It prepares for it.

The best split is:

Claude Code handles the planning layer.

PowerPoint handles the final presentation layer.

If your organization already has strict templates, do not fight that.

Use Claude Code to make better content inputs.

Then place them into the existing deck system.

The goal is not to turn every slide workflow into a developer workflow.

The goal is to stop presentation work from becoming invisible, unreviewable, and impossible to reuse.

That is a more modest goal.

It is also more useful.

When this workflow is too much

Do not use this for every deck.

A 10-minute internal update does not need seven Markdown files.

A one-time status report does not need subagents.

A fixed corporate template with four updated numbers may not need Claude Code at all.

This workflow becomes worth it when:

• the deck will be reused
• the audience changes often
• the talk has sources
• the speaker notes matter
• the deck becomes a workshop
• screenshots or demos can fail
• the presentation also becomes a blog post or handout
• quality review needs to be repeatable

If none of those are true, keep it simple.

Open PowerPoint.

Make the slides.

Move on with your life.

Not every workflow needs a command center.

Sometimes a slide is just a slide.

Small mercy, honestly.

The failure modes

The first failure mode is template addiction.

The deck looks different, but the message did not change.

The second failure mode is audience averaging.

The deck tries to satisfy engineers, executives, marketers, and beginners at once.

It satisfies the ceiling fan.

The third failure mode is visual overproduction.

Every section gets an image.

Half of them are decorative.

The presenter becomes a tour guide for AI art.

The fourth failure mode is missing speaker notes.

The deck reads well but speaks badly.

That is a live presentation problem, not a writing problem.

The fifth failure mode is source drift.

Claims are copied from research notes, but source links disappear before export.

The sixth failure mode is private material leakage.

Internal notes, customer names, or hidden assumptions travel into a deck export.

The seventh failure mode is final-file editing only.

If all fixes happen inside the .pptx, the next deck does not learn from them.

That is why the planning files matter.

They hold the operating memory.

The .pptx holds the final performance.

Both matter.

They should not be the same thing.

A review checklist before opening PowerPoint

Before opening PowerPoint, I want these questions answered:

• What is the talk’s audience?
• What is the time limit?
• What is the one action the audience should take later?
• What slide types are allowed?
• Which slide types are forbidden?
• Which examples change by audience?
• Which claims need sources?
• Which slides require speaker notes?
• Which visuals are necessary?
• Which visuals are decorative and should be skipped?
• Which screenshots need capture dates?
• Which demo steps need fallback slides?
• Which files are private?
• Which files can the AI read?
• Which export formats are required?
• Which review criteria define “done”?

If you cannot answer those, opening PowerPoint will not fix the problem.

It will only make the problem easier to decorate.

Decoration is not strategy.

This is especially true for AI-generated decks.

The prettier the first draft, the easier it is to ignore the missing decisions.

That is why orchestration belongs first.

How this connects to AI coding workflows

This sounds like a presentation article, but it is really an AI workflow article.

The same principle applies to code reviews, blog pipelines, research notes, and product specs.

Do not ask the agent to produce the final artifact first.

Ask it to expose the workflow.

Then ask it to produce artifacts inside that workflow.

For code, that might mean spec, tests, patch, review.

For blog publishing, that might mean research, draft, preflight, publish, sync.

For slide decks, it is brief, style, outline, notes, visuals, review, export.

The artifact changes.

The operating pattern does not.

That is why Claude Code is a reasonable tool here.

It gives you a project workspace, not just a chat box.

The workspace is the point.

FAQ

Should Claude Code generate the final PowerPoint file?

Sometimes, but that is not the first job I would give it.

The higher-value job is creating the planning layer: brief, style rules, outline, speaker notes, visual briefs, and review criteria.

Once those are stable, you can decide whether the final file should be built through PowerPoint, Keynote, a Markdown-to-slides tool, or a script.

Is this workflow only for technical speakers?

No.

Technical speakers may benefit from it because their decks often include code, demos, and source-heavy claims.

But the same workflow helps product managers, marketers, consultants, and operators who reuse talks across different audiences.

The key is not technical complexity.

The key is repeatability.

If the deck will be reused, the planning files are worth keeping.

When should I use subagents for a slide deck?

Use subagents when a side task is independent, bounded, and likely to produce noisy context.

Good examples include source cleanup, audience-specific examples, FAQ generation, or review against a checklist.

Do not use subagents for every tiny slide edit.

If the next step depends on your immediate judgment, keep the work in the main session.

Are generated images worth adding?

Only when they clarify the talk.

Generated images are useful for memory anchors, simple workflow scenes, or abstract concepts that are hard to explain with text alone.

They are risky for charts, numeric claims, logos, product screenshots, and anything where text accuracy matters.

That is why I prefer writing visual_brief.md before generating anything.

What is the smallest version of this workflow?

Use three files:

• brief.md
• slides_outline.md
• deck_review.md

That is enough for a solo speaker preparing a short but reusable talk.

Add deck_style.md, speaker_notes.md, and visual_brief.md only when the deck starts getting reused, reviewed, or adapted for different audiences.

Related reading

• Claude Code로 강의 PPT를 매번 다르게 만드는 이유 2026
• Claude Code context discipline in 2026 – CLAUDE.md, memory, MCPs, and subagents without wasting tokens
• Claude Code subagents vs main session in 2026

Sources

• Claude Code Docs: Extend Claude with skills
• Claude Code Docs: Create custom subagents
• Claude Code Docs: Hooks reference
• Claude Code Docs: Claude Code settings
• Local companion post: 02.Areas/blog/ai_llm/260429 Claude Code로 강의 PPT를 매번 다르게 만드는 이유 2026 디자인 스캐폴딩 병렬 원고 이미지 생성 워크플로우.md
• Local inbox signal: 00.Inbox/260429_[요약] 덕테이프 좋긴한데 어떻게 써요.md

Closing note

Claude Code is not useful for slide decks because it replaces PowerPoint.

It is useful because it can make the work before PowerPoint visible.

That work is where most decks actually succeed or fail.

Define the brief.

Define the slide grammar.

Draft in lanes.

Write image briefs before generating images.

Review the deck as a live talk.

Then open PowerPoint.

The sequence is less magical than “AI made my deck.”

It is also much less likely to embarrass you on slide 17.