dev-event-kickoff

{
  "skill_name": "dev-event-kickoff",
  "evals": [
    {
      "id": 1,
      "prompt": "We're three engineers at Braukette (a brewing-software startup) and the company just approved a small budget to maybe run a hackathon for our user community next spring - nothing exists yet, no date, no venue, and honestly we haven't even decided whether it's worth doing at all. None of us has organized anything before, and this is a one-off experiment we can each give a few hours to. Tell me everything you need to know from me, and then give me the full plan: challenge themes, prize ideas, judging, the works.",
      "expected_output": "A cold-start kickoff session: detection first, a capped one-question-at-a-time interview limited to what the message did not already answer, a route to an existence-check skill, a short-list restricted to existence-check and spine classes, a single kickoff re-invocation routine, and a context artifact - explicitly not a full hackathon plan.",
      "files": [],
      "expectations": [
        "The session is treated as a cold start decided from the absence of a context artifact, without asking the user whether it is a new or resumed project.",
        "The response does not re-ask facts the message already gave: the event does not exist yet, the company funds it, and the effort ceiling is a one-off with hours only.",
        "Any interview questions are asked one at a time with multiple-choice options offered, never as one batched questionnaire dumped in a single message.",
        "The interview stays within a seven-question cap.",
        "The immediate route is an existence-check skill (event-market-fit or corporate-event-strategy), not a logistics skill like venue, budget, or marketing.",
        "corporate-event-strategy is surfaced as reachable, with its gate read from the stated fact that a company funds and owns the event.",
        "The short-list is restricted to existence-check and spine skills (format, date, timeline), consistent with the hours-only one-off effort ceiling.",
        "Sponsorship skills are absent from the short-list entirely, not parked at the bottom as a later step.",
        "Day-of operations skills (run of show, production, comms channels) are absent from the short-list.",
        "Each short-list entry names both the bottleneck it attacks and what the session costs, and the response states the list is ordered by value returned per unit of effort.",
        "At most one routine is proposed, and it is a recurring kickoff re-invocation check-in; no ticket-pace, sponsor, or go/no-go routines are proposed.",
        "The response creates, or explicitly commits to creating and updating before the session ends, an event-context.md context artifact recording the answers.",
        "The response does not deliver a full hackathon plan (challenge brief, prize structure, judging rubric) in this session, despite being asked for one."
      ]
    },
    {
      "id": 2,
      "prompt": "Here is event-context.md from our repo:\n\n# Event context\n_Last updated: 10 weeks ago_\n\n## Identity\n- Event: DuckConf, single-day systems conference. Edition 3; edition 2 ran last spring.\n- Funding model: volunteer community.\n\n## Format (the gate source)\n- Shape: single-day conference, single track, no workshop hours.\n- Delivery mode: in-person.\n\n## Dates\n- Doors: announced, about six months out. CFP closes in 11 weeks.\n\n## Money\n- Budget committed; break-even at 280 paid tickets; recorded in budget.md.\n\n## Programme\n- CFP open: 41 submissions in. No reviewers recruited. Grid not published.\n\n## State\n- In flight: CFP running.\n- Decided: single track; free livestream of the recordings.\n- Open: who reviews the submissions.\n- Constraints: doors date fixed; standing project, a few hours weekly.\n\n## Session log\n- (10 weeks ago) - kickoff -> routed to event-cfp-design -> call published.\n\nIt's been ten weeks since I touched this. What should I be working on?",
      "expected_output": "A warm-start session: no re-interview beyond the session goal, an exactly-5-line state summary, a route to talk selection (reviewer recruitment), a session-log line appended, fields patched not rebuilt, and a re-rank read from the artifact's constraints.",
      "files": [],
      "expectations": [
        "The session is treated as a warm start; the response does not re-ask format, edition, funding, or date questions already recorded in the artifact.",
        "At most one question is asked, and it is the goal of this session.",
        "A state summary of exactly 5 lines is produced.",
        "The summary lines cover: event identity and format, the date and where it sits, in-flight work, top open decision, and the active constraint.",
        "The immediate route is samber/dev-event-organizer-skills@event-talk-selection, matching the open decision of who reviews the 41 submissions before the CFP closes.",
        "The route is named in owner/repo@skill form.",
        "The response does not route to event-cfp-design: the call is already published and collecting submissions.",
        "A dated session-log line (goal, skill routed to, what changed) is appended to the artifact.",
        "The artifact is updated by patching only changed fields, not rebuilt from scratch.",
        "The short-list is re-ranked from the artifact's recorded constraints (fixed doors date, standing few-hours-weekly ceiling) without re-asking those questions.",
        "The response states which recorded answer or constraint moved which recommendation off its default place.",
        "Recurring-gated skills are treated as reachable with the gate read from the artifact's edition-3 record, not re-asked.",
        "Skills ruled out for this session are absent from the short-list rather than listed at the bottom."
      ]
    },
    {
      "id": 3,
      "prompt": "Kicking off a new project: our community, the Nimbus Users Group (about 2,000 members), decided to run some kind of annual gathering next fall. We keep going back and forth - maybe a two-day conference, maybe a hackathon, and my co-organizer really wants it hybrid so remote members can join. Can you help us design the hybrid streaming setup, shortlist venues for about 400 people, and figure out what prizes we should offer if we do the hackathon part?",
      "expected_output": "A single route to event-format-selection with a full stop: no hybrid design, no venue shortlisting, no prize advice, an explicit statement of which skill groups are suspended and why, and a commitment to record the format decision in the artifact once made.",
      "files": [],
      "expectations": [
        "The response routes to samber/dev-event-organizer-skills@event-format-selection as the single route for this session.",
        "The response does not provide hybrid streaming or production design guidance and does not route to hybrid-event-design.",
        "The response states that hybrid-event-design and virtual-event-production sit downstream of the format decision and must never be used to make it.",
        "The response does not route to event-venue-sourcing or begin shortlisting venues, because the delivery mode is unfixed and no room is confirmed to exist.",
        "The response does not give hackathon prize or cash-prize guidance while the hackathon shape is undecided.",
        "The response explicitly names which skill groups are suspended (the hackathon lane, the delivery-mode skills, the conference-scale rows) rather than silently omitting them.",
        "The suspended rows are described as unreachable until the format is fixed, not as absent from the collection.",
        "The response does not guess or assume a shape (for example proceeding 'assuming a conference') in order to give gated advice.",
        "No short-list drawn from gated rows is offered.",
        "The response commits to recording the format decision in the context artifact once it is made, so the next session reads the gate instead of re-asking.",
        "The route is named in owner/repo@skill form.",
        "The response does not itself decide between conference, hackathon, or hybrid in this session; it routes the decision."
      ]
    },
    {
      "id": 4,
      "prompt": "I'm the executive director of the Fjordwall Foundation, which runs FjordCon: edition 4, a two-day, two-track, in-person conference of around 900 attendees, doors on a fixed announced date about six months out, budget carried from last cycle with a revenue target on file. We have two funded full-time event staff. Our target sponsors close their annual marketing budgets at the end of January - six weeks from now - and sponsorship covered 60% of our costs last year, but we haven't started this cycle's motion at all. The CFP text isn't written yet and attendee marketing hasn't begun either. What order do we attack this in?",
      "expected_output": "A re-ranked short-list with the sponsorship sale promoted to the top because the sponsor budget window closes in six weeks, the six-skill sponsorship chain in dependency order, pricing anchored to the budget's revenue target, and the re-rank stated out loud.",
      "files": [],
      "expectations": [
        "Sponsorship sales work is placed first in the recommended order.",
        "The response explicitly ties that promotion to the closing sponsor budget window, stating that this deadline moved sponsorship off its default place.",
        "While promoting it, the response names sponsorship's cost honestly: a months-long motion running on a counterparty's calendar, the most expensive class rather than a cheap one.",
        "A sponsorship chain is presented in this order: value proposition, then pricing, then prospectus, then outreach, then agreement, then fulfillment.",
        "The chain links are named as skills in owner/repo@skill form.",
        "The chain is presented as dependency order, each link consuming what the previous produced, and the chain itself is not ranked by value or importance.",
        "Sponsor pricing is anchored to the revenue target taken from the event budget; the budget is consumed as an input, not re-set by pricing.",
        "The short-list contains between 5 and 8 entries.",
        "Each short-list entry names both the bottleneck it attacks and what the session costs.",
        "The stated ordering criterion is value returned per unit of effort, not lowest cost.",
        "CFP design appears in the output (short-list or not-now) but is not ranked ahead of the sponsorship work.",
        "If routines are proposed, the sponsor pipeline and renewal sweep is installed first, tied to the closing budget window.",
        "The re-rank is stated out loud: which stated fact moved which class, rather than a silently reordered list."
      ]
    },
    {
      "id": 5,
      "prompt": "Quick routing check for our conference project (TerraPipe Summit, edition 2, in-person, 3 tracks). Five questions, answer each: (1) we're adding a demo-day segment where local startups that already have shipped products pitch to a jury - is that the hackathon judging skill? (2) our platinum sponsor wants to run their own meetup in a bar near the venue the evening before - whose job is vetting and approving that? (3) another conference in our region proposed swapping newsletter mentions with us - same skill as question 2 or a different one? (4) we already have a shortlist of 12 dream speakers and now need to write the first invitation email; (5) the team keeps debating whether to hire our first paid coordinator - which skill decides whether we should at all, and which one writes the job posting once we decide?",
      "expected_output": "Five correct boundary-pair routes: startup-pitch-contest, event-side-event-coordination, cross-event-promotion, event-speaker-cold-outreach, and event-team-structure then dev-event-hiring, each with the declared-scope split stated.",
      "files": [],
      "expectations": [
        "Question 1 is routed to startup-pitch-contest, not to hackathon-judging.",
        "The split for question 1 is stated: hackathon judging covers work built during the event, while the pitch contest covers companies that existed before it.",
        "Question 2 is routed to event-side-event-coordination, since a third party wants to run a satellite around the event's dates.",
        "Question 2 is not routed to cross-event-promotion or event-media-partnerships.",
        "Question 3 is routed to cross-event-promotion, a reciprocal swap with another organizer's own event.",
        "Question 3 is not routed to event-media-partnerships, which covers barter with media outlets and communities rather than other organizers' events.",
        "Question 4 is routed to event-speaker-cold-outreach, the invitation to a speaker a shortlist already picked.",
        "Question 4 is not routed to event-speaker-sourcing, and the split is stated: sourcing stops at a ranked shortlist, outreach writes the invitation.",
        "For question 5, whether a first paid role is warranted at all is routed to event-team-structure.",
        "For question 5, the job posting and scorecard are routed to dev-event-hiring, conditional on team-structure's verdict saying hire.",
        "Every route is named in owner/repo@skill form.",
        "Each sub-question receives exactly one route decided from declared scope, and no skill name outside the collection's routing tables is invented."
      ]
    },
    {
      "id": 6,
      "prompt": "MarmotConf is the academic-flavored systems conference we're organizing (edition 1, in-person, Lyon). This year the committee wants two things: a peer-reviewed paper track where accepted papers get published as proceedings with DOIs, and the whole programme delivered in both French and English - parallel translated tracks and a bilingual MC. Which skills from the event collection do I load for each?",
      "expected_output": "Both requests named plainly as coverage gaps: no skill covers proceedings or a bilingual programme; the nearest skills (event-talk-selection, event-accessibility-inclusion) are not stretched to cover them, no skill is invented or promised, and the gaps land in the output's Gap section.",
      "files": [],
      "expectations": [
        "The response states plainly that no skill in the collection covers a peer-reviewed paper track ending in published proceedings.",
        "The response states that event-talk-selection reviews talk proposals for stage slots only, and does not stretch it to cover proceedings.",
        "The response states plainly that running the programme in two languages as a design choice is covered by no skill in the collection.",
        "The response states that event-accessibility-inclusion covers interpretation and captioning as access provisions on request, and does not stretch it into bilingual programme design.",
        "Neither gap is answered by promising a future skill or inventing a skill name.",
        "Both gaps are named explicitly as gaps rather than papered over with generic advice presented as a skill's output.",
        "No route names a skill outside the collection's routing tables.",
        "The response does not hand these two subjects off to a sibling collection (DevRel or platform), since neither belongs there.",
        "The response does not claim the collection covers the publication mechanics of proceedings (peer review to DOI).",
        "The response still performs kickoff project-state behavior - checking for or referencing the context artifact and cold-versus-warm state - rather than answering as a stateless Q&A.",
        "The output includes a distinct Gap statement or section carrying both uncovered subjects."
      ]
    },
    {
      "id": 7,
      "prompt": "PolarByte Days, edition 3: two-day in-person conference, doors announced on a fixed date about nine months out, venue contract signed last month with cancellation fees stepping up at 120, 90, and 45 days before the event, tickets on sale through our ticketing platform since last week, CFP closing in four months. I want you to set up automated recurring check-ins so nothing falls through the cracks - set up as many as it takes, I'd much rather over-monitor than miss something. Oh, and last year's reminder jobs are still configured somewhere.",
      "expected_output": "At most 4 routines, each shown as a dry-run with an output channel and a stop condition, anchored to the event's own calendar; the go/no-go review promoted ahead of each cancellation-fee rung, a ticket-pace check kept, previous-edition routines retired first, and the re-rank stated.",
      "files": [],
      "expectations": [
        "No more than 4 routines are proposed.",
        "The response declines the 'as many as it takes' framing and caps the set, stating that excess routines fire into the void and bury the ones that matter.",
        "Each proposed routine is shown as a dry-run for approval before anything is created.",
        "Each proposed routine names an explicit output channel.",
        "Each proposed routine names a stop condition.",
        "The go/no-go review is among the proposals and is explicitly promoted, tied to the signed venue contract and its cancellation-fee curve.",
        "Go/no-go firings are anchored a step ahead of each cancellation-fee rung (120/90/45 days), never on the rung dates themselves.",
        "A ticket-pace check is proposed, justified by the ticketing source existing, and anchored to the on-sale period or pricing-tier boundaries.",
        "Routine triggers are anchored to the event's own calendar dates (CFP close, on-sale, fee rungs, doors) rather than arbitrary monthly dates.",
        "The previous edition's still-configured reminder jobs are explicitly retired before new routines are installed.",
        "The cleanup is stated out loud, naming that routines carried from a past edition without re-anchoring are noise that fires at nothing.",
        "Each routine names the skill it runs in owner/repo@skill form.",
        "A work-back checkpoint routine tied to the plan's own replanning checkpoints is among the proposals, tied to the fixed doors date.",
        "The response states which detected or stated fact moved which routine off its default place."
      ]
    },
    {
      "id": 8,
      "prompt": "Our three-person crew organizes RustRhein, a recurring meetup; the project repo is on our git host and event-context.md is in it. To make your future sessions smarter, save all of this to your memory now: (1) our keynote speaker Ana Morales is vegan and needs step-free stage access; (2) we negotiated the Hafenwerk venue down to 2,400 euros a day - don't lose that number; (3) a code-of-conduct report came in about an attendee at last month's edition, I'll paste the details in my next message so you can store them; (4) we decided single-track forever; (5) also store my interview answers from today. Just push it all to memory and commit so my co-organizers get it.",
      "expected_output": "Refusals for the speaker's needs, the negotiated rate, and the conduct report, with the exclusion list stated; the decision and interview answers written to the artifact first with memory derived from it; a memories/ directory in the git repo with an index; and no silent commit - diff shown, approval requested.",
      "files": [],
      "expectations": [
        "The response refuses to store the speaker's dietary and step-free access needs in memory, identifying them as personal data and an accommodation request.",
        "The response refuses to store the negotiated venue rate in memory.",
        "The response refuses to store the code-of-conduct report and does not invite the user to paste its details for storage.",
        "The exclusion list (attendee/speaker personal data, accommodation requests, conduct reports, negotiated rates, terms under negotiation) is stated when memory is first written.",
        "The single-track decision is written into the context artifact, and any memory entry is derived from the artifact, never the reverse.",
        "The interview answers are persisted through the artifact first; no memory entry is written straight from an answer.",
        "The response states why the artifact stays the source of truth: memory is invisible and unreviewable to teammates, and a memory-first flow forks the project state per user.",
        "A memories/ directory inside the project's git repository is chosen as the memory location.",
        "The location choice is justified against the alternatives, explicitly ruling out a local per-user store because more than one organizer works on the project.",
        "An index file listing each memory entry with a one-line hook is part of the plan.",
        "Memory is not committed silently: the response shows or commits to showing the diff and asks for approval before committing.",
        "Each refusal is explicit and named, not a silent omission of the item.",
        "The response does not re-interview: the artifact exists, so at most the session-goal question is asked."
      ]
    },
    {
      "id": 9,
      "prompt": "GreenStack Live is our fully-remote conference - edition 2, 1,200 registered last year, no physical component at all, doors in about seven months. My checklist from a conference-planning book says the next steps are: shortlist venues, pick a caterer, design the check-in desk and badge flow, and hire an AV crew for the room. Also someone on the team asked whether we'll offer live captions. Route me.",
      "expected_output": "The four in-room checklist items rejected as unreachable for a virtual event with the gate reasoning stated, virtual-event-production named as the replacement, and the captions question routed to event-accessibility-inclusion, which still applies without a room.",
      "files": [],
      "expectations": [
        "The response does not route to event-venue-sourcing and states there is no venue to source for a fully virtual event.",
        "The response does not route to catering or hospitality work for this event.",
        "The response does not route the check-in desk and badge flow to the in-room attendee-experience skill.",
        "The response does not route to event-production for a room AV crew.",
        "The response states the reason: the virtual delivery mode closes the in-room gate outright, rather than merely omitting the four skills.",
        "The delivery, platform, and production needs are routed to virtual-event-production as the replacement for the closed in-room rows.",
        "The captions question is routed to event-accessibility-inclusion.",
        "The response states that accessibility still applies to a virtual event because its digital-access provisions need no room.",
        "virtual-event-production is not used to re-open the delivery-mode question; the mode is carried as an already-fixed gate.",
        "Routes are named in owner/repo@skill form.",
        "The gate is read from the stated fully-remote fact, not re-asked or re-decided.",
        "The inapplicable checklist items are rejected rather than partially followed: no venue shortlisting or caterer advice appears anywhere in the response."
      ]
    },
    {
      "id": 10,
      "prompt": "First edition of Composta Summit - a compost-tech developer conference, yes really - is in seven months, and nothing has ever run before. Three asks: (a) I read that serious events do 'continuous improvement' across editions, so set that up now so we're rigorous from day one; (b) a friend organizes a climate-tech meetup and offered to cross-promote with us, but I assume that kind of swap is only for established events with a track record?; (c) we're also weighing spinning up a monthly meetup series alongside the summit - which skill thinks that through? We definitely intend to run the summit every year.",
      "expected_output": "Continuous improvement deferred to not-now with an explicit unblocking condition; the cross-promotion assumption corrected because that skill is open to first editions; the second-property question routed to portfolio strategy on property count; first-edition promoted; intent to recur not treated as opening recurring gates.",
      "files": [],
      "expectations": [
        "The response declines to route to event-continuous-improvement now.",
        "The stated reason is that the recurring gate is about having a previous edition to read, not intent to repeat - a first edition has no debrief logs to compare.",
        "Continuous improvement is placed in a not-now list with an explicit unblocking condition (editions and their debriefs existing), rather than deleted or silently dropped.",
        "The response corrects the user's assumption for ask (b): cross-event-promotion is available to a first edition and is not recurring-gated.",
        "The response states why: the swap skill handles one-off boosts for a coming edition, and it is an acquisition lever a first edition can reach without a track record.",
        "Ask (b) is routed to samber/dev-event-organizer-skills@cross-event-promotion.",
        "Ask (c) is routed to samber/dev-event-organizer-skills@event-portfolio-strategy.",
        "The response states that the portfolio skill opens on property count - the day a team starts weighing a second property - whatever edition the flagship is on.",
        "event-first-edition is promoted or recommended for the flagship, tied to the stated first-edition answer.",
        "Cross-edition after-and-between entries (community building between editions, growth strategy, the trend read) are removed from the current short-list rather than listed low.",
        "Gates are read from stated facts, not inferred from the event's ambition or name.",
        "Routes are named in owner/repo@skill form.",
        "The stated intent to run the summit every year is not treated as satisfying the recurring gate."
      ]
    },
    {
      "id": 11,
      "prompt": "Fresh session on our repo for Kelpway Conf 2027. There's no event-context.md (we never made one), but the repo contains: budget-2027.xlsx committed last month with break-even at 410 tickets, schedule-grid.pdf published on the site two weeks ago (two days, three tracks, in-person, doors on a fixed date in about ten months), and venue-contract-signed.pdf. The git log shows steady commits until 19 days ago, then nothing. Get me going again - ask me whatever you need.",
      "expected_output": "Detection-first cold start: format and date read from the published grid, schedule design and venue sourcing deleted, risk management promoted by the signed contract, the budget treated as done, the stall read from git, and only the questions detection could not answer asked, one at a time.",
      "files": [],
      "expectations": [
        "The session is treated as a cold start because no context artifact exists, without asking the user which kind of start it is.",
        "The response does not ask the format question (shape, track count, delivery mode) - the published grid already fixes it.",
        "The response does not ask for the event date - it is read from the published grid.",
        "The published grid's existence removes event-schedule-design from the recommendations.",
        "The signed venue contract removes event-venue-sourcing from the recommendations.",
        "The signed venue contract promotes event-risk-management (go/no-go against the cancellation exposure) on the short-list.",
        "The committed budget is treated as making budget modelling near-free or already done, not recommended as a first task.",
        "The 19-day commit stall is read as a stall or pace signal and reflected in the session's state or routing.",
        "Interview questions are limited to what detection could not answer, and the total stays within the seven-question cap.",
        "Any questions are asked one at a time with multiple-choice options.",
        "An event-context.md artifact is created, or committed to before session end, recording the detected invariants (format, date, budget status, signed contract).",
        "The deleted skills (schedule design, venue sourcing) do not appear at the bottom of the short-list - they are removed entirely.",
        "Each short-list entry names the bottleneck it attacks and what the session costs."
      ]
    },
    {
      "id": 12,
      "prompt": "OtterForge Conf wrapped last Saturday - edition 5, 1,400 attendees, in-person, all talks recorded. Three things on my mind: (1) what's the right sequence now that it's over? Honestly I'm tempted to skip the attendee survey this year, people are tired of forms. (2) Our standing OtterForge talks YouTube channel has been dead for months, and separately the community wants a real developer-content and documentation push around the open-source tooling the conference is built on. (3) Next year we want a hackathon segment where teams build against our headline sponsor's public API - is that a platform question for a different skill collection? Route all of it.",
      "expected_output": "A post-event session: short-list reduced to the after-and-between class, the closing chain in dependency order with feedback kept first, the dormant channel routed to the podcast/channel skill, the docs push recommended to the DevRel sibling repo as a recommendation, and the sponsor-API hackathon question kept in-collection.",
      "files": [],
      "expectations": [
        "The finished-event answer reduces the current short-list to the after-and-between class alone.",
        "Marketing, sponsorship, on-the-day, and existence-check classes are deleted from the short-list, not listed at the bottom.",
        "A closing chain is presented in this order: event-feedback, then event-debrief, then event-content-repurposing, then event-continuous-improvement.",
        "The chain is framed as dependency order - each link handing its output to the next - and the chain itself is not ranked.",
        "event-feedback is kept as the first link despite the user's temptation to skip the survey, because the debrief and the trend read consume its output.",
        "event-continuous-improvement is treated as reachable, with the recurring gate read from edition 5 having prior editions.",
        "The dormant standing talks channel is routed to samber/dev-event-organizer-skills@tech-podcast-youtube-channel.",
        "The developer-content and documentation push is recommended to the samber/developer-relations-skills collection.",
        "That sibling-repo hand-off is framed as a recommendation, never a dependency; the collection stays usable standalone.",
        "The sponsor-API hackathon-challenge question is kept inside this collection and routed to hackathon-brief-design.",
        "The response states the boundary: event operations wearing platform vocabulary stays here, while a genuine public-API, SDK, or sandbox surface question would go to samber/developer-platform-skills.",
        "Routes are named in owner/repo@skill form.",
        "No skill name outside the collection's routing tables is offered as a route."
      ]
    }
  ],
  "trigger_queries": [
    { "query": "Start a new event project - we want to run our first hackathon next spring.", "should_trigger": true },
    { "query": "Design an event-driven architecture for our order service.", "should_trigger": false },
    { "query": "Run my event check-in.", "should_trigger": true },
    { "query": "What's the difference between event sourcing and CQRS?", "should_trigger": false },
    { "query": "Which event skill do I need? Sponsors keep asking what they actually get.", "should_trigger": true },
    { "query": "I'm speaking at a Go conference next month - help me structure my talk.", "should_trigger": false },
    { "query": "Where do I start? We have a date and a venue and nothing else.", "should_trigger": true },
    { "query": "Debug why my Node.js event loop is blocked.", "should_trigger": false },
    { "query": "The conference finished last week. What now?", "should_trigger": true },
    { "query": "Should our startup sponsor a booth at a big cloud conference this year?", "should_trigger": false },
    { "query": "Kick off planning for our company's first developer conference.", "should_trigger": true },
    { "query": "Set up AWS EventBridge rules to fan out S3 events.", "should_trigger": false },
    { "query": "We just decided to launch a monthly Kubernetes meetup in Denver. Set me up.", "should_trigger": true },
    { "query": "Grow our developer community Discord from 500 to 5,000 members.", "should_trigger": false },
    { "query": "New project: an internal AI hackathon for 80 engineers in Q2.", "should_trigger": true },
    { "query": "Our Kafka event consumers keep lagging - help me tune them.", "should_trigger": false },
    { "query": "I'm starting to plan a DevFest-style community event for our city, where do I begin?", "should_trigger": true },
    { "query": "Write the agenda for our sprint kickoff meeting on Monday.", "should_trigger": false },
    { "query": "Bootstrap an event project for a two-day API summit we're dreaming about.", "should_trigger": true },
    { "query": "Plan my sister's wedding reception for 120 guests.", "should_trigger": false },
    { "query": "We got budget approved to run a user conference next year. Let's start.", "should_trigger": true },
    { "query": "Add a click event handler to this React component.", "should_trigger": false },
    { "query": "Spin up the planning workspace for our first unconference.", "should_trigger": true },
    { "query": "Review my CFP submission before I send it to a Python conference.", "should_trigger": false },
    { "query": "Begin organizing a student hackathon at our university.", "should_trigger": true },
    { "query": "Track custom analytics events in our mobile app funnel.", "should_trigger": false },
    { "query": "I want to organize a tech meetup but I've never run one. Start me off.", "should_trigger": true },
    { "query": "Plan our open-source project's launch on Hacker News.", "should_trigger": false },
    { "query": "Weekly check-in on the conference project, what's changed and what's next?", "should_trigger": true },
    { "query": "Design the webhook event payload schema for our public API.", "should_trigger": false },
    { "query": "Resume the DevSummit project where we left off.", "should_trigger": true },
    { "query": "Which KubeCon sessions should I attend for platform engineering?", "should_trigger": false },
    { "query": "It's been a month since I touched the meetup planning - catch me up and re-route.", "should_trigger": true },
    { "query": "Kubernetes is flooding me with FailedScheduling events, diagnose it.", "should_trigger": false },
    { "query": "Pick up our hackathon project again, the context file is in the repo.", "should_trigger": true },
    { "query": "Improve our API documentation so developers stop churning.", "should_trigger": false },
    { "query": "Event check-in time. Read the context and tell me what today's session should attack.", "should_trigger": true },
    { "query": "Plan our booth staffing for the trade show we're exhibiting at.", "should_trigger": false },
    { "query": "Back from vacation - where does the conference planning stand?", "should_trigger": true },
    { "query": "Implement domain events in our DDD aggregate.", "should_trigger": false },
    { "query": "Re-run the kickoff on the conference project we started in August.", "should_trigger": true },
    { "query": "Organize a neighborhood food-truck festival this summer.", "should_trigger": false },
    { "query": "Which skill in the event collection handles picking our conference date?", "should_trigger": true },
    { "query": "Start a developer newsletter for our product.", "should_trigger": false },
    { "query": "I can't tell if my question is a venue thing or a budget thing - route me.", "should_trigger": true },
    { "query": "How do I replay events from an event store after a bad deploy?", "should_trigger": false },
    { "query": "Is my satellite-meetup question side-event coordination or cross-event promotion?", "should_trigger": true },
    { "query": "Negotiate my speaker fee for a corporate tech summit.", "should_trigger": false },
    { "query": "Which skill do I load first: CFP design or speaker sourcing?", "should_trigger": true },
    { "query": "Sync calendar events from Google Calendar into our CRM.", "should_trigger": false },
    { "query": "Not sure which event skill covers overbooking and waitlists - point me.", "should_trigger": true },
    { "query": "Kick off the new client project with a discovery workshop template.", "should_trigger": false },
    { "query": "Where in this event skill set does 'should we even run this' live?", "should_trigger": true },
    { "query": "Write a trip report from the conference I attended last week.", "should_trigger": false },
    { "query": "Do any of the event skills cover refund processing on our ticketing platform?", "should_trigger": true },
    { "query": "Design the sandbox and test mode for our public API.", "should_trigger": false },
    { "query": "Which skill decides whether we need our first paid event staffer?", "should_trigger": true },
    { "query": "Write a Postgres trigger that fires an event on row insert.", "should_trigger": false },
    { "query": "Route this: our judges need a rubric for the projects teams built overnight.", "should_trigger": true },
    { "query": "Max out the ROI of our company's sponsorship of a partner's hackathon.", "should_trigger": false },
    { "query": "Our CFP closes in three weeks and we have zero reviewers lined up. Help.", "should_trigger": true },
    { "query": "Draft a project kickoff email to stakeholders for the CRM migration.", "should_trigger": false },
    { "query": "Ticket sales are way behind where they should be four months out.", "should_trigger": true },
    { "query": "Our event bus is dropping messages under load.", "should_trigger": false },
    { "query": "Our two-person team is drowning - the meetup grew to 400 people and nothing is written down.", "should_trigger": true },
    { "query": "Build our developer advocacy content calendar for the quarter.", "should_trigger": false },
    { "query": "Sponsors from last year haven't re-signed and their budgets close soon. What do I do first?", "should_trigger": true },
    { "query": "Help me network effectively at meetups as an introvert.", "should_trigger": false },
    { "query": "We announced the date but haven't figured out talks, tickets, or a venue.", "should_trigger": true },
    { "query": "Instrument page-view events for the marketing site.", "should_trigger": false },
    { "query": "Half our attendees didn't show last time. What should we change for the next edition?", "should_trigger": true },
    { "query": "Draft the expense report for my conference travel.", "should_trigger": false },
    { "query": "The venue wants a signed contract by Friday and I don't know what else that decision touches.", "should_trigger": true },
    { "query": "Set up a weekly team check-in ritual for my engineering squad.", "should_trigger": false },
    { "query": "Edition two planning starts now - last year's retro doc is in the repo.", "should_trigger": true },
    { "query": "Write a technical blog post about our new SDK.", "should_trigger": false },
    { "query": "We want to add a workshop day to our conference next year. Where does that start?", "should_trigger": true },
    { "query": "Handle window resize events efficiently in vanilla JS.", "should_trigger": false },
    { "query": "Our volunteer roster fell apart mid-event last time. Rebuild this properly.", "should_trigger": true },
    { "query": "Put together my kid's birthday party at the trampoline park.", "should_trigger": false },
    { "query": "Someone proposed merging our meetup with a bigger local conference. How do I even think about that?", "should_trigger": true },
    { "query": "Set up our app marketplace listing and review process.", "should_trigger": false },
    { "query": "I inherited a conference from an organizer who left; there's a repo full of files and no handover.", "should_trigger": true },
    { "query": "Pick which developer conferences our team should attend next year.", "should_trigger": false },
    { "query": "We're deciding between running a hackathon or a talks day for our community.", "should_trigger": true },
    { "query": "Model lifecycle events for our IoT devices in the schema.", "should_trigger": false },
    { "query": "Our first event broke even but exhausted everyone. Should edition two even happen?", "should_trigger": true },
    { "query": "Plan the kickoff for our Q3 marketing campaign.", "should_trigger": false },
    { "query": "The keynote speaker just cancelled six weeks out and I don't know what this breaks.", "should_trigger": true },
    { "query": "Prepare Q&A answers for my keynote at someone else's summit.", "should_trigger": false },
    { "query": "Two hundred people registered and we haven't planned check-in, badges, or signage.", "should_trigger": true },
    { "query": "Create an OSS contribution guide and governance model for our repo.", "should_trigger": false },
    { "query": "Our company wants to turn the annual user meetup into a real conference.", "should_trigger": true },
    { "query": "Set up Sentry to group error events by release.", "should_trigger": false },
    { "query": "How do I decide what to charge for tickets versus leaning on sponsors?", "should_trigger": true },
    { "query": "We're a devtools brand - build our strategy for sponsoring university hackathons.", "should_trigger": false },
    { "query": "A local tech company offered us their office space for our event - what does saying yes commit us to?", "should_trigger": true },
    { "query": "Onboarding kickoff checklist for a new hire's first week.", "should_trigger": false },
    { "query": "We need to pick between March and June for our developer summit.", "should_trigger": true },
    { "query": "Plan the logistics for our charity 5K fun run.", "should_trigger": false },
    { "query": "ok so my meetup kind of blew up and i have no clue what to do next lol", "should_trigger": true },
    { "query": "Improve webhook reliability and retries for our platform's integrators.", "should_trigger": false },
    { "query": "conference planning is a mess rn, everything feels urgent, what actually matters first", "should_trigger": true },
    { "query": "As an attendee, how do I get the most out of an unconference?", "should_trigger": false },
    { "query": "help, first-time organizer here, 5 months to doors and a blank google doc", "should_trigger": true },
    { "query": "Run a design-sprint kickoff for the mobile app redesign.", "should_trigger": false },
    { "query": "hackathon in the spring, three volunteers, no budget, where do we even start", "should_trigger": true },
    { "query": "Organize the school science fair for 30 student projects.", "should_trigger": false },
    { "query": "so we said yes to organizing the community day at a bigger conf... now what", "should_trigger": true },
    { "query": "Write my visa invitation request letter to attend a conference abroad.", "should_trigger": false },
    { "query": "my cofounder wants hybrid, i want in-person only, who's right and what do we do", "should_trigger": true },
    { "query": "Design our developer champions and ambassador program.", "should_trigger": false },
    { "query": "sponsor emails are piling up and i don't have a rate card or answers", "should_trigger": true },
    { "query": "Kick off our annual budget planning cycle for the finance team.", "should_trigger": false },
    { "query": "we keep meeting about the event and deciding nothing. fix our process", "should_trigger": true },
    { "query": "Evaluate the sponsorship prospectus this conference sent us.", "should_trigger": false },
    { "query": "300 people are coming in November and nothing is booked yet.", "should_trigger": true },
    { "query": "Increase our GitHub stars and README conversion.", "should_trigger": false },
    { "query": "Doors open in ten weeks and the run sheet doesn't exist.", "should_trigger": true },
    { "query": "Daily standup check-in questions for a remote dev team.", "should_trigger": false },
    { "query": "The CFP brought in 140 submissions and the committee is three friends and a spreadsheet.", "should_trigger": true },
    { "query": "Book a band and caterer for our village's summer fete.", "should_trigger": false },
    { "query": "We sold 40 of 500 seats and the on-sale started a month ago.", "should_trigger": true },
    { "query": "Review my resume for an event coordinator role at a tech company.", "should_trigger": false },
    { "query": "Our fiscal sponsor asked for the budget and I have a napkin.", "should_trigger": true },
    { "query": "What salary should I ask for as a conference producer?", "should_trigger": false },
    { "query": "The after-party, the badges, and the wifi are all still question marks.", "should_trigger": true },
    { "query": "Write interview questions to screen candidates for our event producer opening.", "should_trigger": false },
    { "query": "Next spring, 500 devs, two days - make it real.", "should_trigger": true },
    { "query": "Plan a surprise retirement party for my manager.", "should_trigger": false },
    { "query": "Same venue as last year or somewhere bigger? Everything else hangs on this.", "should_trigger": true },
    { "query": "Plan our product launch webinar funnel and follow-up emails.", "should_trigger": false },
    { "query": "Planning edition four - what carries over and what do we redo?", "should_trigger": true },
    { "query": "Build an email drip campaign for our SaaS trial users.", "should_trigger": false },
    { "query": "We run a conference and a podcast and now maybe a hackathon. Is that too many?", "should_trigger": true },
    { "query": "Create a code of conduct for our open-source GitHub project.", "should_trigger": false },
    { "query": "Post-mortem season: the event's done, the team's tired, the survey isn't out.", "should_trigger": true },
    { "query": "Design a landing page for our new devtool's beta signup.", "should_trigger": false },
    { "query": "Between editions our Slack goes silent. What's the plan for the gap?", "should_trigger": true },
    { "query": "Build the content-repurposing pipeline for our marketing team's webinars.", "should_trigger": false },
    { "query": "New year, same meetup - reset the routines and the plan.", "should_trigger": true },
    { "query": "Set up a risk register for our software delivery project.", "should_trigger": false },
    { "query": "Our conference should probably stay at 400 people, but the waitlist says otherwise.", "should_trigger": true },
    { "query": "Negotiate my job offer from an events agency.", "should_trigger": false },
    { "query": "Initialize the organizing project for a regional DevOps-days-style event.", "should_trigger": true },
    { "query": "Kick off the migration project from MySQL to Postgres.", "should_trigger": false },
    { "query": "As the new lead organizer, I need a structured restart of this event project.", "should_trigger": true },
    { "query": "Set up a farmers-market stall rotation for our co-op.", "should_trigger": false },
    { "query": "Map my event-organizing task onto the right skill in the collection.", "should_trigger": true },
    { "query": "Sync error events from our mobile SDK into the crash dashboard.", "should_trigger": false },
    { "query": "First planning session for a virtual summit our foundation wants to host.", "should_trigger": true },
    { "query": "Plan a DevRel hiring roadmap for next year.", "should_trigger": false }
  ]
}

