L2Lesson 16Free

Give the builder a deck build prompt

Brief, source, rules, and output

After this, you'll be able to create a build prompt for the deck tool and use it to move a deck from rough material toward a presentable file.

Before you start

Complete Choose the build tool first.

The idea

Deck tools produce better first drafts when the prompt includes the brief, slide list, source constraints, brand rules, and output format. This lesson asks you to make a build prompt for the deck tool, not a prettier version of scattered notes. The output should be specific enough that someone could open the deck file and see what changed.

The first move: turn the lesson input into a build prompt for the deck tool.

Here is the before and after: Before, the prompt asks for a pitch deck and the tool invents structure. After, the prompt tells the tool what to build and what not to invent. For example, if you are preparing a sales presentation, the artifact should name the audience, slide job, proof, speaker note, or export check where that detail matters. A reviewer should be able to tell whether the deck is closer to being presented, sent, or handed off.

Now try it: Turn your deck brief into a builder prompt with sections for source, slides, brand, and review. Make one choice before asking Claude to write: which audience, which decision, which proof, which slide job, or which delivery mode matters most right now. That choice keeps the deck from becoming a generic presentation outline.

Give the builder a deck build prompt runtime mapThe deck works when a build prompt for the deck tool connects the input, the check, and the next step.

Messy inputThe raw pitch deck material before the lesson shapes it.
a build prompt for the deck toolThe thing you can inspect, edit, and reuse.
Review checkThe delivery check that catches a weak assumption.
Next stepThe output moves into the next lesson instead of sitting alone.

The lesson is done when the artifact moves the deck toward a real room, reader, or file handoff.

Try it (16 min)

Watch out for

Asking a deck tool to invent proof the source material does not contain.
Mixing brand systems inside one deck.
Exporting before checking mobile, projector, and send-ahead readability.

Paste this into Claude

Create a deck build prompt for [PowerPoint, Google Slides, Canva, Claude, or designer]. Use this deck brief: [paste]. Include source rules, slide list, brand rules, visual plan, notes rules, output format, and review checklist.

If any input is missing, ask me up to three questions before producing the artifact. Then return five sections: Finished Artifact, Realistic Deck Example, Assumptions To Check, What I Should Use In The Next Lesson, and One Risk If I Present Or Send This Without Fixing It. Keep the answer practical enough that I can paste it into my deck working doc.

What a good response looks like

Finished Artifact:
- a build prompt for the deck tool
- Why it matters: it gives the deck a concrete thing to inspect instead of a vague intention.
- Use it next: paste this artifact into the next lesson before asking Claude to write, build, import, publish, or review anything.

Reality Check:
- The artifact names the user, input, decision, owner, or proof it depends on.
- The weakest assumption is visible.
- The next step can be completed in one sitting.

What good looks like

The prompt includes the deck brief.
The prompt tells the tool not to invent unsupported proof.
The desired output format is named.
The review checklist is part of the prompt.

Go deeper (8 min)

Paste this into Claude

Without rereading the lesson, explain why a build prompt for the deck tool matters in three bullets. Then apply it to a second deck example: [describe a different audience, room, or topic]. Return What Changed, What Stayed The Same, What To Check Before Presenting Or Sending, and the exact next action.

What a good response looks like

Transfer Check:
- What changed: the second example has a different audience, input, or delivery context.
- What stayed the same: a build prompt for the deck tool still needs a source, a review check, and a next step.
- Before trusting it: inspect the delivery check that would catch a wrong assumption.
- Next action: run the check once, then carry the revised artifact into the next lesson.

What good looks like

You explained the lesson idea from memory before applying it again.
The second example changes the artifact instead of copying the first answer.
The delivery check names a real risk.
The next action can be done in one sitting.

When this breaks

Breaks when the prompt lacks source rules because the draft fills gaps with invented confidence.
Fails when output format is unclear because the first draft cannot be used in the target tool.

AI can help with this

Paste the exercise prompt into Claude with your real deck context. Ask Claude to interview you one question at a time, produce a build prompt for the deck tool, challenge the weakest assumption, and rewrite the artifact once so it is ready for the next deck step.

Those pieces fold into one build prompt packet for the chosen tool.

You can now

You can explain a build prompt for the deck tool in one sentence.

You can name the source material or decision it depends on.
You can name the assumption that still needs checking.
You can point to the check that proves it is ready for the next deck step.

Key takeaways

The build prompt is a production instruction, not a request for generic slides.

Prompts should carry source limits.
Slide lists protect structure.
Output format belongs in the first prompt.
Review criteria should travel with the build request.

Was this helpful?

Up nextApply brand or template rules

Choose the build tool Apply brand or template rules

← Back to Slides & Pitch Decks

Create a deck build prompt for [PowerPoint, Google Slides, Canva, Claude, or designer]. Use this deck brief: [paste]. Include source rules, slide list, brand rules, visual plan, notes rules, output format, and review checklist. If any input is missing, ask me up to three questions before producing the artifact. Then return five sections: Finished Artifact, Realistic Deck Example, Assumptions To Check, What I Should Use In The Next Lesson, and One Risk If I Present Or Send This Without Fixing It. Keep the answer practical enough that I can paste it into my deck working doc.

Finished Artifact: - a build prompt for the deck tool - Why it matters: it gives the deck a concrete thing to inspect instead of a vague intention. - Use it next: paste this artifact into the next lesson before asking Claude to write, build, import, publish, or review anything. Reality Check: - The artifact names the user, input, decision, owner, or proof it depends on. - The weakest assumption is visible. - The next step can be completed in one sitting.

Without rereading the lesson, explain why a build prompt for the deck tool matters in three bullets. Then apply it to a second deck example: [describe a different audience, room, or topic]. Return What Changed, What Stayed The Same, What To Check Before Presenting Or Sending, and the exact next action.

Transfer Check: - What changed: the second example has a different audience, input, or delivery context. - What stayed the same: a build prompt for the deck tool still needs a source, a review check, and a next step. - Before trusting it: inspect the delivery check that would catch a wrong assumption. - Next action: run the check once, then carry the revised artifact into the next lesson.