Make audience-specific variants

Complete Build the Q&A appendix first.

Deck variants should change emphasis, proof, and detail level without creating a confusing set of unrelated files. This lesson asks you to make a deck variant plan, 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, every audience gets a separate copy with uncontrolled edits. After, the base deck stays stable and variants are tracked by audience need. 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: Create an investor, sales, internal, or training variant plan from the base deck. 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.

Create deck variants from this base deck. Audience variants needed: [list]. For each, return Keep, Cut, Add, Reorder, Proof Emphasis, Tone Shift, File Name, and Review Owner. Base deck: [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:
- a deck variant plan
- 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

• Each variant has a named audience.
• Keep, cut, add, and reorder decisions are explicit.
• Proof emphasis changes by audience.
• File names and review owners are included.

Without rereading the lesson, explain why a deck variant plan 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 deck variant plan 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.