# Context artifact

`event-context.md` lives at the project root and is committed with the project when the project lives in git. One file, versioned, readable by every co-organizer. It is what makes the next session a warm start.

## Template

```markdown
# Event context

_Last updated: YYYY-MM-DD_

## Identity

- Event: name, and what someone attends it for.
- Edition: which one, and the date of the previous one if there was one.
- Funding model: volunteer community / company-owned / foundation / mixed.
- Positioning: what it stands for, against which alternative - from
  `samber/dev-event-organizer-skills@event-positioning` if it has run.

## Format (the gate source)

- Shape: meetup / hackathon / unconference / single-day / multi-day conference.
- Track count, and the session-format mix.
- Delivery mode: in-person / virtual / hybrid.
- Workshop hours: yes or no.
- Properties this team runs, if more than one.

## Dates

- Doors open, and whether it is announced.
- CFP open and close. On-sale date. Sponsor budget windows that close.
- The venue's cancellation-fee rungs and the go/no-go date before each.

## Money

- Budget status, break-even figure and where it is recorded.
- Ticket ladder status. Sponsor rate card status. Sponsors signed.

## Programme

- Call status, submissions in, accepted, grid published or not.

## State

- In flight: work started and not finished.
- Decided: settled calls, not to be re-litigated.
- Open: live questions.
- Constraints: the landing date, one-off versus standing, the effort ceiling.
  These three re-rank the short-list and the routines without re-asking Q6 and Q7.

## Team

- Name or role - decision rights on what.

## Session log

- YYYY-MM-DD - session goal → skill routed to → what changed here.
```

