samber/dev-event-organizer-skills已通過檢查
SKILL DETAIL
event-debrief
samber/dev-event-organizer-skills/event-debrief
Run the organizing team's own internal retrospective on one finished edition of a technical event - the blameless frame, the reconstructed timeline, what went well split from what went poorly, what fired reconciled against the risk register, budget plan and run of show, team-health findings, and dated lessons-learned entries each carrying an owner and a due date. Use whenever asked to run a post-event debrief, a post-mortem or a retrospective after a conference, meetup or hackathon, review an edition against the goals the team set, build a lessons-learned log, or publish a public recap. Do NOT use to collect participant feedback - use samber/dev-event-organizer-skills@event-feedback - or for trends across editions - use samber/dev-event-organizer-skills@event-continuous-improvement.
安裝量 · 234查看來源
Installation
npx skills add https://github.com/samber/dev-event-organizer-skills --skill event-debrief
技能檔案
SKILL.md
最近同步 · 2026年10月18日
evals/evals.json›
{
"skill_name": "event-debrief",
"evals": [
{
"id": 1,
"prompt": "I co-organize PixelForge Summit, a 350-person indie game-dev conference in Leeds. This year's edition ended eight days ago and honestly nothing went wrong - talks ran on time, the budget landed where we planned it, zero incidents. The three of us on the core team are completely wiped out. My co-organizer says a debrief is only worth running when something actually breaks, like an outage post-mortem at work, so we should skip straight to planning, which kicks off in about five weeks. Is he right? And if not, what's the lightest version we could get away with?",
"expected_output": "A recommendation to hold the debrief anyway, explaining that incident-postmortem severity gating does not transfer to events, with a lightweight single-session or pre-read format sized to a three-person exhausted team, a date set immediately, and exhaustion itself logged as a finding.",
"files": [],
"expectations": [
"Recommends holding the debrief despite nothing going wrong, explicitly rejecting the idea that a debrief is gated on something breaking",
"States that the severity threshold from incident/outage postmortem practice does not transfer to recurring events",
"Justifies the debrief for a quiet edition by naming the risk that practices which worked but go unnamed get silently dropped next edition",
"Recommends setting and calendaring the debrief date immediately, before the team disperses, rather than deferring the scheduling decision",
"States that no standard interval after the event exists and proposes a concrete date anyway",
"Recommends a lightweight depth rung (single session, or written pre-read plus one session), not per-track or multi-track formats",
"Removes both track-based depth options entirely for the three-person team rather than merely ranking them lower",
"Names the team's exhaustion as a finding of the debrief itself, not merely a scheduling constraint to work around",
"Warns against manufacturing action items to look thorough, and allows an explicit 'no action, because [reason]' as a complete outcome",
"Requires every log entry to carry a named owner and a due date, or an explicit no-action",
"Treats the planning start in five weeks as the debrief's deadline and recommends writing open items into next edition's plan",
"Runs what-went-well and what-went-poorly as two separate passes with the well pass first, and does not compare this edition against previous editions"
]
},
{
"id": 2,
"prompt": "TrailStack Conf (400 attendees, single day) ended Saturday and I'm turning our raw team notes into the lessons log. Here's what we wrote down: 1) Registration was a total disaster, Priya was overwhelmed, the queue went out the door and the first talk started 10 minutes late - Priya grabbed two floor volunteers at 9:15 to clear it. We need better volunteers next year. 2) The AV guy kept screwing up mic handoffs in track B all afternoon. 3) The gluten-free lunch count was wrong; we flagged it and catering fixed it by 1pm. 4) Rain flooded the sponsor tent mid-morning and there was nothing anyone could do. Please turn these into our lessons-learned log and run a proper root-cause analysis on each one so we really understand them.",
"expected_output": "A dated log where each finding becomes a three-part entry (what happened, what was done in the moment, what changes next edition) written about conditions and systems rather than Priya or the AV operator, with named owners and dates, categories that route each finding, an accepted empty middle part for the rain, and root-cause escalation refused for all or nearly all entries.",
"files": [],
"expectations": [
"Writes each finding as a three-part entry: what happened, what was done in the moment, what changes next edition",
"Registration entry describes the structural condition (e.g. one staffed position against the arrival curve) rather than Priya being overwhelmed",
"Replaces evaluative adjectives like 'disaster' with observable facts such as queue reach and the 10-minute late start",
"Middle part of the registration entry preserves the improvised response (two volunteers pulled off floor duty at 9:15) so next edition can judge whether it worked",
"Rewrites 'we need better volunteers' into a concrete mechanism (e.g. sizing the desk against the arrival curve, a named float role) with a named owner and a due date",
"AV finding names the handoff process or briefing/checks, not the operator as a person",
"Rain/tent entry keeps an explicitly empty middle part ('nothing could be done during the event') instead of inventing an in-the-moment response",
"Declines to run root-cause or 5-Whys analysis on every entry, keeping entries deliberately shallow",
"If any deeper analysis is allowed, it is capped at one or two findings and gated on recurrence, structural cost, and the obvious fix being symptomatic",
"Sorts entries into gap categories such as nobody-owned-it, known-risk-no-treatment, first-time failure, or checklist miss",
"Routes the rain finding to the risk register as a new unscored risk category rather than proposing a tent fix as the whole answer",
"Uses the ownership/staffing category to route the registration finding toward a team-structure fix",
"Every entry describes gaps and systems, never a person, and the log is dated"
]
},
{
"id": 3,
"prompt": "Cascade DevDays is a 600-person conference in Portland; our debrief is Thursday. I have our risk register (12 scored risks), the planned budget, and the run of show in front of me. What happened: our keynote speaker cancelled the night before - that was risk #3 and the backup speaker list worked; the venue wifi died for two hours, which was never on the register; catering came in $6,800 over plan, AV came in $1,200 under, and sponsorship sold $4,000 below plan. Track A ran 25 minutes long all afternoon because transitions ate time. We never collected an attendee survey this year. In the debrief I want to re-score the whole risk register, set next year's catering budget, and rewrite the run of show so every transition gets 10 minutes. Can you prep all that for Thursday?",
"expected_output": "A debrief prep that refuses to re-score the register, re-budget, or rewrite the cue sheet, and instead produces four reconciliation handbacks: risks in three buckets, a variance table ordered by absolute size with one-sentence causes, run-of-show divergences as observations, and the missing attendee-feedback input named and skipped.",
"files": [],
"expectations": [
"Declines to re-score the risk register inside the debrief and hands back a reconciliation to the risk-management owner instead",
"Risk handback uses three buckets: fired with treatment held, fired with treatment failed, and fired but unscored",
"Places the keynote cancellation in the fired-and-treatment-held bucket since risk #3's backup list worked",
"Places the two-hour wifi outage in the fired-and-unscored bucket and frames it as a new risk category, not a fix",
"Identifies the unscored bucket as the most valuable output of the risk check",
"Budget check is actual-versus-planned variance ordered by largest absolute variance first: catering $6,800, then sponsorship $4,000, then AV $1,200",
"Attaches a one-sentence cause per material variance drawn from price move, volume miss, unplanned line, or estimate that was always wrong",
"Declines to set next year's catering number; the variance table is handed to the budget owner without proposed next-edition figures",
"Run-of-show output is a list of divergences as observations (Track A 25 minutes long, transitions eating time), not a rewritten cue sheet with 10-minute transitions",
"States that revising the cue sheet belongs to the run-of-show owner, not the debrief",
"Names the missing attendee feedback summary as a reconciliation that cannot be run, and skips it rather than reconstructing participant sentiment from memory",
"Does not propose surveying or contacting attendees now to fill the gap",
"Each reconciliation is routed to its owning sibling process, separate from the team's own dated lessons log"
]
},
{
"id": 4,
"prompt": "OrbitJS Mini-Conf just finished its fourth annual edition two weeks ago. My co-organizer wants the debrief document to open with charts comparing ticket sales, sponsor revenue and attendee satisfaction against editions two and three, so we can finally see the trend. One problem: we never wrote goals down this year - back in January we vaguely talked about 250 attendees and breaking even. We ended at 218 and lost about 900 euros. And we have no satisfaction number at all, we didn't measure anything. How should the debrief handle all of this?",
"expected_output": "A debrief scoped to this single edition's dated log, refusing the cross-edition trend charts, reviewing the reconstructed January goals with an explicit 'reconstructed, not measured' label, recording satisfaction as unmeasurable as a finding in itself, and keeping the goals verdict internal.",
"files": [],
"expectations": [
"Declines to build the cross-edition trend comparison inside the debrief and scopes the output to one edition's dated log",
"States that aggregating across editions belongs to a separate continuous-improvement process which receives this log",
"Reviews against the reconstructed January goals (250 attendees, break even) but explicitly labels the goals section reconstructed, not measured",
"Marks satisfaction as unmeasurable and treats the fact nobody instrumented it as a finding in its own right",
"Records attendance 218 against 250 and the roughly 900 euro loss as missed against the reconstructed goals",
"Keeps the goals verdict strictly internal: a signal about this edition's own targets, never a go/no-go on whether the event should continue",
"Routes any demand-relevant signal (attendance shortfall, financial miss) to the market-fit owner as a signal, not a conclusion",
"Records the two-week gap between doors closing and the debrief as a signal to note, not a target to hit",
"States zero orphan entries as the single binary pass threshold for the log",
"Proposes instrumenting satisfaction (or writing goals down) for next edition as an action item carrying a named owner and a due date",
"Checks whether edition three's action items were actually done as a carry-through input, while leaving the trend claim to the continuous-improvement process"
]
},
{
"id": 5,
"prompt": "During the KernelCraft Days debrief last night, our ops lead Tomás - a volunteer, though two of us organizers are paid staff at the sponsoring company - said flat out that he's done: he ran registration, volunteer coordination AND the sponsor desk this year with no backup and he's burnt out. My co-organizer wants two things: (a) a section in our public retrospective post honestly saying 'we overloaded Tomás and he nearly quit', to show accountability, and (b) an agenda item at next year's debrief to figure out how to redistribute his workload. She also thinks Tomás simply took on too much and should have said no earlier. How do we handle this?",
"expected_output": "The finding restated structurally (one person held three roles with no backup), routed to the team-structure owner now with an owned, dated entry rather than parked for next year, kept out of the public post by name, with the mixed-team blameless frame delivered by the reporting-line holder.",
"files": [],
"expectations": [
"Rejects the framing that Tomás took on too much or should have said no, calling that a personal-failing framing that ends the conversation",
"Restates the finding structurally: one person held three roles with no backup",
"Routes the workload redesign to the team-structure owner rather than solving the redistribution inside the debrief",
"States the debrief surfaces and routes team-health findings but does not redesign the team",
"Advises against publishing the finding with Tomás named; personnel-sensitive findings remove the public options entirely rather than just ranking them lower",
"Notes that a criticised volunteer simply stops volunteering, and that this loss is invisible in the log",
"References precedent that events historically published this kind of self-assessment only at shutdown (e.g. JSConf EU's closing statement or !!Con's burnout statement) and that the debrief exists to surface it years earlier",
"On a mixed volunteer/staffed team, the blameless frame must be stated most explicitly and delivered by whoever holds the reporting line, because from anyone else it does not bind",
"Notes that a volunteer sharing the room with paid staff or their day-job manager changes what the volunteer will say about workload",
"Writes the finding into the log now as a three-part entry with a named owner and a due date, instead of deferring it to next year's debrief agenda",
"Does not assign the workload-redistribution action item to Tomás himself",
"States that nothing said in the room becomes a performance judgment and only agreed written findings leave it"
]
},
{
"id": 6,
"prompt": "ForgePoint Conf (900 attendees, Berlin) ended last week. Two things happened very publicly: a speaker was removed mid-talk after a code of conduct violation - half the audience saw it and it's all over social media - and our badge printing collapsed for the first hour of day one. Now the team is split on what to publish. Our community manager wants a full transparency report with the incident details, our sponsor lead wants to publish nothing and let it blow over, and I just want the usual recap with photos. We also have an internal finding that tears into our badge vendor pretty harshly. What should we publish, and who gets to decide?",
"expected_output": "A ranked publication decision: silence rejected because the incident was visible, the transparency report gated on the code-of-conduct pipeline's anonymisation sign-off and its irreversibility named, the vendor-blaming finding kept out of or rewritten for the public post, and the decision made by the team in the room while findings are fresh.",
"files": [],
"expectations": [
"Frames the choice as a ranked menu of postures (nothing published, recap only, recap plus retrospective, plus transparency report) rather than a binary publish-or-not",
"Rejects publishing nothing given the incident was publicly visible, because silence would read as a cover-up - the stated condition that promotes the transparency report",
"Gates the transparency report on the code-of-conduct pipeline's own sign-off on anonymisation, and on the reports actually having been resolved",
"States that a published incident description cannot be unpublished",
"Specifies the transparency report as an anonymised account of reports and how each was handled, with no identifying detail about the speaker",
"Names recap plus retrospective as the default posture, or anchors it to the published recap-plus-retrospective precedent shape",
"Notes the retrospective's marginal drafting cost is low because findings already exist in three-part form",
"Flags the harsh badge-vendor finding: publicly naming a supplier can collide with non-disparagement terms and will reach a supplier the event may want next year, so it is rewritten or kept internal",
"The publication decision is made by the team, in the room, while findings are fresh - not taken away as one person's homework",
"Distinguishes the exposure each rung carries (photo consent for a recap, contractual for a retrospective, code-of-conduct sign-off for a transparency report) from mere drafting effort",
"Cites recap-level publishing as endorsed practice (results blogging described as optional but strongly recommended)",
"Allows the badge-printing failure itself to appear in the public retrospective as what went wrong plus what changes, since it is operational rather than personnel- or incident-sensitive"
]
},
{
"id": 7,
"prompt": "I'm facilitating the debrief for Solder & Code Festival (two-day hardware conference, 11 named roles, mostly volunteers plus Ingrid, our paid event manager) next Wednesday - we have 90 minutes. My plan: kick off with a quick dot-vote on the top 3 things that went wrong, spend an hour fixing those three, then wrap with any positives if there's time left. Two of the track leads already disagree about whether Saturday's workshop-room chaos was a check-in problem or a scheduling problem, so I figured I'd settle that debate first thing to clear the air. Oh, and our volunteer lead can't make Wednesday at all. Can you tighten this agenda for me?",
"expected_output": "A rebuilt agenda: blameless frame first and spoken by Ingrid, chronological timeline reconstruction from artifacts before any judgment, the workshop-room dispute marked disputed rather than settled, a dedicated what-went-well pass before what-went-poorly, reconciliations, an explicit team-health slot, owners-and-dates, publication decided in the room, and the absent volunteer lead's written input collected beforehand.",
"files": [],
"expectations": [
"Rejects opening with a vote on what went wrong; the session opens with the blameless frame stated out loud",
"On this mixed volunteer/staffed team, Ingrid as the reporting-line holder delivers the frame herself",
"Timeline reconstruction of the edition comes before any analysis, judgment, or fixing",
"Timeline is built from artifacts first (run of show, comms channel history, ticketing, photo timestamps) with memory only filling gaps",
"The workshop-room disagreement is recorded as disputed rather than settled first thing, and the dispute itself is treated as a finding that nobody knew what was happening at that moment",
"What-went-well runs as its own explicit pass before what-went-poorly, not as leftover time at the end",
"Justifies the well-first ordering by the risk that an unnamed working practice gets quietly dropped next edition",
"Agenda includes a reconciliation segment checking what happened against the documents that already exist (risk register, budget, run of show, pre-set goals)",
"Team health appears as an explicit agenda item rather than being left to whoever is brave enough to raise it",
"Agenda ends with an owners-and-dates segment where every entry gets a named person and a date or an explicit no-action",
"Publication posture is decided in the session by the team, not taken away afterwards",
"The absent volunteer lead submits written input beforehand, or their absence is named as a coverage gap - part of the event only they saw",
"Recommends a written well/poorly pre-read from every named role so the session discusses rather than collects, preventing the first speaker from anchoring the room"
]
},
{
"id": 8,
"prompt": "BrewCity JS Conf runs every October. Last year's debrief produced 15 action items in a doc - 'improve speaker AV checks', 'start sponsor outreach earlier', that kind of thing. The owner column mostly says 'team' and the deadline column says 'before next year'. Twelve months on we've completed exactly zero of them and we repeated at least three of the same mistakes this edition. Planning for next October opens in three weeks. My co-organizer's fix is to buy a project-management tool and run monthly review meetings all year. What actually went wrong, and what should we do differently this time?",
"expected_output": "A diagnosis of orphan action items (owner 'team', date 'before next year' tracked by nothing), the repeated mistakes tagged as incomplete fixes from last edition, a default of named owner-and-date per entry plus carry-over into the planning document opening in three weeks, and the year-round tool-plus-meetings idea pushed back on as a standing job.",
"files": [],
"expectations": [
"Diagnoses the core failure as orphan action items: an owner of 'team' and a deadline of 'before next year' are tracked by nothing",
"Requires each entry to carry one named person and a concrete date, or an explicit 'no action, because'",
"Tags the three repeated mistakes as incomplete fixes from last edition and identifies that category as the most valuable one, only existing from the second edition onward",
"Recommends the default combination: owner-and-date on every entry plus carrying open items over into next edition's plan",
"Open items are written into next edition's work-back plan as real tasks handed to the planning process, not left as log lines",
"Uses the three-week planning start to promote the carry-over hard: the plan opens now, so items go in the same week",
"Pushes back on the tool-plus-monthly-meetings proposal as the highest-effort option: a standing job rather than an appointment, promoted only when a year-round tracker already exists or findings must resolve between editions",
"Positions a mid-cycle check-in as one dated calendar entry reserved for short-fuse items (vendor conversation, refund, deposit), not a recurring meeting series",
"Applies the binary zero-orphan check: re-read the log line by line and either assign each entry or close it explicitly",
"Records the 0-of-15 carry-through rate as an input while leaving the trend across editions to the continuous-improvement process",
"States that a log full of unowned entries is meeting notes, not a lessons-learned log",
"Contrasts costs when steering the choice: carry-over and check-in cost roughly a calendar entry and under half an hour, versus the tracker as ongoing maintenance"
]
}
],
"trigger_queries": [
{ "query": "Our conference wrapped on Sunday - how do we run the post-mortem and who should be in the room?", "should_trigger": true },
{ "query": "design the post-event attendee survey for our conference", "should_trigger": false },
{ "query": "run a retrospective for our hackathon that ended yesterday", "should_trigger": true },
{ "query": "what questions should we ask attendees in the feedback form", "should_trigger": false },
{ "query": "we need a lessons-learned session for the organizing team after DevFest", "should_trigger": true },
{ "query": "how do we get more responses on our post-event speaker survey", "should_trigger": false },
{ "query": "post-event debrief agenda for my meetup team", "should_trigger": true },
{ "query": "compare attendance and satisfaction across our last three editions", "should_trigger": false },
{ "query": "should we publish what went wrong at our conference publicly or keep it internal?", "should_trigger": true },
{ "query": "trend our sponsor revenue over the past five years of the conference", "should_trigger": false },
{ "query": "nothing really broke this year - is a debrief still worth an evening?", "should_trigger": true },
{ "query": "which problems keep recurring across every edition of our meetup series", "should_trigger": false },
{ "query": "how do I turn our team's own notes after the event into something next year's edition actually uses", "should_trigger": true },
{ "query": "build a year-over-year improvement dashboard for our event series", "should_trigger": false },
{ "query": "who needs to be in the room for our event post-mortem", "should_trigger": true },
{ "query": "build a risk register for next year's conference", "should_trigger": false },
{ "query": "our volunteer team is exhausted - how do we review this edition without burning them out further", "should_trigger": true },
{ "query": "score likelihood and impact for a venue cancellation risk", "should_trigger": false },
{ "query": "one of our organizers said they're completely burnt out during the review - what do we do with that", "should_trigger": true },
{ "query": "what treatments should we plan for our top event risks next year", "should_trigger": false },
{ "query": "last year's debrief produced fifteen lessons and we did none of them - what went wrong with the process", "should_trigger": true },
{ "query": "draft next edition's conference budget", "should_trigger": false },
{ "query": "help me write up what went well and what went poorly for the organizing team", "should_trigger": true },
{ "query": "model next year's P&L for our hackathon", "should_trigger": false },
{ "query": "we want a blameless retro for the conference crew", "should_trigger": true },
{ "query": "help me negotiate the venue contract for next year's event", "should_trigger": false },
{ "query": "how soon after the event should the team retro happen", "should_trigger": true },
{ "query": "write the minute-by-minute cue sheet for event day", "should_trigger": false },
{ "query": "compare what actually happened on the day against our run of show and write up the differences", "should_trigger": true },
{ "query": "design the escalation chain for the live show", "should_trigger": false },
{ "query": "capture the catering budget overrun in our post-event review", "should_trigger": true },
{ "query": "restructure our volunteer team roles for next year", "should_trigger": false },
{ "query": "check which risks from our register actually fired during the event", "should_trigger": true },
{ "query": "how many volunteers do we need per track next edition", "should_trigger": false },
{ "query": "template for lessons-learned entries with owners and due dates", "should_trigger": true },
{ "query": "is there still demand for our conference or should we retire it", "should_trigger": false },
{ "query": "the event's over and everyone wants to move on - how do I get the team to reflect before we lose the details", "should_trigger": true },
{ "query": "build the work-back plan for next year's edition", "should_trigger": false },
{ "query": "we just finished our first hackathon, what should we write down before the team scatters", "should_trigger": true },
{ "query": "write a code of conduct for our conference", "should_trigger": false },
{ "query": "should our conference publish a transparency report about the code of conduct incident", "should_trigger": true },
{ "query": "set up the incident response process for CoC reports during the event", "should_trigger": false },
{ "query": "how do we decide between a public recap and keeping our findings internal", "should_trigger": true },
{ "query": "turn this year's conference talks into blog posts", "should_trigger": false },
{ "query": "structure a 90-minute wrap-up meeting for the organizing committee", "should_trigger": true },
{ "query": "when should we publish the talk recordings from our conference", "should_trigger": false },
{ "query": "the team keeps blaming one person for the registration mess in our review - how do I keep it constructive", "should_trigger": true },
{ "query": "should we run a roadshow or a single-city user conference next year", "should_trigger": false },
{ "query": "how do I reconstruct the event timeline for our review when memories already disagree", "should_trigger": true },
{ "query": "write a postmortem for last night's production outage", "should_trigger": false },
{ "query": "everyone remembers the day differently - how do we settle what actually happened before we judge it", "should_trigger": true },
{ "query": "run a blameless postmortem for our API incident", "should_trigger": false },
{ "query": "what do we do with action items nobody owns after the retro", "should_trigger": true },
{ "query": "SEV1 incident retrospective template for my SRE team", "should_trigger": false },
{ "query": "post-mortem for a meetup that had zero incidents", "should_trigger": true },
{ "query": "facilitate our sprint retrospective next Tuesday", "should_trigger": false },
{ "query": "the sponsor booth setup was chaos - should the debrief fix the floor plan or just log it", "should_trigger": true },
{ "query": "retro format ideas for my scrum team", "should_trigger": false },
{ "query": "write the retro doc for this year's edition so next year's team inherits it", "should_trigger": true },
{ "query": "run a retrospective on our Q3 product launch", "should_trigger": false },
{ "query": "we're handing the conference to a new organizing team - what should this year's review look like", "should_trigger": true },
{ "query": "marketing campaign post-mortem for our spring promo", "should_trigger": false },
{ "query": "how deep should we go on each finding in the event review - do we 5-whys everything?", "should_trigger": true },
{ "query": "put together the post-event report we owe our sponsors", "should_trigger": false },
{ "query": "did we hit the goals we set for this edition - how do we review that honestly", "should_trigger": true },
{ "query": "write thank-you emails to send attendees after the conference", "should_trigger": false },
{ "query": "review this edition against the goals we set back in January", "should_trigger": true },
{ "query": "plan the email sequence announcing next year's dates", "should_trigger": false },
{ "query": "our event went badly and I need a proper internal post-mortem that doesn't become a blame session", "should_trigger": true },
{ "query": "how do we reduce no-shows at the next meetup", "should_trigger": false },
{ "query": "attendee survey results are in - how do we combine them with our own team notes for the wrap-up", "should_trigger": true },
{ "query": "we're planning our first conference edition, where do we start", "should_trigger": false },
{ "query": "it's the final edition of our conference - do we still do a retrospective and publish anything", "should_trigger": true },
{ "query": "pick the date for next year's conference", "should_trigger": false },
{ "query": "how do I log 'we should fix this next year' items so they actually happen", "should_trigger": true },
{ "query": "design the CFP for next year's edition", "should_trigger": false },
{ "query": "quick debrief format for a two-person organizing team", "should_trigger": true },
{ "query": "how should we price sponsor packages for next year", "should_trigger": false },
{ "query": "what should the organizing team measure about its own post-event review", "should_trigger": true },
{ "query": "write the sponsorship prospectus for the next edition", "should_trigger": false },
{ "query": "the venue messed up lunch - how do we write that up in the lessons log without torching the relationship", "should_trigger": true },
{ "query": "improve the attendee experience at our next conference", "should_trigger": false },
{ "query": "our conference retro keeps turning into a performance review of the ops lead", "should_trigger": true },
{ "query": "what session formats should we use next year", "should_trigger": false },
{ "query": "what leaves the debrief room and which team gets which output", "should_trigger": true },
{ "query": "help me plan the after-party and social program", "should_trigger": false },
{ "query": "we skipped the retro two years running - convince my co-organizers it's worth an evening this time", "should_trigger": true },
{ "query": "figure out why ticket sales dropped this year and fix our marketing", "should_trigger": false }
]
}
references/field-precedent.md›
# Field precedent
What published organizer guides and event recaps say about post-event review, and why the session mechanics elsewhere in this skill come from a different lineage.
## What organizer guides publish
- **Write the Docs Prague 2017** published a "Recap and Retrospective" combining the attendee survey with the team's own retrospective - "a few main points that we received, which also reflect our own retrospective results" - and a code-of-conduct transparency report. Write the Docs Day Australia followed the same pattern. Both are dated 2017. **Write the Docs's own subsequent editions did not repeat the pairing.** Its own site publishes a "thanks and recap" post after nearly every later edition (Prague 2018-2020, Portland 2018-2021, Australia 2018 and 2020, Vilnius 2019) - each still carrying the recap and the code-of-conduct transparency report, but the explicit retrospective section is gone. Prague 2018's post narrows the whole retrospective down to one soft line: "We also had some interesting feedback on some things we might improve for next time." The 2017 pairing stayed a one-off inside its own source, not just externally.
- **MLH's organizer guide** names a retrospective as one line on a post-event checklist, opened by three questions.
- **DevOpsDays' organizing guide** has one post-event review line, scoped to code-of-conduct incidents only: "After the event, review any CoC violations and assess how they were handled." Its separate survey line adds "blogging about the results is optional, but strongly recommended."
- **MLH's `Organizer-Resources/keeping-records.md`** names three things - when ("a 1-hour event reflection with your team a few days after the event"), who ("your team", then "next year's organizing team"), and what artifact (a reviewed document, kept in a shared folder) - plus three opening questions about attendee feedback, planning challenges, and useful resources.
- **The Kubernetes Contributor Summit's own organizing team publishes a dated `RETRO.md` after each edition**, in the open-source `kubernetes/community` repository, spanning five editions from 2018 through late 2019 (2018-05, 2018-12, 2019-05, 2019-06, 2019-11). Each follows this skill's own "what went well" / "what could be improved" split, with points attributed to named organizers, attendance figures, and unresolved items carried forward. This is a genuinely current, repeated (not one-off) post-2017 precedent for the retrospective half of a debrief - but it differs in kind from Write the Docs's artifact: it is raw team retrospective notes made public by an open-governance norm, not a polished external recap written for an attendee audience, and it carries no code-of-conduct transparency component.
- **The Summer Institutes in Computational Social Science (SICSS) publish an annual, structured post-mortem** covering every partner site, spanning 2018, 2020, 2021 and 2022 editions, stating up front that each entry covers "how the Institute was run, what each site thinks worked well, and what each site will do differently next time" - the same three-part shape this skill's own lessons-learned entries use, sourced independently of Write the Docs. SICSS sits adjacent to, rather than inside, developer conferences (a computational social science and data science research program), and its post-mortem is a multi-site comparative document rather than a single recap.
- **Peter-Paul Koch ("PPK"), organizer of Fronteers and CSS Day**, publishes a "Conference Organiser's Handbook" with a dedicated Evaluation section naming concrete debrief mechanics for a developer conference: hold it "at the end of your conference" the same day, call all organisers together as a group, and "go through the various stages of organising in order, ask everyone for their feedback, and make a list." The scope is explicitly bounded - "concentrate on things that went wrong just before or during the conference," since this "is not the time to make changes to the concept," which gets its own separate annual-planning meeting instead ([quirksmode.org](https://quirksmode.org/coh/conference.html)).
- **Howard Givner, writing for the PCMA Institute**, describes his own post-event debrief practice from running the event "Paint The Town Red": exchange topic lists with the client beforehand, the way HR departments share written performance reviews ahead of the review meeting, so neither side is ambushed in the room; then split the agenda into "Big Picture" (the event's goals and whether they were met) ahead of "Production Details," so the room doesn't spend as long dissecting a gift bag as it does on whether the event actually worked ([pcmainstitute.org](https://pcmainstitute.org/the-debrief-from-hell/)).
- **Bizzabo's own guide** adds a timing data point without new mechanics: a debrief "should happen as soon as possible after an event ends," while the experience is still fresh, framed as the meeting where "team leaders analyze the show's performance and compare results" ([bizzabo.com](https://www.bizzabo.com/blog/event-debrief-questions)).
None of these sources publishes a figure for how many debrief lessons actually get acted on. Quoting one from software engineering would present a borrowed number as domain practice, which is why SKILL.md § Measurement sets its own pass threshold instead.
## Why the session mechanics come from elsewhere
Organizer guides mostly say little to nothing about debrief format. One clear exception: PPK's handbook names when (immediately, same day), who (all organisers), and format (walk the stages of organizing in order, compile feedback into a list) - but nothing past that. It has no reconciliation against a risk register or budget, no three-part entry structure, no owner-and-date discipline on action items, and no blameless-frame script. The rest of the mechanics in SKILL.md - the rest of when to hold the debrief, who attends, how the log reaches the next plan - still come from the SRE incident-postmortem lineage, adapted to an asset that runs once a year rather than a service that breaks on a weekday.
references/lessons-learned-entries.md›
# Lessons-learned entries
The format, the two sourced examples, a negative counterpart, the categories that make entries sortable, and the narrow case for going deeper than three parts.
## The three-part entry
Every finding is written as three parts and nothing more:
1. **What happened** - the observable fact, described as a condition or a system, never as a person.
2. **What was done in the moment** - the response during the event, or an explicit "nothing could be done during the event".
3. **What changes next edition** - the concrete change, plus its owner and due date.
This depth is not a compromise. It is the depth of the Write the Docs Prague 2017 retrospective, the most complete published artifact in this field, and it is deliberately shallow: most event findings need a fix and an owner, not a causal chain.
## The two sourced examples
Both are from the Prague 2017 "Recap and Retrospective" post, quoted in substance.
**Vegetarian lunch mixup, day one.**
- What happened: the vegetarian lunch order did not match what attendees needed on the first day.
- In the moment: identified as lunch started, raised with the venue immediately, venue acknowledged the mistake.
- Next edition: "continuously working with the venue to improve and broaden menu options", and continuing to monitor.
**Uncomfortable noise level during unconference sessions.**
- What happened: unconference sessions ran at a noise level attendees found uncomfortable.
- In the moment: nothing - it could not be fixed mid-event.
- Next edition: "made a careful note of this potential issue and will make the necessary adjustments to the venue layout".
Notice what neither entry does: no root cause, no blame, no severity score, no five layers of why. Notice also that the second one openly records that nothing could be done on the day. An entry with an empty middle part is a complete entry, and pretending otherwise pushes teams toward inventing a response they did not have.
## A negative counterpart
> Registration was a disaster. Sam was overwhelmed and the queue was out the door. We need better volunteers next year.
Four failures in three sentences:
- "A disaster" is an adjective, not an observation.
- "Sam was overwhelmed" names a person where the finding is structural.
- "Better volunteers" is a wish with no owner, no date and no mechanism.
- Nothing records what was done at 9:15 that morning, so next edition's team cannot tell whether the improvised fix worked.
The same finding, written properly:
- What happened: the registration desk had one staffed position against roughly 200 arrivals inside the first thirty minutes; the queue reached the building entrance and the first session started nine minutes late.
- In the moment: two volunteers were pulled off floor duty at 09:15, which cleared the queue by 09:40 and left the main room unstaffed for that period.
- Next edition: size the desk against the arrival curve rather than headcount, and roster a named float role for the first hour. Owner: the volunteer lead. Due: at roster build, six weeks before doors.
## Categories, so entries sort into fixes
Sort each finding by the gap that let it reach the debrief. This taxonomy maps real failure modes:
- **Nobody owned it** - the work existed and no name was attached to it.
- **Known risk, no treatment** - it was on the risk register and nothing was actually put in place.
- **First-time failure mode** - genuinely new; nobody could have scored it. This one goes to the risk register as a new category rather than as a fix.
- **Incomplete fix from last edition** - it is in last edition's log, marked done, and it recurred. The most valuable category in the whole list, and the one that only exists from edition two onward.
- **Checklist or review miss** - a process existed and the step was skipped.
Sorting by category is what turns a flat list into a routing decision:
- "nobody owned it" → team-structure finding
- "known risk, no treatment" → risk-register finding
- "checklist miss" → run-of-show or planning finding
The category tells you which sibling receives it.
## What-went-well entries
Same three parts, inverted: what worked, what made it work, and what has to be deliberately preserved next edition. The third part is the one that matters - a practice that worked because one person quietly did it every year is a bus-factor finding wearing a compliment.
## When to go deeper than three parts
Escalate exactly one or two findings per edition to a 5-Whys, and only when all three of these hold:
- The finding recurred, or would recur by default rather than by chance.
- Its cost is structural - money, safety, a person leaving, an audience segment not coming back - not an inconvenience.
- The obvious fix addresses the symptom and the team can feel that it does.
Everything else gets three parts. Forcing five layers onto a catering mixup burns the room's attention before it reaches the finding that needed it, and produces a document whose depth no longer signals anything.
When the deeper pass points at the standing team's design or at an unscored risk category, stop at the diagnosis and route it. This skill surfaces those findings; it does not redesign the team or rewrite the register.
references/reconciliation-and-session-agenda.md›
# Session agenda, reconciliations, handover
How the session runs, the four checks against documents that already exist, and what leaves the room.
## Session agenda
Timings are for the default single-session rung. MLH schedules "a 1-hour event reflection with your team a few days after the event" and opens it with three questions about attendee feedback, planning challenges, and useful resources.
The segment breakdown below sits inside that hour. Scale these timings to your team's pace; they are a pacing guide, not measured intervals.
| Segment | Roughly | What happens |
| ---------------- | ------- | ------------------------------------------------------------------------------------ |
| Frame | 5 min | The blameless statement, out loud. Who is here, what leaves the room, what does not. |
| Timeline | 20 min | Chronological reconstruction. No judgment yet. |
| What went well | 15 min | First, and not as a formality. |
| What went poorly | 25 min | Observations, not verdicts. |
| Reconciliations | 20 min | The four checks below, against the documents in the room. |
| Team health | 10 min | Explicitly on the agenda, so it is not left to whoever is brave. |
| Owners and dates | 15 min | Every entry gets a name and a date, or an explicit no-action. |
| Publication | 10 min | Decided here, by the team, not taken away as homework. |
## The blameless opening, said out loud
Adapt the wording; keep all four moves. Read it rather than paraphrasing it - the point is that everyone hears the same sentence at the same time.
> We are reconstructing what happened, not deciding who is at fault. The question this session asks is what conditions allowed something, never who caused it. Everything that went wrong here went wrong inside a system we all built, mostly at the end of a long day. Nothing said in this room becomes a performance judgment, and nothing leaves it except the findings we agree to write down.
Two additions by team type:
- **Volunteer team** - add that nobody is here on work time and that saying "I could not keep up with this" is a finding about the workload, not about them.
- **Staffed or mixed team** - whoever holds the reporting line says the frame themselves; coming from anyone else it does not bind, and a manager silently present is read as an evaluator by default.
Enforce it the first time it slips, immediately and lightly: restate the observation without the name. One uncorrected "you dropped this" costs the rest of the session.
## Timeline reconstruction
Walking the sequence before analysing it is what stops the loudest memory from becoming the record.
1. Two granularities, in order: the planning cycle at whatever resolution matters (usually milestone by milestone), then the event days hour by hour.
2. Build it from artifacts first - the run of show, the comms channel history, the ticketing timeline, photo timestamps - and from memory second. Memory fills gaps; artifacts set the spine.
3. Mark anything the room disagrees on as disputed rather than resolving it. A disputed step is itself a finding: nobody knew what was happening at that moment.
4. Mark the gaps too. "Nobody in this room knows what happened at the sponsor tables between 14:00 and 16:00" tells you who was missing from the debrief.
5. Only once the sequence stands does anyone say whether a step was good or bad.
## The four reconciliations
Each is a check against a document that already exists, owned by a sibling skill. Each produces a handback, not a rewrite. If a document does not exist, say so and skip the check rather than reconstructing it from memory.
**Against the risk register.** Three questions:
- which scored risks actually materialised
- whether each treatment held
- what fired that nobody had scored
Hand back a list in three buckets: fired-and-treatment-held, fired-and-treatment-failed, fired-and-unscored. The third bucket is the valuable one - it is a new risk category, not a fix. Re-scoring the register is `samber/dev-event-organizer-skills@event-risk-management`'s job, not yours.
**Against the planned budget.** Line-by-line actual versus planned, largest absolute variance first. For each material variance, one sentence on cause:
- a price move
- a volume miss
- an unplanned line
- an estimate that was always wrong
Hand back the variance table with those causes. Do not propose next edition's numbers.
**Against the run of show.** Where did the real day diverge from the written one:
- segments that ran long
- a role that was never actually staffed
- an escalation that went to the wrong person
- a transition that ate a talk's time
Hand back the divergences as observations. The cue sheet's revision belongs to `samber/dev-event-organizer-skills@event-run-of-show`.
**Against the goals the team set.** Whatever was written down before the event:
- attendance
- financial outcome
- satisfaction
- incident count
- a diversity or first-time-speaker target
Hit, missed, or unmeasurable - and be willing to write unmeasurable, since a goal nobody instrumented is itself a finding. If no goals were written down, reconstruct what they would have been and label the whole section reconstructed, not measured. Keep this strictly internal: it answers whether this edition hit its own targets, never whether the event still has a market.
## Why surface team health at finding severity, not shutdown severity
Two of this field's best-known events published this kind of self-assessment only at shutdown.
- **JSConf EU, 2019 closing statement** - itemised what became unmanageable: "over 1600 attendees in total, 60+ flights and 100+ hotel stays to book, 120 scholarships... the cost of all this exceeds one million Euro."
- **!!Con, co-founder statement, June 2024** - "after !!Con 2022, the team was burned out and needed to take a year off."
Both examples appeared at shutdown. A debrief is where the same assessment should surface years earlier, while the finding is still small enough to route rather than absorb.
## Handover packet
One dated document leaves the debrief, plus four routed items. Name each recipient explicitly so nothing sits unclaimed.
- **The dated lessons-learned log** - every entry in three parts, each carrying an owner and a date or an explicit no-action, each tagged with its category. Goes to `samber/dev-event-organizer-skills@event-continuous-improvement`, which owns every trend claim across editions.
- **The three risk buckets** → `samber/dev-event-organizer-skills@event-risk-management`.
- **The variance table** → `samber/dev-event-organizer-skills@event-budget`.
- **The run-of-show divergences** → `samber/dev-event-organizer-skills@event-run-of-show`.
- **The team-health findings, phrased structurally** → `samber/dev-event-organizer-skills@event-team-structure`. "One person held three roles with no backup", never "they took on too much".
- **Any signal the demand verdict should weigh** - a sponsor renewal below goal, a return rate below goal - → `samber/dev-event-organizer-skills@event-market-fit`, as a signal and not as a conclusion.
- **Open action items**, once next edition's plan opens → `samber/dev-event-organizer-skills@event-planning-timeline`, as real tasks with slots rather than log lines.
If your harness has persistent memory, store:
- the log
- the goals it was measured against
- the open items with owners and dates
- the routing list
Next edition's debrief then opens on last edition's unfinished items, which is the one input nobody can reconstruct a year later.
SKILL.md›
---
name: event-debrief
description: Run the organizing team's own internal retrospective on one finished edition of a technical event - the blameless frame, the reconstructed timeline, what went well split from what went poorly, what fired reconciled against the risk register, budget plan and run of show, team-health findings, and dated lessons-learned entries each carrying an owner and a due date. Use whenever asked to run a post-event debrief, a post-mortem or a retrospective after a conference, meetup or hackathon, review an edition against the goals the team set, build a lessons-learned log, or publish a public recap. Do NOT use to collect participant feedback - use samber/dev-event-organizer-skills@event-feedback - or for trends across editions - use samber/dev-event-organizer-skills@event-continuous-improvement.
license: MIT
metadata:
author: Samuel Berthe
version: "1.1.0"
---
# Event Debrief
You run the organizing team's retrospective on one finished edition: the meeting, the reconstruction, the findings, and the log that reaches next edition's plan. Internal-facing only - nothing here reaches an attendee, a speaker or a sponsor.
**Run it every edition, unconditionally.** The SRE incident-postmortem lineage this skill borrows from gates a postmortem on a severity threshold (SEV1/SEV2, an outage over fifteen minutes); that gate does not transfer. A quiet edition where nothing broke still gets a debrief - the goal is improving a recurring asset, not containing an incident. "It went fine, let's skip it" is the failure this rule exists to prevent.
Five things arrive already decided. Read them, reconcile against them, never reopen them:
| Sibling | Owns | You do |
| ----------------------- | --------------------------------------------- | ----------------------------------------------------------------------------------------- |
| `event-feedback` | Collecting from attendees, speakers, sponsors | Consume its summary, never survey or write to participants |
| `event-risk-management` | Taxonomy, scoring, treatments | Check what fired against it, hand back a reconciliation |
| `event-budget` | P&L, next edition's numbers | Compare actual vs. planned, hand back the variance |
| `event-run-of-show` | Day-of execution | Log what broke as raw input, never re-diagnose |
| `event-market-fit` | Whether the concept still meets demand | Surface whether this edition hit the goals _this team_ set, as a signal, never a go/no-go |
Upstream boundary: **trends across editions are not yours.** You produce one edition's dated log; `event-continuous-improvement` aggregates editions - comparing this one to the last two duplicates its whole reason to exist.
## What the field actually publishes about this
Published organizer guides give this a line or two at most. The mechanics that follow instead - when to hold the debrief, who attends, how the log reaches the next plan - come from the SRE incident-postmortem lineage, adapted to an asset that runs once a year rather than a service that breaks on a weekday. See [references/field-precedent.md](references/field-precedent.md) for the sourced detail.
## Interview
Ask one question at a time, multiple-choice where possible. Questions 6 to 8 exist because the menus below diverge sharply on time-to-effect, durability and effort; the default ordering cannot be picked for the user without them.
1. Which edition just ended, when did doors close, how many days ago? Decides debrief vs. archaeology.
2. What goals did the team set _before_ the event, in its own words? If unwritten, say so - the review becomes reconstructed, not measured.
3. Who held a named role, and who can be in the room? A debrief missing the volunteer lead misses the half of the day only they saw.
4. Which of the four inputs already exist: feedback summary, risk register, planned budget, run of show? Each missing one is a reconciliation you can't run.
5. Volunteer-run or staffed? Changes who can safely say what and who can be given an action item.
6. When does next edition's planning actually start? That date is this skill's deadline.
7. One-off, final, or recurring for years? A closing and a compounding edition want opposite things from the same menus.
8. Effort ceiling: hours left, and what state the team is in - honestly. An exhausted team is the first finding, not a scheduling problem to route around.
9. Is leadership handing over after this edition, and does the event run as one unit or as several cities under a shared brand?
10. How many code-of-conduct reports did this edition receive, how many were resolved, and were any visible enough that the community already knows?
11. Is this event public, or private/NDA-bound?
12. Does the team already run a year-round tracker for something else?
## Who is in the room and what they are paid
The axis that changes this skill's output is who is in the room and what they are paid - it decides what can be said and who can be handed a task. **Volunteer-run**: no employment relationship buffers the conversation, so candor is cheaper, but no manager absorbs an action item, and a criticised volunteer simply stops volunteering - a loss invisible in the log. **Staffed**: carry-through is structurally better since action items land on someone whose job includes them, but the debrief drifts toward performance review unless the blameless frame is stated and enforced explicitly. **Mixed** (the common case): state the frame most explicitly here - a volunteer and their day-job manager in the same room changes what the volunteer will say about workload.
## Workflow
1. Run the interview. Pick the depth rung before booking anything.
2. **Set the date immediately, hold it soon.** No standard interval exists; propose one and calendar it before the team disperses.
3. **Open with the blameless frame, out loud, in the room** - the question is _what conditions allowed this_, never _who caused this_. Findings describe gaps and systems, never people.
4. **Reconstruct the timeline before any analysis.** Walk the edition chronologically. Reconstruction first, judgment second - a room jumping to opinions relitigates the loudest memory instead of the actual sequence.
5. **Separate well from poorly as two explicit passes.** Run "well" first - a practice that worked and goes unnamed is one quietly dropped next edition.
6. **Reconcile against what exists**: risk register, planned budget, run of show, Q2's goals. Four checks, four outputs, each to its owning sibling. Checklists: [references/reconciliation-and-session-agenda.md](references/reconciliation-and-session-agenda.md).
- If the team keeps a KPI shortlist (2-3 KPIs, each with an owner and an action - defined in `samber/dev-event-organizer-skills@event-continuous-improvement`), read this edition's value of each against its declared threshold here. Never add KPIs in the debrief; a number with no owner and no action is the long dashboard nobody re-reads.
- If the team scores a self-rated "impact intensity" per event, score it now, by at least two organizers independently, on the scale fixed before the season. Record disagreement instead of averaging it.
- **Capture outcomes.** List what has already come out of the edition - projects started, collaborations, companies founded, jobs found - with the source of each, and hand the list to the outcome log in `samber/dev-event-organizer-skills@event-continuous-improvement`. Nearly every hackathon edition can produce at least one company; outcomes like that are invisible in a findings-only log. Expect more to surface months later; this is the first entry, not the full count.
7. **Surface team-health findings and route them without solving them.** Exhaustion, a role only one person could do, an unsized workload - structural findings for `event-team-structure`, not yours to fix.
8. **Write each finding as a three-part entry**: what happened, what was done in the moment, what changes next edition - deliberately shallow. Format and escalation criteria: [references/lessons-learned-entries.md](references/lessons-learned-entries.md).
9. **Give every open entry an owner and a due date, or close it explicitly.** No orphans - an entry with no owner is a wish, not a lesson. If no action is needed, write "no action, because" rather than manufacturing one.
10. **Decide the publication posture** as a team, in the room, while findings are fresh.
11. **Hand the log to `event-continuous-improvement`** as one dated document, each reconciliation to its owning sibling, and stop.
If your harness has persistent memory, record:
- the dated log itself
- the goals this edition was measured against
- the KPI shortlist values, the impact-intensity scores, and the outcomes captured
- every action item with its owner and due date
- which findings were routed to which sibling
Next edition's debrief then opens with last edition's open items instead of a blank page - and that carry-over list is the single input `samber/dev-event-organizer-skills@event-continuous-improvement` cannot reconstruct later.
Every ranking below is a default, not a law; it shifts with context and with who executes it. Where a constraint deletes a rung, strike it from that menu's axis lines too - a rung surviving in the ordering survives in the reader's head and comes back as scope. Re-rank all three menus against what you already know about this team:
- A team whose members run sprint retrospectives at work buys the deeper depth rungs far more cheaply than the effort axis assumes.
- An event with a published-recap tradition already sits at the publication menu's default.
- A team that already keeps a shared tracker running year-round makes the tracking menu's starved option nearly free, because it is an existing habit rather than a new standing job.
- A team where one person holds three roles has already produced the finding that the depth menu is trying to buy.
## Debrief depth
Ranked menu - findings that actually change next edition, bought per unit of the team's remaining energy. All three orderings are judgment rather than a published standard: organizer guides prescribe no debrief format.
- effort (hours, calendar coordination, facilitation): `multi-track written review > per-track sessions > written pre-read plus one session > one session`
- value (findings surfaced that would otherwise be lost): `multi-track written review > per-track sessions > written pre-read plus one session > one session`
- efficiency: `written pre-read plus one session > one session > per-track sessions > multi-track written review`
**Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations - clean only by construction, and by-construction is never a pass.** Value and effort are the same list, so one mechanism blocks all six pairs: whichever rung surfaces more costs strictly more team-hours. No third axis blocks or rescues a pair; the efficiency line rests on the argument that follows.
Efficiency inverts the middle of the list because the two rungs on top of value are also the two on top of effort. Hours are the binding constraint right after an event, and per-track coordination scales worse than the detail it buys.
- **One session** - a single 60-90 minute meeting, notes captured live into a dated log.
- **Written pre-read plus one session** (default) - every named role submits a well/poorly list beforehand; the session discusses rather than collects. Buys the quiet organizer's findings and stops the first speaker anchoring the room.
- **Per-track sessions** - separate debriefs per workstream, then one consolidation session. Promote when named workstream leads worked genuinely independently - no single room holds everyone who knows what happened.
- **Multi-track written review** (starved rung) - per-track sessions plus a written document per track, consolidated into a full edition report. Tops value and effort, so efficiency never picks it. **Promotion condition, keyed to Q9**: a leadership handover (incoming team inherits a written record) or a franchise/multi-city event whose sibling organizers read each other's reviews.
When the "team" is one or two people, **delete both track-based rungs** rather than demoting them - five track sessions for two people is ceremony.
## The retro table
A single meeting produces minutes; a **standing table kept open across the cycle** produces something a meeting cannot - room for dissent to survive past the moment it was raised. Structure it with five columns - _Who / Observation / Agrees / Disagrees / Comments_ - and let anyone add a row at any time, not only during the scheduled session. Agreement and disagreement are columns, not a comment thread that quietly closes; a row stays open until the team is actually ready to close it, never just until the meeting ends.
Preserve some findings as raw testimony rather than folding every voice into one summary line. Two people describing the same practice in contradictory terms - one calling it too rare, another too frequent - is real signal a synthesized average would erase into "seems fine." Where a topic drew genuinely split reactions, keep both quotes on the table instead of picking the louder one.
**A documented refusal is itself the artifact, not a failure to act.** Writing "no action, because [reason]" directly onto the row is what stops an identical suggestion resurfacing next edition as if it had never been considered - the same no-action discipline step 9 already asks for action items, applied here to the table itself. Do the same for a call that genuinely split the team: record both positions on the row rather than letting one side win by attrition, so the debate stays available to whoever revisits it.
One recurring split worth a row of its own: who judges this edition's impact, the team or the attendee questionnaires. Organizers disagree on exactly this. Keep both readings on the row - the team's impact-intensity score beside the questionnaire result - rather than letting either overwrite the other.
## Publication posture
Ranked menu - community trust and accountability bought per unit of drafting, review and exposure. This is the one menu here carrying real exposure, so it gets a compliance-cost axis.
- effort (drafting, anonymisation, sign-off): `recap plus retrospective plus transparency report > recap plus retrospective > recap only > nothing published`
- value (trust, accountability pressure that makes the fix happen, and a reusable public artifact): `recap plus retrospective plus transparency report > recap plus retrospective > recap only > nothing published`
- efficiency: `recap plus retrospective > recap only > recap plus retrospective plus transparency report > nothing published`
- compliance cost (review triggered, reversibility spent): `recap plus retrospective plus transparency report > recap plus retrospective > recap only`; publishing nothing carries none.
**Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations - clean only by construction, and that is not a pass.** Value, effort and compliance cost all run in one order: the rung that buys more trust is strictly worse on both cost axes, including against "nothing published," which loses on value rather than winning anything for free. The check catches nothing; what follows is argument.
Efficiency still favors the retrospective: its findings already exist in three-part form by step 8, so the marginal cost is two paragraphs, not new analysis. Publishing nothing ranks last on efficiency despite costing nothing, because zero over zero never wins a ratio, even where it is the correct choice for other reasons.
The compliance ordering is not a rewrite of the effort ordering:
- **Recap** - exposure is a photo-consent check.
- **Retrospective** - exposure is contractual: a finding naming a venue or a caterer can collide with a non-disparagement clause and will certainly reach a supplier you want next year.
- **Transparency report** - exposure is categorically different again: it needs the code-of-conduct pipeline's own sign-off on anonymisation, and a published incident description cannot be unpublished.
- **Nothing published** - findings stay in the team's log.
- **Recap only** - what happened, numbers, photos, thanks; no findings. DevOpsDays endorses this much: blogging results is "optional, but strongly recommended."
- **Recap plus retrospective** (default) - Write the Docs Prague 2017's shape: recap plus a short section naming what went wrong and what changes next edition.
- **Recap plus retrospective plus transparency report** (starved rung) - full Prague 2017 artifact, adding an anonymised account of code-of-conduct reports and how each was handled. Tops value, effort, and compliance cost, so efficiency never picks it. **Promotion condition, keyed to Q10**: reports were actually resolved and `event-code-of-conduct`'s pipeline signs off on the anonymisation, or an incident was visible enough that silence would read as a cover-up.
**Delete condition, keyed to Q11**: for a private event, or findings that are personnel-sensitive or under confidentiality, delete every public rung rather than demoting them.
## Action-item tracking rigour
Ranked menu - lessons that actually reach next edition, per unit of standing overhead. Ownership discipline matters: every action item needs a named owner and a date, or it vanishes.
This does not assume a ticketing system exists; all rungs work with whatever the team has. The rungs are judgment.
- effort (setup, calendar, maintenance): `standing tracker with a review cadence > plan carry-over == mid-cycle check-in > owner and date on the entry`
- value (share of findings that change something): `standing tracker with a review cadence > plan carry-over > mid-cycle check-in > owner and date on the entry`
- efficiency: `owner and date on the entry > plan carry-over > mid-cycle check-in > standing tracker with a review cadence`
The effort tie is argued, not indecision: both the check-in and the carry-over cost one calendar entry and under half an hour, with nothing to build or maintain between the debrief and that date - unlike the standing tracker, which is a job rather than an appointment. They are not equal on value: the carry-over lands items in the document the team actually works from, so with effort tied, it wins the ratio.
- **Owner and date on the entry** - every entry carries a named person and a date, or an explicit "no action, because". Near-zero marginal effort. Stops orphaning, nothing more.
- **Mid-cycle check-in** - one dated check a few weeks out, confirming short-fuse items happened (vendor conversation, refund, apology, deposit chased).
- **Plan carry-over** - every open item written into next edition's work-back plan as a real task, handed to `event-planning-timeline`.
- **Standing tracker with a review cadence** (starved rung) - a persistent tracker reviewed on a recurring cadence between editions. Tops value and effort, so efficiency never picks it. **Promotion condition, keyed to Q12**: a year-round tracker already exists for something else, or findings routed structural work to `event-team-structure` (which happens between editions by definition).
**Default: owner and date on every entry, plus plan carry-over.** Add the mid-cycle check-in when items have a fuse shorter than the planning cycle. Move to the standing tracker when findings must resolve before planning starts (a legal-entity change, a succession gap).
For a final or one-off edition, **delete the carry-over and the standing tracker** rather than demoting them, keeping only the owner-and-date rule.
## Re-ranking against the interview answers
Say which answer moved which option, per menu, rather than silently reordering.
| Interview answer | Depth | Publication | Tracking |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Q6 - planning starts within weeks | Promotes both single-session rungs, demotes both track-based rungs (they need cross-lead calendar coordination the deadline doesn't allow) | Barely moves, and say so - a recap isn't on the planning critical path, so let it slip rather than cutting the debrief short | Promotes the plan carry-over hard - the document opens now and items can go in the same week |
| Q7 - final or one-off edition | Demotes the written review unless a successor organisation will read it | Promotes the retrospective and the transparency report - a closing edition's public account is the only record the community gets, which is why the JSConf EU and !!Con statements are still cited | Deletes the carry-over and the standing tracker |
| Q7 - compounding, recurring edition | - | - | Promotes the carry-over and the standing tracker |
| Q8 - low effort ceiling / exhausted team | Deletes both track-based rungs outright | Demotes the transparency report, since anonymisation is where its hours go, and keeps the recap | Demotes the standing tracker and leaves the default untouched - the point of a default costing one field and one paste |
## Failure modes
- **Blame in the room.** One "you dropped this" reframes the session as a performance review, and the next finding never gets said; on a volunteer team the person simply does not come back, and that loss is invisible in the log. State the frame at the top and hold it out loud the first time it slips.
- **Skipping the debrief because the edition went fine.** Severity-gating is the one mechanic that explicitly does not transfer from the incident-postmortem lineage. A quiet edition still has practices worth naming before they are dropped.
- **Orphan action items.** An entry with an owner of "we" and a due date of "next time" is not tracked by anything. Assign a person and a date, or close it explicitly as no-action.
- **Manufacturing action items to look thorough.** The inverse failure, named directly in incident-postmortem practice: if a finding needs no action, say so.
- **5-Whys on every entry.** Five causal layers on a lunch mixup is over-engineering, and it crowds out the one finding that genuinely warranted it. The published precedent runs three shallow parts per finding with no root-cause treatment at all.
- **Re-diagnosing the day.** Rewriting the cue sheet, re-scoring the risk register or re-modelling the budget inside the debrief takes work from the sibling that owns it and produces a version nobody else will adopt. Hand back a finding, not a redesign.
- **Treating burnout as a personal failing.** "They took on too much" is not a finding; "one person held three roles with no backup" is. The first ends the conversation, the second routes to a structural fix.
- **Deferring the debrief until nobody remembers.** Six weeks out, the timeline is reconstructed from the loudest three memories and the quiet failures are gone. If the date has already slipped that far, say so and downgrade the claim the log makes rather than pretending the reconstruction is complete.
- **Trending across editions.** Comparing this edition's numbers to the last two is `samber/dev-event-organizer-skills@event-continuous-improvement`'s job. Produce one dated log; let the aggregation happen where it belongs.
## Measurement
Published guidance settles when, who, and what artifact a debrief produces, but leaves open how many of its lessons get acted on - see [references/field-precedent.md](references/field-precedent.md) for the sourced detail. This skill sets **exactly one pass threshold**, on the only thing fully inside the team's control:
- **Zero orphan entries** (binary). Every entry in the log has a named owner and a dated deadline, or an explicit "no action, because"; iterate until it holds by re-reading the log line by line and either assigning or closing each one. A log failing this is not a lessons-learned log, it is meeting notes.
The rest are signals to record, not targets to hit:
- **Days from doors closing to the debrief**. Record yours so the team can see the trend across editions.
- **Named-role coverage**: how many people who held a named role were in the room or submitted written input, out of the total. A low share explains a thin log better than any other number.
- **Carry-through rate** (only measurable from edition two onward): how many of last edition's action items were actually done. Record it as an input; the trend belongs to `samber/dev-event-organizer-skills@event-continuous-improvement`.
- **Outcomes captured at the debrief** (self-set): projects, collaborations, companies, jobs. A first count only; later ones arrive through the outcome log.
## Invocation examples
- "Our conference wrapped on Sunday. How do we run the post-mortem, and who should be in the room?"
- "We've got the attendee survey results back - how do we turn those plus our own notes into something the next edition actually uses?"
- "Should we publish what went wrong publicly, or keep it internal?"
- "Last year's debrief produced a list of fifteen lessons and we did none of them. What went wrong with the process?"
- "One of our organizers said in the debrief that they're completely burnt out. What do we do with that?"
- "Nothing really broke this year. Is a debrief still worth an evening?"
Expected output:
- a dated lessons-learned log of three-part entries, each with a named owner and a due date or an explicit no-action
- four reconciliations handed to the siblings that own the risk register, the budget, the run of show and the demand verdict
- a routed list of team-health findings
- a publication decision with its reason
- a stated handover to `samber/dev-event-organizer-skills@event-continuous-improvement`
## References
- [references/lessons-learned-entries.md](references/lessons-learned-entries.md) - the three-part entry format with both sourced worked examples and a negative counterpart, the "why it slipped through" categories, and the narrow criteria for escalating a single entry to a 5-Whys.
- [references/reconciliation-and-session-agenda.md](references/reconciliation-and-session-agenda.md) - the session agenda with a blameless opening script, the timeline reconstruction method, the four reconciliation checklists with their handback formats, two published team-health examples, and the handover packet to event-continuous-improvement.
- [references/field-precedent.md](references/field-precedent.md) - what published organizer guides say about post-event review, and why this skill's session mechanics come from the SRE incident-postmortem lineage instead.