Run an event debrief that changes the next event — what the numbers say, what actually went wrong versus what felt stressful, and the specific changes carried into the next brief. Use when asked to run a post-event debrief, write an event wrap report, review how an event went, or capture lessons learned after a conference, launch, or wedding. Produces the outcome scorecard against the original objectives, the timeline of what actually happened, the root causes separated from symptoms, supplie...
Scanned 9/3/2026
Install to Claude Code
npx -y skills add mohitagw15856/pm-claude-skills --skill post-event-debrief --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Post Event Debrief?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/mohitagw15856-post-event-debrief-pm-claude-skills)More formats (shields.io, HTML) on the badges page.
---
name: post-event-debrief
description: "Run an event debrief that changes the next event — what the numbers say, what actually went wrong versus what felt stressful, and the specific changes carried into the next brief. Use when asked to run a post-event debrief, write an event wrap report, review how an event went, or capture lessons learned after a conference, launch, or wedding. Produces the outcome scorecard against the original objectives, the timeline of what actually happened, the root causes separated from symptoms, supplier performance, and the changes written into the next event's brief."
---
# Post-Event Debrief
Most event debriefs produce a feelings-based list nobody reads before the next event, and the same three problems recur annually. This separates what went wrong from what merely felt stressful, traces each problem to the decision that caused it — usually made weeks earlier — and writes the fixes into the next brief rather than into a document that gets filed.
## What This Skill Produces
- **The outcome scorecard** — performance against the objectives set before the event, not against how it felt
- **The actual timeline** — what really happened versus the run of show, with the slippage visible
- **Root causes** — each problem traced back to the decision or omission that produced it
- **Supplier performance** — a record specific enough to be useful at the next procurement
- **The budget out-turn** — final versus budget, with the variances explained
- **Changes into the next brief** — the fixes, written as instructions to the next event rather than observations about this one
## Required Inputs
Ask for these if not provided:
- **The original objectives** — what this event was supposed to achieve, from the brief
- **The numbers** — attendance versus target, budget versus out-turn, and any measured outcomes such as leads, funds raised, or satisfaction
- **What happened** — the actual timeline, incidents, and deviations from plan
- **Feedback** — attendee, client, staff and supplier, and how it was gathered
- **The team's account** — what each person found hard, gathered before the group discussion so it is not shaped by the loudest voice
## Framework: Numbers First, Then Causes, Then the Next Brief
1. **Start with the objectives and the numbers.** Before opinion enters the room. An event that felt chaotic and hit every objective is a different problem from one that felt smooth and missed them.
2. **Reconstruct the actual timeline.** Against the run of show. Slippage is visible here in a way it never is in recollection.
3. **Separate the stressful from the broken.** Plenty of things feel terrible and harm nothing; some quiet failures matter enormously. Do not confuse adrenaline with evidence.
4. **Trace each problem to its decision.** The AV failure at 19:00 usually traces to a supplier chosen in March or an access time agreed in April. Debriefing the symptom changes nothing.
5. **Collect individual accounts before the group meets.** Otherwise you get one narrative, shaped by whoever speaks first.
6. **Record supplier performance specifically.** 'Good' is useless in twelve months; 'crew arrived 90 minutes late, recovered without impact, communicated well' is procurement evidence.
7. **Write fixes as instructions to the next brief.** 'Load-in must start 4 hours before doors' belongs in the next brief. 'Load-in was rushed' belongs nowhere.
## Output Format
### Event debrief: [event] · [date] · [debrief date]
**Objectives vs outcome**
| Objective (from the brief) | Target | Actual | Met |
|---|---|---|---|
**Numbers:** attendance [actual/target] · budget [out-turn/budget] · [other measured outcomes]
**What actually happened**
| Planned | Actual | Variance | Effect |
|---|---|---|---|
**Problems — traced**
| What went wrong | Felt bad or was bad? | Root cause (the earlier decision) | Fix |
|---|---|---|---|
**Supplier performance**
| Supplier | Delivered as briefed | Specific notes | Use again |
|---|---|---|---|
**Budget out-turn:** [budget] → [actual] · **Variances over [threshold]:** [line — amount — why]
**Feedback:** attendees [summary, method, n] · client [summary] · team [summary] · suppliers [summary]
**What worked and must be kept:** [the things to deliberately repeat, which debriefs usually forget to record]
**Into the next brief** — written as instructions
1. [specific instruction] — owner [name]
2. [specific instruction] — owner [name]
## Quality Checks
- [ ] Objectives and numbers are reviewed before any discussion of how it felt
- [ ] The actual timeline is reconstructed against the plan
- [ ] Each problem is classified as felt-bad or was-bad
- [ ] Root causes point at earlier decisions, not at the moment of failure
- [ ] Individual accounts were collected before the group session
- [ ] Supplier notes are specific enough to be useful at next procurement
- [ ] What worked is recorded, not only what failed
- [ ] Fixes are written as instructions into the next brief, with owners
## Anti-Patterns
- **Debriefing on feelings alone.** The stressful and the harmful are not the same set.
- **Fixing symptoms.** The AV failure was a March procurement decision; changing the cable supplier fixes nothing.
- **Group discussion first.** Produces one story, usually the most confident person's.
- **'Supplier was fine.'** Useless as evidence a year later.
- **Recording only failures.** What worked is how you keep it working.
- **A lessons-learned document nobody opens.** If it is not in the next brief, it did not happen.
- **Debriefing three weeks later.** Detail is gone, and only the emotional peaks remain.
## Example Trigger Phrases
- "Run a debrief for last week's conference"
- "Write an event wrap report for the client"
- "How do I stop the same problems happening at every event?"
- "Capture lessons learned from our launch event"
- "What should we change for next year's gala?"
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!