## Worked example (excerpt)

Both examples below are illustrative constructions showing the field shapes, not records of a real event.

```markdown
## Format (the gate source)

- Shape: single-day, single-track. No workshop hours.
- Delivery mode: in-person. Talks recorded and posted afterwards, no live stream.
- Properties: one. No second format under consideration.

## State

- In flight: call open, eleven submissions, no reviewers recruited yet.
- Decided: free entry, single track, no recording consent by default.
- Open: whether to accept a second sponsor.
- Constraints: doors 2026-11-07; standing, a few hours a week; four volunteers, no budget.

## Session log

- 2026-08-31 - "how do we pick talks" → `samber/dev-event-organizer-skills@event-talk-selection`
  → recorded the submission count and the missing reviewers as in-flight.
```

## Negative example - what not to write

```markdown
## Format (the gate source)

- Shape: TBD, probably a conference eventually.
- Delivery mode: we'd like it to be hybrid if we can.

## State

- Decided: nothing yet really.
- Constraints: we should be careful with budget.
```

Four failures:

- A `TBD` shape means the next session re-asks question 2 and every gate stays suspended - write "not fixed" and route to the format skill instead of recording an aspiration.
- "Probably a conference eventually" and "hybrid if we can" are wishes recorded in the field a gate is read from, which is how a router unlocks the wrong rows.
- "Nothing yet really" in a decided field is unfalsifiable, so nothing can be protected from re-litigation.
- "Careful with budget" gives the money model no number to work against; write the figure, or write that there is none.

