
event-learning-expedition-design
Decide whether to take a technical audience into an organization the organizer does not control, and on what terms - when a host's own premises, operation and staff are the programme rather than a room rented and filled by the organizer. Sets the host-dependency posture (host speaker hosted in-house, one host site host-led or to a negotiated agenda, a multi-host circuit) and the access posture, meaning what the host lets attendees see and repeat afterwards. Use whenever asked to design a learning expedition, company tour, field trip, site-visit programme or executive immersion. Do NOT use for catering - use samber/dev-event-organizer-skills@event-hospitality - or multi-venue logistics - use samber/dev-event-organizer-skills@event-production. States no legal threshold or instrument.
- Installs
- 5.2K
- Last 24h
- +175
- Trending rank
- #1376
- Security
- Pass
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/samber/dev-event-organizer-skills --skill event-learning-expedition-design- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads event-learning-expedition-design automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
Security audits
Independent scans of the skill's instructions and bundled files.
SKILL.md
The instructions your agent reads when the skill is triggered.
Event Learning Expedition Design
You take your own audience into somebody else's building, where that organization's working operation is the programme. Two decisions follow, and this skill owns nothing else: how much of your agenda depends on a host you cannot direct, and what the host lets your attendees see and repeat.
Read first: the scope is much narrower than the name
A "learning expedition" sounds like a whole event format. Inside this collection it is not, and pretending otherwise hands you advice a sibling skill gives better.
Most of what the format is taken to include already has an owner here, and each owner covers it in more depth than this skill can:
- Several sites in one agenda. Not a new mechanic.
samber/dev-event-organizer-skills@event-venue-sourcing's reference file settles it: multi-venue events "inherit this whole sheet once per site, plus the transit time between them and a single named owner per site. That much is straightforward extension." Take the sheet from there. - Transport and the headcount problem.
samber/dev-event-organizer-skills@event-hospitalityranks an offsite excursion below doing nothing at all: "only one of them spends transport, a second building's own rules and insurance ask, and a headcount you cannot correct once the transport has left." That argument applies to you unchanged. One exception: a visit that is a social evening rather than the programme is that skill's subject, not this one's. - Whether your policy reaches the coach and the host's floor.
samber/dev-event-organizer-skills@event-code-of-conductowns the scope clause. Its reference file records MLH covering "all hackathon venues, hackathon-related social events, hackathon-supplied transportation, and online interactions related to the event." and notes that "a shuttle is neither the venue nor a social event". Hand it the sites and the vehicles, and take back the clause. - Catering on the move, and every supplier who moves with you.
samber/dev-event-organizer-skills@event-hospitalityfor the service style,samber/dev-event-organizer-skills@event-vendor-sourcingfor the contract. - Who you invite and why.
samber/dev-event-organizer-skills@business-event-formats. Its shape ladder ranks the account-depth family, and its compliance axis carries the mechanic people reach for here: "an accepted invitation cannot be withdrawn without insult, and it lands on the guest's own gift and anti-bribery policy before it lands on yours." A named guest with a protocol obligation issamber/dev-event-organizer-skills@event-vip-management; a journalist issamber/dev-event-organizer-skills@event-press-relations. - Capturing the visit and publishing anything from it.
samber/dev-event-organizer-skills@event-productionthrough the master file, thensamber/dev-event-organizer-skills@event-content-repurposing. Its rights gate governs you: "Silence is off-limits, not permission." - Why the event exists, what it costs and how it is measured.
samber/dev-event-organizer-skills@corporate-event-strategy. Perception shift and pipeline influence are that skill's goal-and-measurement vocabulary, not yours.
What is left is one structural fact, and it is real. Everywhere else in this collection, a third party supplies either the room or the content.
samber/dev-event-organizer-skills@event-venue-sourcing gets you a room you then fill. samber/dev-event-organizer-skills@event-side-event-coordination handles an event somebody else runs for their own reasons - "Where that skill's evening is the thing you provide, yours is the thing you permit."
Here the host supplies both. So a host who withdraws does not cost you a room you can re-book: it deletes the programme.
Nothing in the collection covers that. Nothing covers what a host organization - which is not a speaker, not a sponsor and not a vendor - permits your attendees to see and to repeat. The consent chain this collection runs on goes organizer to speaker, and it has no branch for the organization that opened its floor.
Route any question other than those two decisions to the owners above, and stop. This skill is short because those two decisions are all it owns.
Do not invent a number for any deliverable built from this skill. A site count, group size, briefing length, lead time, or host-approval turnaround is the host's to state, and an invented number outlives the caveat attached to it. Describe the constraint qualitatively and ask the host.
This skill states no legal threshold, jurisdiction, form, instrument name or monetary figure. That is the standing policy samber/dev-event-organizer-skills@event-side-event-coordination holds for liability and samber/dev-event-organizer-skills@hackathon-cash-prize holds for prize law. The access-posture rungs describe postures, not instruments, and any paper they need is counsel's to name.
Interview
Ask one question at a time, multiple-choice where possible. Every condition on both menus names the question it is keyed to, so answer these before ranking anything.
- Has a host organization agreed in writing to receive your audience, or is this a format idea with nobody's yes behind it? If there is a yes, was it conditioned on anything?
- Why does the audience need to be physically there: is there a thing that cannot be shown on a slide - a floor, a hall, hardware, a scale, a failure - or is the draw the people and the conversation?
- What is the audience's own question: a specific technical one they could push a named engineer on, or an experiential one about how an organization operates day to day?
- Inside the host, who is the named counterpart, and can that person commit their colleagues' time, or only their own?
- Has the host stated a restriction - an area, a customer name, a photography rule - and did that come from someone who speaks for the host, or from your own assumption about what they would want?
- Is the attendee list bounded and known before the day, or open until the door?
- Who, by name, would run a post-event clearance queue, and for how long after the event would they still be doing it?
- What is the effort ceiling and the date: how many people can own this end to end, how much runway exists, and how survivable does a host's cancellation have to be?
- What already exists that the default ordering assumes away: a standing relationship with a candidate host, an organizer employed by one, a prior edition's expedition, or an agreement already signed with any of them?
Both rankings below are defaults, not laws, and they shift with context and with who executes them. Re-rank against Q9 before recommending anything: an organizer who already works inside a candidate host turns a cold approach into a calendar invitation, and promotes that rung above whatever the default picked.
Workflow
- Run the interview, Q1 first. If nobody has said yes, you are choosing a format rather than designing one, and
samber/dev-event-organizer-skills@business-event-formatsowns that choice. - Route out everything in the scope section above before going further. Most of what arrives as "design our learning expedition" leaves before either menu is reached.
- Fix the value axis on the first menu from Q2 and Q3 before ranking it. This is the mechanic
samber/dev-event-organizer-skills@business-event-formatsuses for its own shape ladder - take it from there rather than re-deriving it. - Pick the host-dependency posture, applying its delete rules before ranking.
- Pick the access-and-repeatability posture, applying its delete rules before ranking.
- Write the host brief: what your audience is coming to understand, what you are asking their people to do, and what you have told your attendees they may repeat. Send it before the host's internal approvals start, not after.
- Hand off, explicitly and by name:
- Sites and vehicles to
samber/dev-event-organizer-skills@event-code-of-conduct, for the scope clause. - The per-site requirements sheet to
samber/dev-event-organizer-skills@event-venue-sourcing. - Transport, catering and the headcount to
samber/dev-event-organizer-skills@event-hospitalityandsamber/dev-event-organizer-skills@event-vendor-sourcing. - Anything recorded to
samber/dev-event-organizer-skills@event-production. - Goals and measurement to
samber/dev-event-organizer-skills@corporate-event-strategy.
- Sites and vehicles to
- Present each decision for validation before anything is promised to a host or published to attendees. A host's approval process is the point of no return: once their people have blocked the time, a change costs their goodwill, not your calendar.
If your harness has persistent memory, record which host said yes and on what condition, the access posture agreed and who agreed it, and the restriction list. A host relationship is the only durable asset this format produces, and the one thing the next edition cannot rebuild from a document.
Host-dependency posture
How much of the agenda depends on an organization that has no obligation to you. Four rungs:
- Host representative in your own room: you invite their engineer to speak where you already control the room. No site.
- One host site, host-led: you go to them and they show what they show visitors.
- One host site, negotiated agenda: you specify what your audience needs to see and they build to it.
- Multi-host circuit: several host organizations in sequence.
Two value axes, and they genuinely disagree. That is why Q2 and Q3 have to be answered before this menu is ranked.
- effort (securing a host with no reason to say yes, briefing their staff, transit between sites, a headcount fixed before departure, an escort per site, and the rebuild when one host withdraws):
multi-host circuit > one host site, negotiated agenda > one host site, host-led > host representative in your own room - value, place - what the audience sees on site that no talk reproduces:
multi-host circuit > one host site, negotiated agenda == one host site, host-led > host representative in your own room - value, fit - the audience's own question gets answered, in their vocabulary, by someone they can push:
one host site, negotiated agenda > host representative in your own room > one host site, host-led == multi-host circuit - compliance cost, as the review it triggers on the host's side - visitor screening, site safety induction, their own confidentiality and customer-data rules - and what stops being reversible once your audience is standing in their building:
multi-host circuit > one host site, negotiated agenda > one host site, host-led > host representative in your own room - efficiency, place per unit effort, the line to use when Q2 names a physical thing:
one host site, host-led > one host site, negotiated agenda > multi-host circuit > host representative in your own room - efficiency, fit per unit effort, the line to use when Q3 names a specific technical question:
host representative in your own room > one host site, negotiated agenda > one host site, host-led > multi-host circuit
The place == is argued: a host-led visit and a negotiated one both put the audience inside one real building, and the building is what the axis measures. They differ in what is shown there, which is the other axis's job.
The fit == is argued too, and at the same level rather than at zero: a host-led agenda is a host-led agenda whether the audience sees one of them or a sequence of them, so a circuit multiplies places without improving the answer to anybody's question. That tie does not survive division: equal fit at strictly higher effort is strictly worse fit-efficiency. That is why the circuit sits last on that line rather than level with the host-led rung.
Compliance tracks effort rung for rung here. Admit that rather than presenting it as a second signal: both scale with how far inside somebody else's organization you go, and with how many organizations that is. The axis stays because the exposure is real - a host's screening and induction requirements are theirs to set and you cannot negotiate them down - but it discriminates nothing the effort axis did not already say.
Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations. Covering all six takes two mechanisms, and one alone would cover only half:
- Blocked by opposed value axes (3 pairs): own-room against host-led, own-room against the circuit, negotiated against the circuit. In each, whichever rung leads on place trails on fit.
- Blocked by cost alone (3 pairs): own-room against negotiated, host-led against negotiated, host-led against the circuit. In each, the rung ahead leads on both value axes (tying one of them in the last two) and still costs strictly more on effort and on compliance.
That accounts for all six.
The two value axes are not exact inverses of each other. They tie in different places, so this check carries real information rather than being clean by construction.
-
One host site, host-led - the default. It buys the whole "they were actually there" effect for the least coordination, and it is the rung a host can say yes to without convening anybody. Promote it to the negotiated agenda when Q3 says the audience's question is specific and Q4 names a counterpart who can commit their colleagues' time. Both, not either: a specific question with nobody inside to route it produces a standard tour with your hopes attached.
-
Host representative in your own room. Tops the fit-efficiency line and costs almost nothing. When Q3 says the question is technical and specific, this is the honest recommendation: say so plainly and close this skill rather than designing travel around a conversation that fits in a session. Delete it, from this menu and from every axis line above, when Q2 names a physical thing that cannot be shown on a slide. A talk is not a smaller version of standing on the floor, and a deleted rung left at the bottom returns later as a cost saving.
-
One host site, negotiated agenda. The rung that answers a specific question, at the price of an internal owner inside the host. Delete it, from this menu and from every axis line above, when Q4 finds no counterpart who can commit colleagues' time. Without one it is not a cheaper negotiated agenda. It is the host-led rung plus meetings, which is the worst cell on this menu.
-
Multi-host circuit - the starved rung. Tops place, tops both cost axes, and neither efficiency line ever picks it. Promotion conditions are keyed to Q9 and Q8, each carrying its own weight:
- Q9: standing relationships with more than one candidate host, so each additional site is a call rather than a cold approach.
- Q8: enough runway that one host withdrawing does not collapse the day.
Both conditions apply together, not either alone - a circuit built on cold approaches with no slack is the one configuration where a single withdrawal deletes the programme after the travel is booked.
Access and repeatability posture
What the host lets your attendees see, and what they may repeat afterwards. Four rungs:
-
Open on the record: nothing restricted. Attendees may photograph, write and speak freely.
-
Named ground rules, no instrument: a rule the organizer states and publishes, accepted by attending - a named area not photographed, nothing attributed to an individual, with nobody signing anything.
-
Per-attendee written undertaking: each attendee signs something before entry, on the host's terms.
-
Host-controlled, organizer-relayed clearance: attendees see freely, and the host reviews anything they want to publish afterwards, through you.
-
effort (negotiating with a host's legal function, collecting signatures, handling the person who refuses at the door, running a queue that outlives the event):
host-controlled, organizer-relayed clearance > per-attendee written undertaking > named ground rules > open on the record -
value, access - how much the host is willing to actually show:
per-attendee written undertaking > host-controlled, organizer-relayed clearance > named ground rules > open on the record -
value, takeaway - what an attendee can carry back and use without asking anyone:
open on the record > named ground rules > per-attendee written undertaking == host-controlled, organizer-relayed clearance -
compliance cost, as the review it triggers and the reversibility it costs:
per-attendee written undertaking > host-controlled, organizer-relayed clearance > named ground rules == open on the record -
efficiency, access per unit effort:
named ground rules > per-attendee written undertaking > open on the record > host-controlled, organizer-relayed clearance -
efficiency, takeaway per unit effort:
open on the record > named ground rules > per-attendee written undertaking > host-controlled, organizer-relayed clearance
The access ordering rests on one argument, and that argument stays genuinely contested. Its claim: what a host shows tracks how much residual risk the host still carries at the moment the audience walks in. An undertaking binds the room before anyone sees anything, which is what actually unlocks a floor; a review-afterwards regime does not stop what was seen from being known, so it unlocks less despite feeling stricter.
Two accounts bear on that claim, and they point in opposite directions:
- For a pre-entry instrument, and narrower than it sounds. Securities law lets an issuer share material nonpublic information on a facility visit without triggering Regulation FD only when the visitor agreed to confidentiality beforehand, a legal permission with no after-the-fact equivalent. That is evidence a pre-entry instrument controls whether disclosure is permitted, not evidence that hosts show more once one is signed.
- Against the ordering, and the only documented account of what an NDA actually bought a visitor. An engineer who signed a photography and social-media ban before a factory tour wrote that nothing he saw was information other, non-NDA visitors hadn't already published, and that the agreement's main effect was to raise his own sense of the visit's value rather than what he was shown.
Treat the ordering as a defensible default, not a settled one: the strongest direct evidence on what hosts actually reveal runs the other way. For both accounts and the counter-cases beside them, read references/precedent-and-evidence.md.
The takeaway == is argued: under both bottom rungs an attendee cannot repeat what they saw without somebody else's permission. They differ in who holds the pen and when, not in whether the attendee is free.
The compliance == is argued at zero: neither of the top two rungs on that line creates any instrument or obligation at all, so neither triggers a review - they differ in what is said, not in what is signed.
The takeaway efficiency line discriminates nothing, and say so when using it. It is rank-identical to inverse effort, so dividing takeaway by effort changes no position and the line collapses into cheapest-first - the one ordering a ranking exists to prevent. It stays the correct order when a freely repeatable takeaway is the whole point, but it cannot catch an error, so never let it pick the posture on its own.
Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations. Covering all six takes two mechanisms:
- Blocked by opposed value axes (5 pairs): open against ground rules, open against the undertaking, open against relayed clearance, ground rules against the undertaking, ground rules against relayed clearance. In each, the rung ahead on access is behind on takeaway.
- Blocked by a single cost axis (1 pair): the undertaking against relayed clearance. The undertaking leads on access, ties on takeaway, and is cheaper on effort, so effort does not block it and compliance is the only thing that does. Remove the compliance axis and the undertaking dominates relayed clearance outright.
That accounts for all six.
Be honest about what this check is worth. Access and takeaway are near-inverses of each other by the nature of the subject: what a host shows more of is what an attendee may repeat less of. So five of the six pairs are blocked by construction, and the undertaking-against-clearance pair is the only one where the check carries information - the pair a reader is most likely to get wrong.
-
Named ground rules - the default. What reassures a host is that somebody named is responsible for the room, not that a crowd of strangers each signed a page. It buys most of the host's willingness for a fraction of the cost of an instrument, and creates nothing anyone has to review. State the rules to attendees before they travel, not at the door - a rule someone learns after arriving is a rule you are asking them to accept under pressure.
-
Open on the record. Cheap, honest, and the right answer whenever the host is showing what its own website already shows. Delete it, from this menu and from every axis line above, when Q5 reports a restriction stated by someone who speaks for the host. Publishing an open-record posture over a site with a restricted area is a rule you have broken before the coach leaves. Parked at the bottom, it comes back as "let's just not make a fuss about it".
-
Per-attendee written undertaking - the starved rung. Tops access and tops compliance, and sits second on effort behind relayed clearance. So the takeaway line never picks it, and the access line picks it only once the ground rules have failed. Promotion conditions are keyed to Q6 and Q1, each carrying its own weight:
- Q6: a bounded attendee list known before the day, because a signature drive against a list still open at the door is a door failure rather than a policy.
- Q1: the host's yes was conditioned on it.
Both conditions apply together, not either alone. Whatever the instrument turns out to be is counsel's to name, and this skill names none.
-
Host-controlled, organizer-relayed clearance. The only rung whose cost continues after the event ends. Delete it, from this menu and from every axis line above, when Q7 names nobody to run the queue, or names someone who will not still be doing it when the requests arrive. An unrun clearance queue is two failures at once: a promise to the host you will break, and an attendee's write-up that sits unpublished forever with no one to chase.
Failure modes
- Designing the day before a host has said yes. Q1 exists to stop this. A format with no host is a choice between formats, and
samber/dev-event-organizer-skills@business-event-formatsowns it. - Treating a host like a venue. A venue that falls through costs you a room you re-book. A host that falls through deletes the programme, because the host was the programme.
Carry that difference into every date and deposit decision, and never copy the several-venues-against-several-dates mechanic from
samber/dev-event-organizer-skills@event-venue-sourcing. A second host is not a substitute for the first. It is a different event. - Assuming a restriction the host never stated. Self-imposed secrecy is the most common way an expedition produces nothing anyone can use. Q5 asks who the restriction came from precisely because the usual answer is "we assumed".
- Assuming the absence of a restriction. The mirror failure, and the more expensive one.
samber/dev-event-organizer-skills@event-content-repurposing's rights gate has the rule for it: "Silence is off-limits, not permission." - Letting the host's marketing team write the agenda. A host-led visit that turns into a product demonstration has cost your audience a journey to watch a webinar. Say at the brief stage what the audience is coming to understand, then check the agenda against that sentence.
- Re-deriving transport, catering or the per-site requirements sheet here. All three have owners named in the scope section, and all three are better covered there than anything this skill could say.
- Forgetting the vehicle. The scope clause has to name it.
samber/dev-event-organizer-skills@event-code-of-conduct's own reference file says why: "a shuttle is neither the venue nor a social event". - Inventing a number. A site count, a group size, a lead time, a host-approval turnaround: every one is the host's to set, and none generalises from one host to the next. Ask the host, and record their answer as theirs.
Measurement
Every gate below is self-set rather than an external benchmark. Say so when you present them. Whether the event as a whole succeeded belongs to samber/dev-event-organizer-skills@corporate-event-strategy.
Pass threshold (structural, one only): before any attendee is told where they are going, all four of these exist in writing with zero blanks:
- The host's yes, and any condition attached to it.
- The named counterpart inside the host.
- The access posture, with the restriction list it was built from.
- The person named to handle anything an attendee wants to publish afterwards.
Iterate until the count is four. A blank in any of them is the failure this skill exists to catch.
Signals worth recording afterwards, all self-set:
- Whether any host withdrew, and at what notice.
- Whether the agenda that ran matched the brief you sent.
- How many attendees asked to publish something, and how long each waited.
- Whether the host would receive you again.
That last one is the only signal that compounds, and the one nobody writes down.
Invocation examples
- "We want to take our conference attendees to a hyperscaler's datacentre before the event opens. How do we structure it?"
- "A hardware company offered to host our community for a factory tour. What do we need to agree before we say yes?"
- "Our attendees want to see how a big engineering org actually runs CI. Should we visit one, or just get someone from one on stage?"
- "The host wants everyone to sign something before entry. Is that normal, and what does it cost us?"
- "Can attendees blog about what they saw on the site visit?"
Expected output: an expedition brief with:
- The routing list - everything in the request that belongs to another skill, named.
- The host-dependency posture, with the rungs deleted and why each was cut.
- The access-and-repeatability posture, with the restriction list it was built from.
- The host brief itself.
- The explicit handoffs.
- For each choice, the interview answer that would flip it.
Presented section by section for validation before anything is promised to a host.
References
- references/precedent-and-evidence.md - read it for the one documented technical conference to have run a host-site programme, a same-named format that is not this skill's subject, the evidence on both sides of the access-ordering argument, and published group-size, site-count and lead-time ranges from named study-tour operators.
Key handoffs to other skills in the collection:
samber/dev-event-organizer-skills@business-event-formats- whether this format is the right shape at all, and the account-depth family people reach for when they say executive immersion.samber/dev-event-organizer-skills@event-code-of-conduct- the scope clause that has to name the host's premises and the vehicle.samber/dev-event-organizer-skills@event-hospitality- transport, catering service style, the uncorrectable headcount, and the offsite evening when the visit is social rather than the programme.samber/dev-event-organizer-skills@event-vendor-sourcing- the contract with any supplier who moves with you.samber/dev-event-organizer-skills@event-production- capture through published master, if anything is recorded.samber/dev-event-organizer-skills@corporate-event-strategy- goals, funding and what the event commits to being measured on.
The scope section above routes to further siblings for venue requirements, content rights, VIP guests and press relations. Read it for the complete routing list.
FAQ
What does the event-learning-expedition-design skill do?
Decide whether to take a technical audience into an organization the organizer does not control, and on what terms - when a host's own premises, operation and staff are the programme rather than a room rented and filled by the organizer. Sets the host-dependency posture (host speaker hosted in-house, one host site host-led or to a negotiated agenda, a multi-host circuit) and the access posture, meaning what the host lets attendees see and repeat afterwards. Use whenever asked to design a learning expedition, company tour, field trip, site-visit programme or executive immersion. Do NOT use for catering - use samber/dev-event-organizer-skills@event-hospitality - or multi-venue logistics - use samber/dev-event-organizer-skills@event-production. States no legal threshold or instrument.
How do I install event-learning-expedition-design?
Run npx skills add https://github.com/samber/dev-event-organizer-skills --skill event-learning-expedition-design in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/event-learning-expedition-design/ (personal) or .claude/skills/event-learning-expedition-design/ (project).
Which AI agents can use event-learning-expedition-design?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is event-learning-expedition-design safe to install?
Security partners have reviewed it: Gen Agent Trust Hub passed; Socket passed; Snyk passed. As with any skill, read the SKILL.md and bundled scripts before installing.
Who maintains event-learning-expedition-design?
It is published by samber in samber/dev-event-organizer-skills. It has 5,247 recorded installs.
More from samber/dev-event-organizer-skills
tech-podcast-youtube-channel
samber/dev-event-organizer-skills
Run an organizer's own standing podcast or video channel as a cross-edition media property - whether to sustain a channel at all, the cadence commitment and its named owner in the quiet months, guest sourcing from the speaker pool outward, the two-way feed with the event cycle, and the wind-down or handover when organizers change. Use whenever the user mentions starting a conference podcast or YouTube channel, publishing between editions, where episode guests come from, who owns the show when an organizer leaves, or closing one down - even if they never say "podcast". Do NOT use for cutting one edition's talk recordings into clips - use samber/dev-event-organizer-skills@event-content-repurposing instead.
dev-event-hiring
samber/dev-event-organizer-skills
Employer-side hiring for tech-event-organizing roles - producer/manager/coordinator, and the community-manager-shaped end of the field. Calibrates the scorecard to operating context (in-house, agency, non-profit/community, or a standing conference business), builds the loop from the general event-planner sequence plus CMX's five-competency set and paid mini-audit work sample, flags the "one hire owns sponsorship, content and production" consolidation pattern seen in postings, sources candidates from general event-industry boards since no tech-specific one exists, and gates compensation on named sources (PCMA, BLS, Glassdoor) rather than a blended figure. Use when the user asks how to hire an event producer or manager, write a posting, design a loop, or hire an event community manager. Do NOT use for candidate prep (samber/dev-event-organizer-skills@dev-event-career) or team org design (samber/dev-event-organizer-skills@event-team-structure).
hackathon-brief-design
samber/dev-event-organizer-skills
Write the hackathon challenge document teams read before they build - problem statements sized to the time box, thematic challenge tracks, the published rules and eligibility text, the submission-artifact checklist, sponsor-challenge framing, and naming (never weighting) the evaluation categories. Use whenever the user mentions a hackathon brief, challenge or track prompts, hackathon rules or eligibility, submission guidelines, or turning a sponsor's API into a challenge - even if they never say "brief". Challenge tracks here are thematic categories a team enters, not parallel session streams. Do NOT use for rubric weights and judging mechanics - use samber/dev-event-organizer-skills@hackathon-judging instead.
event-budget
samber/dev-event-organizer-skills
Build the budget and P&L for a technical event - every cost line split into fixed and per-head, the revenue mix against the funding model, a Good/Better/Best scope-tier ladder so break-even has three answers instead of one, a contingency sized as a stacked floor, pad and downgrade ladder whose cuts also price lost sponsor reach, a cross-edition reserve policy, annual funding decoupled from single events, and outflows scheduled against the dates sponsor and ticket money actually lands. Use whenever asked to build an event budget, model conference or hackathon costs, find break-even, size a contingency reserve, set a reserve or surplus policy across editions, fund a recurring meetup series annually, plan event cash flow, or decide what to cut when revenue falls short. Consumes prices and real vendor quotes, never sets them. Do NOT use to set ticket or sponsor prices - use samber/dev-event-organizer-skills@event-ticket-pricing or samber/dev-event-organizer-skills@event-sponsor-pricing.
event-date-selection
samber/dev-event-organizer-skills
Pick the date a technical event runs on - the decision every other plan hangs off. Covers weekday versus weekend from whose calendar the audience lives on (working professionals versus students), seasonality and the calendars constraining the real audience, competing and anchor events scanned for both conflict and deliberate piggybacking, candidate windows negotiated against venue availability instead of one date fixed first, and the announcement gate on payment handling existing. Use whenever asked to choose an event date, pick a conference weekend, check date conflicts with other events, decide how far ahead to announce, or resolve a clash with a competing event. Do NOT use for the work-back schedule from that date - use samber/dev-event-organizer-skills@event-planning-timeline.
event-landing-page
samber/dev-event-organizer-skills
Build a technical event's public front door and the small site around it - the page shape for the funding model (a ticketed event's single-CTA hero, or a free event's stats hero with no registration to sell), the section set, a date-gated CTA state machine so Propose renders only during the CFP window and Register only inside the registration window, the accessibility target, and the event structured data. Use whenever asked to build or review a conference, meetup or hackathon website, write the event home page, decide what the page should show before tickets go on sale, or run a pre-launch check on an event site. Do NOT use to set prices or positioning - use samber/dev-event-organizer-skills@event-ticket-pricing or samber/dev-event-organizer-skills@event-positioning.
Popular education & science skills
teach
mattpocock/skills
Teach the user a new skill or concept, within this workspace.
scaffold-exercises
mattpocock/skills
Create exercise directory structures with sections, problems, solutions, and explainers that pass linting. Use when user wants to scaffold exercises, create exercise stubs, or set up a new course section.
paper-context-resolver
lllllllama/rigorpilot-skills
Rigor Paper Context helper for README-first deep learning repo reproduction. Use only when the README and repository files leave a narrow reproduction-critical gap and the task is to resolve a specific paper detail such as dataset split, preprocessing, evaluation protocol, checkpoint mapping, or runtime assumption from primary paper sources while recording conflicts. Do not use for general paper summary, repo scanning, environment setup, command execution, title-only paper lookup, or replacing README guidance by default.
caveman-learn
juliusbrussee/caveman
Act on a Caveman learn report - review the ranked token sinks, apply cost-lowering fixes with per-edit consent, and report what those fixes returned. Use when asked to lower an agent's token cost, what caveman has saved, to trim a heavy CLAUDE.md, or to offload re-pasted context into cavemem.
gsap-plugins
greensock/gsap-skills
Official GSAP skill for GSAP plugins — registration, ScrollToPlugin, ScrollSmoother, Flip, Draggable, Inertia, Observer, SplitText, ScrambleText, SVG and physics plugins, CustomEase, EasePack, CustomWiggle, CustomBounce, GSDevTools. Use when the user asks about a GSAP plugin, scroll-to, flip animations, draggable, SVG drawing, or plugin registration.
teach-impeccable
pbakaus/impeccable
DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.