Write claim headers

Complete Turn rough notes into an outline first.

A claim header says what the audience should take from the slide. It is different from a topic label. This lesson asks you to make claim headers for every slide, not a prettier version of scattered notes. The output should be specific enough that someone could open the deck file and see what changed.

Here is the before and after: Before, slide titles say Market, Product, Team, or Budget. After, titles make the point: demand is already visible, the product removes a manual step, or the budget protects delivery. 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: Ask Claude to rewrite every slide title as a claim, then test whether the claims alone tell the deck story. 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.

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

Rewrite these slide titles as claim headers. For each, include Original Title, Claim Header, Proof Needed, and Risk If Unsupported. Slide list: [paste]. Argument: [paste].

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:
- claim headers for every slide
- 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

• Every title makes a claim.
• The claim can be supported by proof.
• The headers in order tell a story.
• Weak claims are marked for rewrite.

Without rereading the lesson, explain why claim headers for every slide 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: claim headers for every slide 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.