智能体工作流

event-debrief

samber/dev-even…r-skills

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.

  • 5859 次安装
  • 4 星标
  • 收录于

安装命令

npx skills add https://github.com/samber/dev-event-organizer-skills --skill event-debrief

SKILL.md

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