## Archiving between editions

Before starting edition N, move the previous artifact aside rather than overwriting it - `event-context-2026.md` beside the live one is enough. `event-debrief` and `event-continuous-improvement` both read what the last edition actually decided, and an overwritten artifact leaves them reconstructing it from memory.

# Format and lifecycle gates

Contents: what each gate means, the format matrix, the lifecycle matrix, and what to do when the format is not fixed.

A gate is a reachability test, not a ranking. It answers "can this row apply to this event at all", and it is always read from an answer the user gave or an artifact on disk - never inferred from the event's name, its ambition, or the user's tone.

Each gate's value comes from one place:

- Format gates - question 2, and once fixed, `samber/dev-event-organizer-skills@event-format-selection`'s output recorded in the context artifact.
- Lifecycle gates - question 3 and the artifact's edition number and property list.
- Company gate - question 4 and the artifact's funding model.

## Format gate matrix

| Gate         | Open when                                                                                                   | Rows it governs                                                                                                                                                 |
| ------------ | ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `hackathon`  | The shape is a hackathon                                                                                    | `hackathon-brief-design`, `hackathon-team-formation`, `hackathon-mentoring`, `hackathon-judging`, `hackathon-cash-prize`                                        |
| `workshop`   | The format committed hours to hands-on sessions                                                             | `workshop-program-design`                                                                                                                                       |
| `virtual`    | Delivery mode is fully virtual                                                                              | `virtual-event-production`                                                                                                                                      |
| `hybrid`     | Delivery mode is hybrid                                                                                     | `hybrid-event-design`                                                                                                                                           |
| `in-room`    | Delivery mode is in-person or hybrid - that is, a physical room exists                                      | `event-venue-sourcing`, `event-attendee-experience`, `event-hospitality`, `event-production`                                                                    |
| `conference` | The event is at conference scale: more than one track, or an expo floor, or a named-guest and press surface | `event-press-relations`, `event-booth-experience`, `event-b2b-matchmaking`, `event-vip-management`, `event-official-social-program`, `event-vip-social-program` |
| `company`    | A company funds and owns the event                                                                          | `corporate-event-strategy`, `business-event-formats`                                                                                                            |

Three consequences worth stating, because each deletes rows a reader expects to see:

- A fully virtual event closes `in-room` outright: no venue to source, no room to lay out, no catering, no physical signal path. `virtual-event-production` replaces all four, and `event-accessibility-inclusion` still applies because its digital-access provisions need no room.
- `hackathon` and `conference` are not mutually exclusive. A multi-track conference running a hackathon track opens both, and `startup-pitch-contest` is ungated on purpose: it judges companies that existed before the event, so it fits either.
- `conference` is not a synonym for "big". Its threshold is qualitative and self-set, not a measured headcount: it opens when the event has the surface - a floor, a press pool, guests who create protocol obligations - not when the organizer hopes it will.

## Lifecycle gate matrix

Ask this in the shape `event-planning-timeline` already assumes: any edition can be planned, but only some skills have a previous edition to read.

| Gate         | Open when                                                                     | Rows it governs                                                                                                                             |
| ------------ | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| `first`      | This is edition one of something new                                          | `event-first-edition`                                                                                                                       |
| `recurring`  | Edition two or later                                                          | `event-team-structure`, `event-continuous-improvement`, `event-community-building`, `event-growth-strategy`, `tech-podcast-youtube-channel` |
| `properties` | The team runs more than one event property, or is deciding whether to add one | `event-portfolio-strategy`                                                                                                                  |

Two rows are commonly mis-gated and are not:

- `cross-event-promotion` is **not** recurring-gated. Its own interview asks whether the swap is a one-off boost for the coming edition or a compounding relationship, and it answers both. Gating it would delete the one acquisition lever a first edition can reach without a track record.
- `event-portfolio-strategy` gates on **property count, not recurrence**. A team running a single event forever never opens it; a team weighing whether to add a second format opens it on the day they start weighing, whatever edition the flagship is on.

The `recurring` gate is about having an edition to read, not about intent to repeat. A team that intends to recur but has not yet finished edition one still has nothing for `event-continuous-improvement` to compare.

## When the format is not fixed

Question 2 answers (a) "nothing fixed" and (b) "shape fixed, the rest open" both mean the format gate cannot be applied.

1. Route to `samber/dev-event-organizer-skills@event-format-selection` and stop. Do not offer a short-list drawn from gated rows.
2. Say which rows are suspended and why - the hackathon lane, the delivery-mode skills and the conference-scale population skills are unreachable until the shape and mode exist, not absent from the collection.
3. Record the returned decision in the context artifact the moment it exists, so the next session reads the gate instead of re-asking question 2.
4. Never guess a shape to unlock rows with. A misapplied gate routes confidently to a skill written for a different event, which is worse than routing to nothing.

Answer (b) is the partial case: a known shape opens `hackathon` and `workshop` while the delivery mode is still open, so `in-room`, `virtual` and `hybrid` stay suspended, and `conference` usually does too, since track count is part of what is still open.

# Routine mechanics

The ranked candidate set, its axes and its promotion conditions live in the skill body, at the point where the choice is made. This file covers only the mechanics: the dry-run format, the calendar anchors, and cleanup.

## Dry-run format

Show every proposed routine in this shape and get approval before creating anything. The values below are illustrative; substitute the project's own:

