L1Lesson 7Free

Write the deck brief

The packet for Claude or a designer

After this, you'll be able to create a complete deck brief and use it to move a deck from rough material toward a presentable file.

Before you start

Complete Assign slide jobs first.

The idea

The deck brief is the handoff packet. It gives Claude, PowerPoint, Google Slides, Canva, or a designer the argument, source material, slide jobs, tone, and output rules. This lesson asks you to make a complete deck brief, not a prettier version of scattered notes. The output should be specific enough that someone could open the deck file and see what changed.

Audience, decision, proof, slide jobs, tone, and sources float as loose deck parts. — The first move: turn the lesson input into a complete deck brief.

Here is the before and after: Before, the builder guesses the room, story, and source quality. After, the build starts with a clear packet that keeps the deck from drifting. 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: Combine the decision statement, argument, proof inventory, storyline, and slide jobs into one deck brief. 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.

Write the deck brief runtime mapThe deck works when a complete deck brief connects the input, the check, and the next step.

Messy inputThe raw pitch deck material before the lesson shapes it.
a complete deck briefThe 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 (18 min)

Watch out for

Sending only the slide list and leaving proof out of the brief.
Skipping brand rules because design comes later.
Hiding open questions instead of resolving them before build.

Paste this into Claude

Assemble a deck brief from this material: [paste decision, argument, proof inventory, storyline, slide jobs]. Return Deck Type, Audience, Decision, Argument, Slide List, Proof Inventory, Brand Rules, Output Format, Open Questions, and Build Instructions.

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 complete deck brief
- 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 brief names the audience, decision, and deck type.
The slide list is included.
Proof and missing proof are visible.
Build instructions name the output tool or handoff recipient.

Go deeper (8 min)

Paste this into Claude

Without rereading the lesson, explain why a complete deck brief 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 complete deck brief 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

Fails when the brief lacks output rules because the builder returns the wrong file or detail level.
Breaks when open questions are hidden because the deck fills gaps with guesses.

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 complete deck brief, challenge the weakest assumption, and rewrite the artifact once so it is ready for the next deck step.

The parts bind into one complete deck brief packet.

You can now

You can explain a complete deck brief 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 brief turns messy thinking into build-ready instructions. It is the control surface for the whole deck.

The brief holds strategy and source material.
Open questions belong in the brief.
Brand and output rules should arrive before build.
A clear brief shortens design review.

Was this helpful?

Up nextTurn rough notes into an outline

Assign slide jobs Turn rough notes into an outline

← Back to Slides & Pitch Decks

Assemble a deck brief from this material: [paste decision, argument, proof inventory, storyline, slide jobs]. Return Deck Type, Audience, Decision, Argument, Slide List, Proof Inventory, Brand Rules, Output Format, Open Questions, and Build Instructions. 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 complete deck brief - 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 complete deck brief 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 complete deck brief 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.