Deck maintenance checklist
Keep the file current after the meeting
After this, you'll be able to create a deck maintenance checklist and use it to move a deck from rough material toward a presentable file.
Before you start
Complete Hand off source files and notes first.
The idea
Decks age quickly. Maintenance keeps claims, numbers, proof, audience variants, and file links current. This lesson asks you to make a deck maintenance checklist, 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, an old deck gets reused with stale numbers and broken links. After, the owner has a checklist for updates before every meaningful send. 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: Build a checklist for monthly review or pre-send review, depending on how often the deck is used. 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.
- Messy inputThe raw pitch deck material before the lesson shapes it.
- a deck maintenance checklistThe 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 (14 min)
Watch out for
- Reusing last quarter's deck without checking dates.
- Keeping every old variant in the same folder.
- Updating copy but not speaker notes.
Paste this into Claude
Create a maintenance checklist for this deck. Include claims to refresh, numbers to check, links to test, file permissions, audience variants, old slides to archive, and owner cadence. Deck purpose: [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.
What a good response looks like
Finished Artifact: - a deck maintenance checklist - 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 checklist names the owner and cadence.
- Claims, numbers, links, and permissions are checked.
- Audience variants are included.
- Archive rules are clear.
Go deeper (8 min)
Paste this into Claude
Without rereading the lesson, explain why a deck maintenance checklist 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 deck maintenance checklist 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 deck is reused without review because old claims weaken trust.
- Breaks when variants are not archived because people send the wrong version.
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 deck maintenance checklist, challenge the weakest assumption, and rewrite the artifact once so it is ready for the next deck step.
You can now
You can explain a deck maintenance checklist 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
A deck that matters needs an owner and an update habit.
- Decks become stale.
- Maintenance needs an owner.
- Links and permissions need checks.
- Old variants should be archived.