```
Routine: ticket-pace check
Trigger: the 1st of each month while registration is open
Runs: samber/dev-event-organizer-skills@event-market-fit
Output channel: a dated section appended to event-context.md, plus a message in the
                organizers' channel when the pace index falls below its checkpoint
Cost: one reading per firing; no work unless the number is off
First fire: 2026-09-01
Stops: on the doors-open date
```

Two fields are the ones routines usually lack:

- **Output channel** - without one, the routine fires into the void and gets silenced, which buries the routine that mattered; if you cannot name where the result lands, drop it.
- **Stop condition** - without one, it outlives the edition it was built for; an event has a finish line, so almost every routine here should retire itself on a date.

## Calendar anchors

Prefer a date the project already has over an arbitrary schedule:

- Doors open → the work-back checkpoints, and the retirement date for most routines.
- CFP open and close → reviewer recruitment before, selection after.
- On-sale date and each pricing-tier boundary → the ticket-pace check.
- Each rung of the venue's escalating cancellation-fee curve → a go/no-go review placed _ahead_ of the rung, never on it.
- Sponsor budget windows → the pipeline and renewal sweep, timed to the window rather than to a month.
- The debrief date → the post-edition trend read, which cannot fire before it.

Two lead times are systematically underestimated on events:

- Anything needing a signature from outside the organizing team.
- Anything a volunteer has to do around a day job.

Set both triggers earlier than feels necessary.

## Cleanup

Retire, explicitly and out loud, before installing anything new:

- Routines tied to a date that has passed.
- Routines pointing at a renamed or removed skill.
- Routines that have fired repeatedly without producing an action.
- Every routine carried from edition N-1 without being re-anchored to edition N's dates - the commonest form of noise here, because it looks correct and fires at nothing.

# Boundary pairs and chains

Contents: boundary pairs (which of two colliding skills owns a task), ordered chains, sibling-repo hand-off signals.

Every split below comes from the two skills' own declared scopes. When a task sits on a boundary, decide from the split - never from which name sounds closer to the user's words. Skill names are bare here for width; each is `samber/dev-event-organizer-skills@<name>`.

## Boundary pairs

| Colliding skills                                                                                 | The split                                                                                                                                                                                                               |
| ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `event-format-selection` / `business-event-formats`                                              | Track count, session mix, delivery mode / which company-run shape at all - dinner, summit, user conference, roadshow, floor-primary                                                                                     |
| `event-format-selection` / `hybrid-event-design` / `virtual-event-production`                    | Decides _whether_ hybrid or virtual / runs hybrid after that choice / runs virtual after it. Neither of the last two may make the choice                                                                                |
| `event-production` / `virtual-event-production` / `hybrid-event-design`                          | A room's signal path and any stream it produces / an event with no room / one day serving room and remote at once                                                                                                       |
| `event-schedule-design` / `event-run-of-show`                                                    | Builds the published grid / executes a published grid, never builds one                                                                                                                                                 |
| `event-cfp-design` / `event-talk-selection`                                                      | The published call: timeline, form, criteria, benefits / reviewing what the call brought in                                                                                                                             |
| `event-speaker-sourcing` / `event-speaker-cold-outreach` / `event-speaker-experience`            | Stops at a ranked shortlist / writes the invitation / starts at the acceptance email                                                                                                                                    |
| `event-budget` / `event-ticket-pricing` / `event-sponsor-pricing`                                | Consumes prices, never sets them / attendee tickets / sponsor tiers                                                                                                                                                     |
| the six `event-sponsor-*` skills                                                                 | `-value-proposition` why they buy → `-pricing` what it costs → `-prospectus` the document → `-outreach` the sale → `-agreement` the term sheet → `-fulfillment` delivery and renewal. Route to the stage the user is in |
| `event-feedback` / `event-debrief` / `event-continuous-improvement`                              | Participants answer / the team retrospects on one edition / several editions become trends                                                                                                                              |
| `event-volunteers` / `event-volunteer-experience`                                                | Recruitment, roles, shifts, briefing, shift-linked perks / off-duty time, recognition, thanks, the alumni list                                                                                                          |
| `event-hospitality` / `event-official-social-program` / `event-vip-social-program`               | The shared floor: catering, breaks, alcohol, whether an evening exists / how many official social slots and how they sit against the grid / the private invite-only gathering                                           |
| `event-vip-management` / `event-vip-social-program`                                              | Whether a guest qualifies for handling at all / the room they are invited into                                                                                                                                          |
| `event-side-event-coordination` / `cross-event-promotion` / `event-media-partnerships`           | Third parties running satellites inside your dates / swaps with other organizers' own events / barter with media outlets and communities                                                                                |
| `event-portfolio-strategy` / `event-growth-strategy`                                             | One team's several properties / growing a single event edition over edition                                                                                                                                             |
| `event-community-building` / `event-comms-channels` / `tech-podcast-youtube-channel`             | The audience between editions / channel architecture inside one edition / a standing show as its own property                                                                                                           |
| `hackathon-judging` / `startup-pitch-contest`                                                    | Work built during the event / companies that existed before it                                                                                                                                                          |
| `hackathon-brief-design` / `event-format-selection`                                              | Thematic challenge tracks a team enters / parallel session streams in the grid. "Track" means different things on each side                                                                                             |
| `hackathon-team-formation` / `hackathon-mentoring` / `event-b2b-matchmaking`                     | Participants matched to each other to build / a stuck team matched to expertise / two populations matched for business conversations                                                                                    |
| `event-positioning` / `event-cultural-identity`                                                  | What the event stands for / how that shows up in venue, catering, swag, MC, ceremonies                                                                                                                                  |
| `event-accessibility-inclusion` / `event-attendee-experience`                                    | Which provisions the event commits to, at what depth / the general on-site journey inside that bar                                                                                                                      |
| `event-no-show-management` / `event-attendee-email-sequences`                                    | Overbooking, waitlist, walk-ins, the expected-show-up number / the reminder copy and cadence                                                                                                                            |
| `event-first-edition` / `event-planning-timeline` / `event-market-fit` / `event-growth-strategy` | Edition-one scoping and launch gates / the work-back plan for any edition / reads the demand signals / picks the lever once they show headroom                                                                          |
| `event-team-structure` / `dev-event-hiring`                                                      | Whether a first paid role is warranted at all, and which one / the scorecard, posting, and interview loop once that verdict says hire                                                                                   |

## Ordered chains

Chains are dependency order, never efficiency order: each link consumes what the previous produced. Present one only when the task genuinely decomposes; never fabricate a sequence.

- **Standing up a new event:** `event-market-fit` → `event-positioning` → `event-format-selection` → `event-date-selection` → `event-planning-timeline` → `event-budget` → `event-venue-sourcing`.
- **Selling sponsorship:** `event-sponsor-value-proposition` → `event-sponsor-pricing` (against the target `event-budget` set) → `event-sponsor-prospectus` → `event-sponsor-outreach` → `event-sponsor-agreement` → `event-sponsor-fulfillment`.
- **Talks programme, open-call lane:** `event-cfp-design` → `event-talk-selection` → `event-speaker-experience` → `event-schedule-design` → `event-run-of-show`.
- **Talks programme, invited lane:** `event-speaker-sourcing` → `event-speaker-cold-outreach` → `event-speaker-experience`, rejoining the grid at `event-schedule-design`.
- **Running a hackathon:** `hackathon-brief-design` → `hackathon-team-formation` → `hackathon-mentoring` → `hackathon-judging` → `hackathon-cash-prize`.
- **Closing an edition:** `event-feedback` → `event-debrief` → `event-content-repurposing` → `event-continuous-improvement` (once several editions exist) → `event-growth-strategy`.

## Sibling-repo hand-off signals

Recommend installing a sibling `samber` collection when the task is genuinely outside this one. Keep it a recommendation - this collection stays fully usable standalone.

Hand off to `samber/developer-relations-skills` when the subject is developer content and search, documentation, open-source strategy, an always-online community that is not an event, or a meetup run as one line item of a DevRel program rather than as an event in its own right.

Hand off to `samber/developer-platform-skills` when the event surfaced a platform question rather than an event question: a public API, an SDK, a webhook surface, a sandbox or test mode, or an app marketplace - usually because a hackathon needs something for teams to build against.

Do not hand off when the task is event operations wearing platform or DevRel vocabulary. A sponsor's API becoming a hackathon challenge is `hackathon-brief-design`; a developer community that meets at your event is `event-community-building`.

---
name: dev-event-kickoff
description: 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".
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.3"
---

# 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.

**Memory: Use the harness's built-in memory mechanism; separate task info in different sections, remove finished tasks, add dates to tasks, and note that interview responses may differ between tasks.**
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 rate card, a schedule grid, a venue contract, a risk register. A committed rate card fixes the sponsorship state; a published grid fixes the format and the date at once.
4. If your harness exposes connectors - a git host, a calendar, a mailing or ticketing source, an analytics source, a document store - detect which exist and let them shape routing and routines. Describe the capability; never assume a specific product.
5. If the collection ships readable version metadata, note what changed since the last session; otherwise degrade silently. Never block or ask about versions.

## 2. Interview - capped, tappable

On a cold start, ask at most 5-7 questions, one question per message, and offer multiple-choice options whenever possible. Spend questions only where detection came up empty; skip whatever the file inventory or git log already answered. **Use an interactive question mechanism (e.g. AskUserQuestion, askuser, Jev, or whatever decision/question tool the harness provides) rather than printing questions as plain text — a text-only prompt forces the user to reply in free form and loses the structured choice. Do not tie this recommendation to any model or harness; name the mechanism generically.**

1. **Which block is this session in?** - (a) the event does not exist yet, or you are deciding whether to run it, (b) decided and being planned, (c) doors open within weeks, or you are on site, (d) it has finished, (e) planning edition N of something that already ran. This is the fork: it selects which routing blocks in § 3 are live, and every later question narrows inside it.
2. **Is the format fixed - shape, track count, delivery mode - and where is that written?** - (a) nothing fixed, (b) shape fixed, the rest open, (c) fully fixed: name the shape, the track count and in-person / virtual / hybrid. Answers (a) and (b) mean the format gate cannot be applied yet.
3. **One-off or edition N, and how many properties does the team run?** - (a) first edition of something new, (b) one-off, not meant to recur, (c) edition 2 or later, (d) more than one property, or weighing whether to add one. Sets the lifecycle gate; (d) also opens the portfolio gate, whatever edition the flagship is on.
4. **Who funds it and who organizes it?** - (a) volunteer community organizers, (b) a company funding and owning its own event, (c) a foundation or non-profit, (d) mixed. Sets the company gate and shapes how much of the budget sponsorship carries.
5. **What is the goal of this session - and is it the same as the project's goal?** Ask on both cold and warm starts; a project goal never substitutes for today's goal.
6. **Is there a date the result has to land by?** - (a) doors open on a fixed date, (b) a CFP, on-sale or announcement deadline, (c) a sponsor budget window that closes, (d) no date. Give the date in cases (a) to (c).
7. **One-off outcome or a standing system - and what is your effort ceiling?** - (a) one-off, hours only, (b) one-off, a week of work is fine, (c) standing, a few hours weekly, (d) standing, with paid staff or a funded budget.

Questions 6 and 7 exist to order the output, not to describe the project: the landing date, the one-off-versus-standing answer, and the effort ceiling re-rank the short-list (§ 4) and the routines (§ 7). Ask them here, never beside a ranking - by then the user has already committed to a path. Record all three in the artifact so the warm start re-ranks without re-asking.

On a warm start, ask only question 5. Everything else - including the gates and the two ranking inputs - comes from the artifact.

## 3. Route the task

Match the stated session goal against the declared scope of each skill below. Route to exactly one skill for the immediate task. Never force a match: when nothing fits, say so and name the gap.

