event-debrief

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 Show more Installs 1.3K Repository samber/dev-even…r-skills GitHub Stars 2 First Seen Sep 13, 2026 Security Audits Gen Agent Trust Hub Pass Socket Pass Snyk Pass