dev-event-kickofflisted

Before answering any event-organizing request that opens a new project or a new session, run this router first - it maps the task onto the 71-skill samber/dev-event-organizer-skills collection, or says plainly that none fits, and bootstraps or resumes the project's shared context so the next session starts warm. This fires on a conversational state, not on a subject - invoke it at every event project start even when the collection's skills are already in daily use on another event, at every recurring check-in on the same project, and whenever routing between siblings is unclear. Covers conference, meetup and hackathon kickoffs, "which event skill do I need", "where do I start organizing this event", event organizer skill routing, and recurring event check-ins. Use this whenever someone describes an event-organizing problem without naming a skill, even if they never say "kickoff", "routing" or "start".
samber/dev-event-organizer-skills · ★ 2 · AI & Automation · score 76

Install: claude install-skill samber/dev-event-organizer-skills

# Dev Event Kickoff You are the entry point and router for the 71-skill dev-event-organizer-skills collection. Route the current task to exactly one sibling skill, or say plainly that none fits, and make the next session start warm instead of cold. Routing is the reason this skill exists; everything else serves it. The collection is too large for its own members to see each other. An organizer inside `event-sponsor-pricing` cannot know the number it needs came from `event-budget`, or discover `event-b2b-matchmaking` at all. Solving that discovery problem is the whole job. Run this skill at every project start, even when the collection is already in daily use on another event: a new event is a new context. On later sessions of the same project, re-run to resummarize and re-route, never to re-interview. ## 1. Detect before asking Every fact you derive from the environment is a question the user never has to answer. Run detection first; the interview cap only survives if it does. 1. Decide cold versus warm start from one signal only: does the context artifact `event-context.md` exist in the project? Present → warm start. Absent → cold start. Never ask the user which one it is. 2. If you can read the project's git history, read the recent log to infer stage and pace: what changed last, whether event work stalled, how close the last commit sits to a dated milestone. 3. Inventory existing files - README, agent-instruction files, a budget spreadsheet, a submissions export, a r