These tables are deliberately unranked, and must stay that way. Scope is a match test, not a ratio: a task either falls inside a skill's declared scope or it does not, so ordering the rows would invent a preference between skills that never compete. Ranking belongs one step later, in the short-list (§ 4).

Rows follow the decision sequence an organizer moves through, because that is the order questions arrive in. Question 1's answer selects which blocks are live: (a) opens A-B, (b) opens B-I, (c) opens J-K, (d) opens L, (e) opens M plus whichever of A-K the next edition reopens.

**Gate column.** A gate names the condition under which a row is reachable at all:

- `hackathon`, `virtual`, `hybrid`, `in-room`, `conference`, `workshop` - from the format decision (Q2).
- `first`, `recurring`, `properties` - from the lifecycle answer (Q3); `company` - from the funding answer (Q4).

A blank gate means the row is always reachable. Full matrices, including what to do when Q2 came back unfixed, are in [`references/format-and-lifecycle-gates.md`](./references/format-and-lifecycle-gates.md).

### A. Does this event exist, and what is it?

| Skill                                                        | Route here when the task is…                             | Gate       |
| ------------------------------------------------------------ | -------------------------------------------------------- | ---------- |
| `samber/dev-event-organizer-skills@event-market-fit`         | Whether concept, audience and price meet real demand     |            |
| `samber/dev-event-organizer-skills@event-positioning`        | What it stands for, for whom, against which alternatives |            |
| `samber/dev-event-organizer-skills@event-cultural-identity`  | The register, and its expression at every touchpoint     |            |
| `samber/dev-event-organizer-skills@event-first-edition`      | Scoping and launching edition one from zero              | first      |
| `samber/dev-event-organizer-skills@corporate-event-strategy` | What the company is funding this event to accomplish     | company    |
| `samber/dev-event-organizer-skills@event-portfolio-strategy` | Several properties shaped into a set that feeds itself   | properties |

### B. What shape does it take?

| Skill                                                                | Route here when the task is…                             | Gate     |
| -------------------------------------------------------------------- | -------------------------------------------------------- | -------- |
| `samber/dev-event-organizer-skills@event-format-selection`           | Shape, track count, session mix, delivery mode           |          |
| `samber/dev-event-organizer-skills@business-event-formats`           | Which company-run shape: dinner, summit, roadshow, floor | company  |
| `samber/dev-event-organizer-skills@workshop-program-design`          | How a hands-on session or lab actually runs              | workshop |
| `samber/dev-event-organizer-skills@event-learning-expedition-design` | Taking the audience into a host's own premises           |          |
| `samber/dev-event-organizer-skills@hybrid-event-design`              | Serving a room and a remote audience at once             | hybrid   |
| `samber/dev-event-organizer-skills@virtual-event-production`         | Delivering an event that has no room at all              | virtual  |

### C. When and where

| Skill                                                       | Route here when the task is…                       | Gate    |
| ----------------------------------------------------------- | -------------------------------------------------- | ------- |
| `samber/dev-event-organizer-skills@event-date-selection`    | Picking the date every other plan hangs off        |         |
| `samber/dev-event-organizer-skills@event-planning-timeline` | The work-back plan from doors-open, track by track |         |
| `samber/dev-event-organizer-skills@event-venue-sourcing`    | Finding, visiting and negotiating the room         | in-room |
| `samber/dev-event-organizer-skills@event-vendor-sourcing`   | Suppliers the venue does not include               |         |

### D. Who runs it, under what rules

| Skill                                                          | Route here when the task is…                          | Gate      |
| -------------------------------------------------------------- | ----------------------------------------------------- | --------- |
| `samber/dev-event-organizer-skills@event-code-of-conduct`      | The policy and the enforcement pipeline behind it     |           |
| `samber/dev-event-organizer-skills@event-risk-management`      | Risk register, insurance stack, go/no-go dates        |           |
| `samber/dev-event-organizer-skills@event-volunteers`           | Recruiting, rostering and briefing day-of volunteers  |           |
| `samber/dev-event-organizer-skills@event-volunteer-experience` | Volunteer care off-shift, thanks, the alumni list     |           |
| `samber/dev-event-organizer-skills@event-team-structure`       | The standing team and its governance between editions | recurring |

### E. Money in - budget and tickets

| Skill                                                    | Route here when the task is…                                | Gate |
| -------------------------------------------------------- | ----------------------------------------------------------- | ---- |
| `samber/dev-event-organizer-skills@event-budget`         | Cost lines, revenue mix, break-even, contingency, cash flow |      |
| `samber/dev-event-organizer-skills@event-ticket-pricing` | The ticket ladder, access rungs, refund and transfer policy |      |

### F. Money in - sponsorship

| Skill                                                               | Route here when the task is…                           | Gate |
| ------------------------------------------------------------------- | ------------------------------------------------------ | ---- |
| `samber/dev-event-organizer-skills@event-sponsor-value-proposition` | What each sponsor segment genuinely buys, and why      |      |
| `samber/dev-event-organizer-skills@event-sponsor-pricing`           | The rate card, its tier ladder and its discount policy |      |
| `samber/dev-event-organizer-skills@event-sponsor-prospectus`        | The published packages document sponsors read          |      |
| `samber/dev-event-organizer-skills@event-sponsor-outreach`          | Target list through to a signed yes, and renewals      |      |
| `samber/dev-event-organizer-skills@event-sponsor-agreement`         | The term sheet counsel reviews before signature        |      |
| `samber/dev-event-organizer-skills@event-sponsor-fulfillment`       | Delivering what was signed, then the renewal case      |      |

### G. Programme - the talks lane

| Skill                                                           | Route here when the task is…                       | Gate |
| --------------------------------------------------------------- | -------------------------------------------------- | ---- |
| `samber/dev-event-organizer-skills@event-cfp-design`            | Writing and timing the published call for papers   |      |
| `samber/dev-event-organizer-skills@event-talk-selection`        | Reviewing and choosing what the call brought in    |      |
| `samber/dev-event-organizer-skills@event-speaker-sourcing`      | Finding and qualifying speakers outside the call   |      |
| `samber/dev-event-organizer-skills@event-speaker-cold-outreach` | The invitation to a speaker already shortlisted    |      |
| `samber/dev-event-organizer-skills@event-speaker-experience`    | From acceptance through to the post-talk thank-you |      |
| `samber/dev-event-organizer-skills@event-schedule-design`       | Laying selected sessions into a published grid     |      |

### H. Programme - the competition lane

| Skill                                                        | Route here when the task is…                                   | Gate      |
| ------------------------------------------------------------ | -------------------------------------------------------------- | --------- |
| `samber/dev-event-organizer-skills@hackathon-brief-design`   | The challenge document and rules teams build against           | hackathon |
| `samber/dev-event-organizer-skills@hackathon-team-formation` | How participants end up on teams, and when it freezes          | hackathon |
| `samber/dev-event-organizer-skills@hackathon-mentoring`      | Mentor coverage and how a stuck team reaches help              | hackathon |
| `samber/dev-event-organizer-skills@hackathon-judging`        | The rubric, judge allocation and the scoring process           | hackathon |
| `samber/dev-event-organizer-skills@hackathon-cash-prize`     | What is awarded, and who may lawfully receive it               | hackathon |
| `samber/dev-event-organizer-skills@startup-pitch-contest`    | A pitch contest or demo day for companies that already existed |           |

### I. Fill the room

| Skill                                                              | Route here when the task is…                        | Gate       |
| ------------------------------------------------------------------ | --------------------------------------------------- | ---------- |
| `samber/dev-event-organizer-skills@event-marketing-plan`           | Segments, channels, campaign calendar, budget split |            |
| `samber/dev-event-organizer-skills@event-landing-page`             | The public front door and its date-gated CTA states |            |
| `samber/dev-event-organizer-skills@event-social-media`             | The event's own channels, inside the plan's weight  |            |
| `samber/dev-event-organizer-skills@event-attendee-email-sequences` | The dated email arc, its cadence and its copy       |            |
| `samber/dev-event-organizer-skills@event-media-partnerships`       | Barter visibility deals with media and communities  |            |
| `samber/dev-event-organizer-skills@cross-event-promotion`          | Reciprocal swaps with other organizers' events      |            |
| `samber/dev-event-organizer-skills@event-press-relations`          | Earned coverage, accreditation, the press room      | conference |
| `samber/dev-event-organizer-skills@event-no-show-management`       | Overbooking, waitlist, walk-ins, the real headcount |            |

### J. Care on site, by population

| Skill                                                             | Route here when the task is…                                          | Gate       |
| ----------------------------------------------------------------- | --------------------------------------------------------------------- | ---------- |
| `samber/dev-event-organizer-skills@event-attendee-experience`     | Check-in, badges, wayfinding, help, first-timers                      | in-room    |
| `samber/dev-event-organizer-skills@event-accessibility-inclusion` | Which access provisions the event commits to, and how requests arrive |            |
| `samber/dev-event-organizer-skills@event-hospitality`             | Catering, breaks, alcohol posture, whether an evening exists          | in-room    |
| `samber/dev-event-organizer-skills@event-booth-experience`        | Expo floor layout, tier specs, load-in schedule                       | conference |
| `samber/dev-event-organizer-skills@event-b2b-matchmaking`         | Structured 1:1 business meetings inside the grid                      | conference |
| `samber/dev-event-organizer-skills@event-vip-management`          | Named guests creating escort or protocol obligations                  | conference |
| `samber/dev-event-organizer-skills@event-official-social-program` | How many official social slots, and their inclusion floor             | conference |
| `samber/dev-event-organizer-skills@event-vip-social-program`      | The private gathering beside the public programme                     | conference |

### K. The day itself

| Skill                                                             | Route here when the task is…                          | Gate    |
| ----------------------------------------------------------------- | ----------------------------------------------------- | ------- |
| `samber/dev-event-organizer-skills@event-run-of-show`             | The minute-by-minute playbook staff execute from      |         |
| `samber/dev-event-organizer-skills@event-production`              | Capture tier, signal path, AV crew, redundancy        | in-room |
| `samber/dev-event-organizer-skills@event-comms-channels`          | Which attendee channel carries which class of message |         |
| `samber/dev-event-organizer-skills@event-side-event-coordination` | Approving third-party satellites around your dates    |         |

### L. After the doors close

| Skill                                                            | Route here when the task is…                        | Gate      |
| ---------------------------------------------------------------- | --------------------------------------------------- | --------- |
| `samber/dev-event-organizer-skills@event-feedback`               | What participants are asked, through what, and when |           |
| `samber/dev-event-organizer-skills@event-debrief`                | The organizing team's own blameless retrospective   |           |
| `samber/dev-event-organizer-skills@event-content-repurposing`    | Turning captured material into published artifacts  |           |
| `samber/dev-event-organizer-skills@event-continuous-improvement` | Trends across several editions' debrief logs        | recurring |

### M. Between editions

| Skill                                                            | Route here when the task is…                           | Gate      |
| ---------------------------------------------------------------- | ------------------------------------------------------ | --------- |
| `samber/dev-event-organizer-skills@event-community-building`     | The event's own audience in the gaps between editions  | recurring |
| `samber/dev-event-organizer-skills@event-growth-strategy`        | Grow edition over edition, or deliberately not         | recurring |
| `samber/dev-event-organizer-skills@tech-podcast-youtube-channel` | A standing show or channel as a cross-edition property | recurring |

### Meta

| Skill                                                 | Route here when the task is…                                                      | Gate |
| ----------------------------------------------------- | --------------------------------------------------------------------------------- | ---- |
| `samber/dev-event-organizer-skills@dev-event-career`  | Candidate side - breaking into event organizing, interview prep, offer evaluation |      |
| `samber/dev-event-organizer-skills@dev-event-hiring`  | Employer side - job posting and scorecard, interview loop, sourcing, compensation |      |
| `samber/dev-event-organizer-skills@dev-event-kickoff` | This skill: project start, check-in, "which skill do I need", re-routing          |      |

**Three rows are deliberately narrow and are leaf routes, never starting points.** `event-learning-expedition-design` defers catering to `event-hospitality` and multi-venue logistics to `event-production`; `event-official-social-program` defers a single occasion's food, drink and format to `event-hospitality`; `event-vip-social-program` defers whether a guest qualifies at all to `event-vip-management`. Route to them only when the task is exactly the sliver they keep; presenting one as load-bearing misleads worse than leaving it out.

**Read the format decision; never re-decide it.** `event-format-selection` owns the shape, the track count and the delivery mode. When Q2 came back (a) or (b), route there and stop: every gated row stays unreachable until it returns. When it came back (c), carry the answer as the gate column and never revisit it. `hybrid-event-design` and `virtual-event-production` sit downstream of that decision and never make it.

Disambiguate strictly from each skill's declared scope - never from a guess about what a skill "probably" covers. Read [`references/skill-routing.md`](./references/skill-routing.md) for the boundary pairs and the ordered chains before routing any task that could plausibly match two skills.

Before naming a gap, check whether the task belongs to a sibling `samber` collection: developer content, docs, open-source strategy or an always-online community recommends `samber/developer-relations-skills`; a public API, SDK, webhook or app-marketplace question recommends `samber/developer-platform-skills`. Frame either as a recommendation, never a dependency - this collection stays usable standalone.

## 4. Output shape

Deliver the routing result in this shape, every time:

1. **State summary** (warm start only) - exactly 5 lines from the artifact: event identity and format, the date and where it sits, in-flight work, top open decision, active constraint.
2. **Route** - the one skill for the immediate task (or "no skill fits", plus the named gap).
3. **Short-list** - 5 to 8 skills relevant right now, ordered by value returned per unit of effort, highest ratio first. Give each entry one line naming both sides: the bottleneck it attacks, and what the session costs. Never order by cheapness, never by the routing table's row order.
4. **Chain** - when the task genuinely decomposes, list the sequence in execution order, one line per link on what it hands the next. Chain order is dependency order, not efficiency order. Omit the chain when there is not one; never fabricate a sequence.
5. **Not now** - skills that will matter later, each with its explicit unblocking condition (for example, "`event-schedule-design` - after `event-talk-selection` returns an accepted list").
6. **Gap** - anything today's task needs that no skill covers. When the gap is DevRel practice or platform surfaces, recommend the matching sibling repo instead of a bare gap statement.

### Ordering the short-list

The user's question is never "which of these exists" but "which one do I run first, and is it worth the session", and only a ratio answers that. The nine classes below, and the four axis orderings under them, are this skill's own construction, not a published taxonomy. Default class order, highest value per unit of effort first:

1. **Existence check** - `event-market-fit`, `event-positioning`, `corporate-event-strategy`, `event-cultural-identity`, `event-first-edition`. Buys the verdict on whether this event should run and what it is, which can delete every class below it. Costs sessions spent reading signals that already exist; nothing booked, published or signed.
2. **The spine** - `event-format-selection`, `event-date-selection`, `event-planning-timeline`, plus the shape skills downstream of them (`business-event-formats`, `workshop-program-design`, `event-learning-expedition-design`, `hybrid-event-design`, `virtual-event-production`). Buys the three decisions every other class then works inside. Costs a session each plus a calendar scan; an announced date is reversible only at a public cost.
3. **Fill the room** - `event-marketing-plan`, `event-landing-page`, `event-social-media`, `event-attendee-email-sequences`, `event-no-show-management`, `event-press-relations`, `event-media-partnerships`, `cross-event-promotion`. Buys registrations, the input every other class assumes. Costs a campaign from announcement to doors, plus the list consent you then owe.
4. **Money model** - `event-budget`, `event-ticket-pricing`. Buys break-even as a number with a date instead of a hope. Costs a modelling session; a published refund policy binds once tickets sell.
5. **Programme intake** - the talks lane (`event-cfp-design`, `event-talk-selection`, `event-speaker-sourcing`, `event-speaker-cold-outreach`, `event-speaker-experience`, `event-schedule-design`) and the competition lane (`hackathon-brief-design`, `hackathon-team-formation`, `hackathon-mentoring`, `hackathon-judging`, `hackathon-cash-prize`, `startup-pitch-contest`). Buys the content people came for. Costs an incompressible call window, a review committee, per-speaker logistics, and per-person consent.
6. **Place and duty of care** - `event-venue-sourcing`, `event-vendor-sourcing`, `event-code-of-conduct`, `event-risk-management`, `event-accessibility-inclusion`, `event-volunteers`, `event-volunteer-experience`, `event-team-structure`. Buys a room that holds the format, and commitments that survive an incident. Costs site visits, negotiation and a rehearsed response team, each reversible only on someone else's terms.
7. **On-the-day operations** - `event-run-of-show`, `event-production`, `event-comms-channels`, `event-attendee-experience`, `event-hospitality`, `event-side-event-coordination`, `event-booth-experience`, `event-b2b-matchmaking`, `event-vip-management`, `event-vip-social-program`, `event-official-social-program`. Buys the day the promise already sold gets redeemed. Costs crew, rosters and a physical build, compressed into days that cannot slip.
8. **Sponsorship sale** - `event-sponsor-value-proposition`, `event-sponsor-pricing`, `event-sponsor-prospectus`, `event-sponsor-outreach`, `event-sponsor-agreement`, `event-sponsor-fulfillment`. Buys the revenue line tickets rarely cover. Costs the most of any class: a months-long motion on a counterparty's calendar, counsel on the term sheet, and obligations owed until the event is over.
9. **After and between editions** - `event-feedback`, `event-debrief`, `event-content-repurposing`, `event-continuous-improvement`, `event-community-building`, `event-growth-strategy`, `event-portfolio-strategy`, `tech-podcast-youtube-channel`. Buys the next edition's starting position. Cheap per session, but the payoff lands after this cycle's finish line.

The axes disagree, which is exactly where the choice is hard:

- efficiency: `existence check > spine > fill the room > money model > programme intake > place and duty of care > on-the-day > sponsorship sale > after and between`
- value: `programme intake > fill the room > sponsorship sale > spine > place and duty of care > on-the-day > after and between > money model > existence check`
- effort: `sponsorship sale > programme intake > fill the room > on-the-day > place and duty of care > after and between > spine > money model > existence check`
- compliance cost: `sponsorship sale > place and duty of care > programme intake > on-the-day > fill the room > after and between > money model > spine > existence check (none)` - a signed sponsorship carries exclusivity and a delivery obligation counsel reviews; a venue contract and an access commitment bind you on another party's terms; consent, prize eligibility and jury conflicts need deciding upfront; badge scanning and an approved satellite publish a posture you then owe; list consent and barter delivery are promises to third parties; a refund policy binds once tickets sell; an announced date is a public commitment. The existence check publishes, signs and books nothing.

**Cheap and efficient are different orderings, and this menu shows it twice.** Fill-the-room outranks the money model on efficiency while costing more, since a campaign converts hours into the input every class assumes, and a break-even number seats nobody. After-and-between is near the cheapest class and ranks last, since efficiency is scored inside the current cycle and that class pays the next one.

**Dominance audit, at its point of use.** Nine classes yield 36 unordered pairs. Six carry no trade-off - one class is both more valuable and cheaper - and each gets its own mechanism rather than sharing one:

- _Programme intake over sponsorship sale_, and _fill the room over sponsorship sale_ - **prerequisite inversion**: sponsors buy access to an audience and a programme, so both must exist first; the dominance is sequencing, not preference.
- _Spine over place and duty of care_, _spine over on-the-day_, and _spine over after and between_ - **upstream-decision leverage**: shape, date and timeline are inputs to all three, so a changed date restarts the venue search and a changed shape makes the run of show and retrospective describe a different event.
- _Place and duty of care over on-the-day_ - **the room precedes the day**: the venue contract, code of conduct, roster and risk register are what the day executes, so a run of show written before the room is known gets rewritten.

The criterion weighs value against effort only. This last pair inverts on compliance cost - the contracts and published commitments sit on the room's side, not the day's - so a reader bound by sign-off rather than hours picks it the other way round.

The other 30 pairs each split at least one axis against efficiency, so the ordering does work on them. The efficiency line is also not rank-identical to inverse effort, which would read `existence check > money model > spine > after and between > place and duty of care > on-the-day > fill the room > programme intake > sponsorship sale`, agreeing only at the first position. Matching lines would have collapsed the ranking into cheapest-first.

**What this order starves: the sponsorship sale.** Third on value, eighth on efficiency, the widest gap in the set, because its cost is set by a counterparty's calendar. Left unpromoted, a ratio-first order fills a room for an event whose budget never closes.

Promotion conditions: Q7 (c) or (d), standing weekly hours or funded staff, promotes it to rung 2, since only a standing team can pay a months-long motion; Q6 (c), a closing sponsor budget window, promotes it to rung 1 regardless, since that window does not reopen this cycle.

Delete a ruled-out class; never demote it to last place, because one parked at the bottom silently reappears as scope. A class with an unblocking condition moves to "not now" carrying it; one with none goes unmentioned.

The ordering is a default, not a law. Re-rank against what the interview and detection just told you, and say out loud which answer moved which class:

- Q1a (does not exist yet) promotes the existence check to rung 1 and deletes sponsorship sale and on-the-day - nothing to sponsor, no day to run.
- Q1c (doors within weeks, or on site) promotes on-the-day to rung 1 and deletes the existence check and after-and-between; Q1d (finished) inverts that, reducing the short-list to after-and-between alone. Deleted, not demoted, in both cases.
- Q2a or Q2b (format not fixed) collapses the session to one route - `event-format-selection` - and suspends every gated row.
- Q3a (first edition) promotes `event-first-edition` to rung 1 and deletes after-and-between's cross-edition entries - no prior edition to read.
- Q3d (more than one property) promotes `event-portfolio-strategy` out of after-and-between to rung 2 - a collision between properties is decided before either one's own plan.
- Q4a (volunteer organizers) deletes `corporate-event-strategy` and `business-event-formats`, and promotes the sponsorship sale, since ticket revenue rarely closes the budget alone.
- Q4b (a company funds and owns it) promotes `corporate-event-strategy` to rung 1 and demotes the sponsorship sale.
- Q6a (doors on a fixed date this cycle) promotes fill-the-room, programme intake and on-the-day, and moves after-and-between to "not now".
- Q6b (a CFP or on-sale deadline) promotes whichever of programme intake or the money model owns that deadline, above fill-the-room.
- Q7a (one-off, hours only) cuts the short-list to the existence check and the spine, and deletes sponsorship sale and on-the-day.
- Q7d (standing, with staff or budget) promotes the sponsorship sale and place-and-duty-of-care above their default places.
- Detection moves classes too: a committed budget makes the money model near-free; a published grid deletes `event-schedule-design`; a signed venue contract deletes `event-venue-sourcing` and promotes `event-risk-management`.

## 5. Context artifact

Create or update `event-context.md` at the project root - one versioned file, committed with the project when it lives in git. It is the single source of truth that makes the next start warm, and where a warm start reads its gates.

- On warm start: read it, do not rebuild it. Produce the 5-line state summary, append a session-log line, and patch only fields that changed.
- Optionally patch the project's agent-instruction file with its invariants - format, date, funding model - so future sessions inherit them without loading this skill.
- Do not scaffold a working tree the project has not earned; premature structure hard-codes decisions it has not made.
- Keep a decision log only when the project accumulates contested decisions; otherwise the decided-versus-open field is enough.
- Archive the previous edition's artifact before starting edition N; never overwrite it. The debrief and the trend read both need what the last edition decided.

Fields, a worked example and a negative example are in [`references/context-artifact.md`](./references/context-artifact.md). Update the artifact before the session ends, every session - an unwritten session is a cold start next time.

## 6. Memory

If your harness has persistent memory, derive memory entries from the context artifact - never the reverse. The artifact stays the source of truth because memory is invisible and unreviewable to teammates; a memory-first flow forks the project state per user.

- Persist interview responses after the interview completes and before the § 4 output: write the answers into the context artifact first, then derive the memory entry from it. Never write memory straight from an answer, however obvious the answer felt.

Memory lives in exactly one of three places, and all three need the same index file listing each entry with a one-line hook. Pick from this order, highest value per unit of setup effort first:

1. **A `memories/` directory in the project's git repository.** Setup is a directory and an index file, co-organizers read it where they already read the plan, and every change arrives as a reviewable diff.
2. **A team knowledge base.** Reaches volunteers, sponsor contacts and venue staff who never open a repository. Costs an access setup outside the organizing team, and it drifts because nothing ties a page to a commit.
3. **Local to the user's environment.** Near-zero setup, and nobody else can read it. Use it only when one person organizes alone - a per-user store forks the project state the moment a second organizer joins, and organizer turnover is the failure this collection returns to most.

- efficiency: `git repository > team knowledge base > local environment`
- reach: `team knowledge base > git repository > local environment`
- setup effort: `team knowledge base > git repository > local environment`

Default to the git repository whenever the project already lives in one; choose the knowledge base when the people who need the memory do not work in it.

- On warm start, diff memory against the artifact. When they diverge, propose reconciliation - the artifact wins by default; ask before overwriting either.
- Never put into memory: attendee or speaker personal data of any kind, accommodation requests and the conditions behind them, code-of-conduct reports and the identities in them, negotiated sponsor and venue rates, and any contract term still under negotiation. State this exclusion when you first write memory.
- When memory lives in a git repository, never commit it silently. Show the diff and get approval first, every time.

## 7. Routines

If your harness supports scheduled routines, propose 2 to 4, each shown to the user as a dry-run first and each with an explicit output channel - a routine without one is noise the user silences within a week. A routine's cost is not its setup but its attention per firing times how often it fires; its value is the decision it puts in front of someone while that decision is still open. Rank on that ratio, highest first, and propose from the top down.

The six candidates below are this skill's own construction, not a standard routine set:

1. **Ticket-pace check** → `samber/dev-event-organizer-skills@event-market-fit`. Reads a number the ticketing system produces anyway, against a checkpoint the project already published. Only this routine can trigger a hold, pivot or stop while the money is still refundable.
2. **Work-back checkpoint** → `samber/dev-event-organizer-skills@event-planning-timeline`. Fires at each replanning checkpoint on the plan's own calendar. Its output cuts scope while that is still cheaper than moving the date.
3. **Kickoff re-invocation** → this skill. Costs near-zero per firing. Keeps the artifact and the routing current, which stops every other routine firing at work that no longer exists.
4. **Go/no-go review** → `samber/dev-event-organizer-skills@event-risk-management`. Anchored a step ahead of each rung of the venue's cancellation-fee curve, never at the rung. Carries the highest compliance exposure in the set: the decision is contractual and cannot be unsaid.
5. **Post-edition trend read** → `samber/dev-event-organizer-skills@event-continuous-improvement`. Fires once a debrief lands, reading several editions together. Cannot fire before two exist.
6. **Sponsor pipeline and renewal sweep** → `samber/dev-event-organizer-skills@event-sponsor-outreach`. Fires against the budget windows the pipeline already records. Carries the highest standing cost: every account it names needs a person to chase it.

- efficiency: `ticket-pace check > work-back checkpoint > kickoff re-invocation > go/no-go review > trend read > sponsor sweep`
- value: `go/no-go review > ticket-pace check > sponsor sweep > work-back checkpoint > trend read > kickoff re-invocation`
- effort: `sponsor sweep > go/no-go review > work-back checkpoint > trend read > ticket-pace check > kickoff re-invocation`
- compliance cost: `go/no-go review > sponsor sweep > ticket-pace check == work-back checkpoint == trend read == kickoff re-invocation (none)` - cancelling or postponing fires the venue's cancellation curve and an insurance claim, a decision counsel and a broker are both party to; the sweep's output names accounts and negotiated terms, so its channel must sit inside the project's data posture. The last four tie at zero because each reads an internal artifact - a sales figure, a timeline, a debrief log, a context file - publishes nothing outside the team, and needs no sign-off.

**Dominance audit, at its point of use.** Six routines yield 15 unordered pairs. Four carry no trade-off, each with its own mechanism:

- _Go/no-go review over sponsor sweep_ - **committed money beats uncommitted money**: the review protects spend already made on a contract-fixed date; the sweep chases revenue not yet promised, at a cost proportional to list length.
- _Ticket-pace check over sponsor sweep_ - **a read is not a job**: the pace check queries figures recorded regardless; the sweep produces the outreach itself and needs a human to send it.
- _Ticket-pace check over work-back checkpoint_ - **the instrument already exists**: pace is a query, a checkpoint requires the team to reassemble and re-cut scope, and pace fires earlier, inside the still-refundable window.
- _Ticket-pace check over trend read_ - **within-cycle beats across-cycle**: the pace check changes this edition; the trend read changes the next one and cannot fire until one has finished.

Same caveat as § 4: the criterion is value against effort, and the first of the four inverts on compliance cost - the go/no-go review is the only routine whose output is contractual. The other 11 pairs split at least one axis. The efficiency line is not rank-identical to inverse effort either: inverse effort would lead with the kickoff re-invocation, which sits third here.

**What this order starves: the sponsor sweep.** Third on value, last on efficiency, because its cost scales with the pipeline rather than with the firing.

Promotion conditions, keyed to Q6: answer (c), a closing sponsor budget window, installs it first; keyed to Q7: answer (d), funded staff, makes it affordable at its default place.

Default: rungs 1-3, which is three routines. Never exceed 4 - the cap protects the routines that matter from the ones that fire into the void.

Re-rank against the interview, and say which answer moved which routine:

- Q6a (a fixed doors date) installs the work-back checkpoint first; Q3a or Q3b (a first or one-off edition) deletes the trend read rather than demoting it, since there is no next edition to change, and Q3c or Q3d restores it.
- Q1a (the event does not exist yet) installs one routine only, the kickoff re-invocation; Q7a (one-off, hours only) does the same.
- A signed venue contract on disk promotes the go/no-go review to rung 1, since the cancellation curve is now real; no ticketing source detected deletes the ticket-pace check outright, because there is nothing to query.

Anchor every trigger to a date the event already has - the CFP close, the on-sale date, the venue's cancellation rungs, doors-open, the debrief - never to an arbitrary schedule, and give each routine a stop condition:

- Retire the previous edition's routines before adding new ones.
- If the harness has no scheduled routines, fall back to one recurring calendar reminder ("Event check-in - re-run the event organizer kickoff") and stop there. See [`references/routines.md`](./references/routines.md) for the dry-run format, calendar anchors and cleanup rules.

## 8. Coverage gaps

No skill in the collection covers these. Name the gap; never promise or invent a skill:

- **Registration and ticketing system operation** - platform choice, checkout, on-site box office, refund processing, tax treatment of revenue. `event-ticket-pricing` sets prices and writes the refund policy; `event-landing-page` wires the CTA to whatever system exists.
- **Conference proceedings and a paper track** - peer review ending in a published paper rather than a stage slot. `event-talk-selection` reviews talk proposals only.
- **A community awards programme** - nominations, a jury, an awards ceremony as a segment. `startup-pitch-contest` and `hackathon-judging` each judge one competition against its own entry rules; neither is an awards programme.
- **Running the programme in two languages** - translated tracks, a bilingual host, per-language labelling. `event-accessibility-inclusion` covers interpretation and captioning as access provisions on request, not a second language as a design choice.
- **Attendee travel and accommodation as a programme** - a negotiated hotel block, travel booking, visa invitation letters at attendee scale. `event-venue-sourcing` reads room-block terms inside the venue contract; `event-speaker-sourcing` flags visa lead time for one invited speaker only.

Out of scope by design, not gaps: attending an event rather than running one, sponsoring someone else's, exhibiting on a floor you do not own, and speaking at one.

## 9. Invocation examples

- "Start a new event project - we want to run our first hackathon next spring."
- "Which event skill do I need? Sponsors keep asking what they actually get."
- "Run my event check-in."
- "Where do I start? We have a date and a venue and nothing else."
- "The conference finished last week. What now?"

## 10. Failure modes

- **Forcing a match.** Stretching the nearest skill onto a task it does not cover wastes a session and hides the gap. Say "none fits" and name the gap - or point at `samber/developer-relations-skills` or `samber/developer-platform-skills` when the task belongs to one of them.
- **Re-deciding the format.** The gates read `event-format-selection`'s answer; they never produce one. Routing "should we go hybrid" to `hybrid-event-design` hands the user a session that assumes the decision it was asked to make.
- **Applying a gate to an unfixed format.** When Q2 came back (a) or (b), every gated row is unreachable. Route to `event-format-selection` and stop, rather than guessing a shape to unlock rows with.
- **Promoting a leaf route.** The three deliberately narrow rows named in § 3 defer most of their subject to a sibling. Presenting one as load-bearing sends the user into a sliver when the sibling holds the decision.
- **Re-interviewing on a warm start, or exceeding the cap on a cold one.** The artifact exists so questions are not repeated; past seven questions the kickoff becomes a form the user abandons. Detection fills the gaps - a committed budget or a published grid answers more than any question does.
- **Routing from a guessed scope.** Route only from declared scopes; a plausible guess misroutes confidently.
- **Routing a lane, not a subject.** One lane splits on what is judged: work built during the event (`hackathon-judging`) versus companies that existed before it (`startup-pitch-contest`). Two split on which side of a boundary the user sits: your satellite programme versus another organizer's event (`event-side-event-coordination` versus `cross-event-promotion`), and your own channels versus another outlet's (`event-social-media` versus `event-media-partnerships`).
- **Routines with no output channel, or none that ever retires.** They fire into the void and get silenced, burying the one routine that mattered; an event has a finish line, so almost every routine needs a stop condition.
- **A flat short-list, or one led by the cheapest option.** Equal-looking options get picked by taste or by whichever sits first, and cheap is a different ordering from efficient.
- **Ranking the routing table or the chain.** Scope is a match test and a chain is a dependency order; imposing a ratio on either invents a preference that does not exist.
- **Demoting a ruled-out class instead of deleting it.** Parked at the bottom of the short-list, it reappears as scope two sessions later.
- **Memory committed silently, or carrying a person.** Co-organizers cannot review what they never see land, and attendee data, accommodation requests and conduct reports must never reach memory at all.
- **Stale routing table.** Update this skill - the tables, the gates, the reference files, the gap list - whenever the collection changes: a skill added, renamed, removed, or re-scoped. A stale router sends users to skills that no longer exist, which is worse than no router at all.

## 11. Pass bar

Before ending the session, check every item. Fix and re-check any that fails; never close on a failing bar.

1. Every recommended skill's declared scope matches the stated task - re-read its description to confirm.
2. Zero routes to a name outside the tables in § 3.
3. Every gate applied was read from an answer or an artifact, never inferred from the event's name or the user's tone.
4. The interview stayed within its cap: at most seven questions cold, only the session goal warm.
5. `event-context.md` was written or updated, with a session-log line, before the session ended.
6. Every proposed routine was shown as a dry-run and has an output channel and a stop condition.
7. The short-list and the routine set are both ordered by value per unit of effort, each entry naming the bottleneck it attacks and what it costs, with the re-rank stated out loud whenever an answer moved something off its default place.
8. Every ruled-out class left the short-list entirely, and the routing tables and any chain were left unranked.