E

event-production

by @samberv
4.4(120)

技術イベントのAV制作を設計するスキル。スマートフォン1台からマルチカメラの映像ミックスまでの収録段階、会場表示と収録出力を分離する信号経路、録音障害モードへの冗長化、AVクルーの役割、会場選定やサプライヤーに渡す技術仕様書、メディア予算と公開パイプラインをまとめる。カメラ・マイク・録画・配信・AVベンダー・障害時のバックアップが必要な会議で使う。

event-productionav-productionlivestreamingvideo-recordingconferenceGitHub
インストール方法
npx skills add https://github.com/samber/dev-event-organizer-skills --skill event-production
compare_arrows

Before / After 効果比較

3 组
使用前

チームは経験だけでマイクと録音経路を決め、既知の障害モードに対する冗長化がなく、収録後に音声欠落やノイズに気づくことが多い。

使用後

この Skill は録音障害モードを先に定義し、独立した第二の録音経路と予備マイクを設計するため、収録ファイルが確実に残る。

SKILL.md

Event Production

You own the technical execution layer: the signal path from a speaker's mouth and laptop to a room's projector, a recording file, and - sometimes - a live stream. Everything upstream arrives decided:

  • samber/dev-event-organizer-skills@event-format-selection decides whether the event is hybrid or streamed at all.
  • samber/dev-event-organizer-skills@event-schedule-design fixes which room at which hour.
  • samber/dev-event-organizer-skills@event-speaker-experience collects what each talk needs.

You turn those into equipment, crew, redundancy and a publication pipeline.

Five boundaries, four of them stated by the sibling from its own side.

  • Venue. samber/dev-event-organizer-skills@event-venue-sourcing names hybrid and multi-venue technical specification as a gap it will not fill: "Do not invent an equipment list or a bandwidth figure. Put it to the venue as a question it must answer in writing" - and routes the specification here and to samber/dev-event-organizer-skills@event-format-selection. You author that specification - guaranteed upstream bandwidth, rigging points, camera positions, uplink redundancy, control-room space - and hand it back as written questions for the venue to answer during negotiation. You never negotiate the contract, and you take the room's seated capacity and walking distances as given.
  • The day. samber/dev-event-organizer-skills@event-run-of-show states the split: "samber/dev-event-organizer-skills@event-production engineers technical redundancy - the backup mic, the second recording path. You own what a room lead does in the ninety seconds after the redundancy fails." Build the backup path before the day starts. Never re-describe live incident escalation here.
  • Speakers. samber/dev-event-organizer-skills@event-speaker-experience collects A/V requirements - "what the talk does, not just what the laptop is: a live demo, an audio clip, a hardware prop and an internet dependency" - and owns how that answer is asked for and acted on. You consume what it collects and you consume its consent record. You never publish a recording the consent record does not cover.
  • Captioning. samber/dev-event-organizer-skills@event-accessibility-inclusion decides whether captioning and hearing loops are needed and to what standard. You deliver them technically, and they land in the same budget line as recording.
  • The supplier. samber/dev-event-organizer-skills@event-vendor-sourcing carries AV and production suppliers in its own scope and states the split from its side: it "selects and contracts that supplier. Never let one skill do both jobs: a supplier picked before the spec exists writes the spec." You author the technical specification the supplier is quoted against and held to; you never run the quote comparison or sign the contract. Hand the brief over before selection starts, not after a quote arrives.

Every ranking below is a default, not a law: it shifts with context and with who executes it. After the interview, re-rank all three menus against what you know:

  • A venue with a house technician and installed cameras.
  • A community that already runs a video crew across editions.
  • An event that has never published a video.
  • An owned equipment stock.

Each of these overturns a default rung.

Interview

Ask one question at a time, multiple-choice where possible. Questions 7-9 exist because the menus diverge sharply on time-to-effect, durability and effort - those orderings cannot be picked for the user.

  1. Is anything captured at all, and in what form: nothing, recorded for later, or streamed live? This is the question that reorders every menu below. Ask it first and get a real answer rather than an aspiration.
  2. What did the format decision actually commit to, and to whom? A promised livestream is a commitment; a hoped-for one is not.
  3. What is the grid - how many rooms run at once, how long is the shortest changeover between sessions, and which sessions are plenary?
  4. What did speaker collection return: live demos, audio playback, hardware props, internet dependencies, non-standard connectors? Which of those has no answer yet?
  5. What is the recording and publication consent posture per session format, and where is that record held? You cannot publish past it.
  6. What does the venue actually give you - a house technician or not, installed projection and sound or not, rigging points, a control-room space, an internet connection with a guaranteed upstream figure or a shrug?
  7. What is the last date the venue or the supplier can still add something? That deadline, not the event date, is what these menus are ranked against.
  8. One-off edition or a recurring event? A recurring event promotes every rung whose payoff lands after this edition ends: a trained crew, a written brief, owned equipment, a repeatable pipeline.
  9. What is the effort ceiling - who runs this on the day, how many people can be doing only production rather than also doing something else, and does anything have to be reversible after the event?
  10. Has accessibility decided on captioning or hearing loops? That decision lands in your budget line and your signal path, and it is not yours to make.
  11. What already exists that should re-rank the menus: cameras the community owns, a crew that has done this four times, a venue that streams its own events, last edition's recordings and what went wrong with them?
  12. Is the audience genuinely distributed, such that reaching a remote half is the point of the event rather than a bonus?

What actually splits this work

This collection usually replaces the B2B/B2C split with community-run versus vendor-run. Test it here rather than assuming it: it splits the crew and almost nothing else.

It holds for crew, which splits into two poles:

  • Community pole. Staffs production with volunteers. The sourced training ladder is built exactly for that pole: a full introduction deck "for events without 'experienced' A/V angels," a brief refresher plus hands-on training "for experienced angels" at a recurring event (C3VOC).
  • Vendor pole. Contracts a supplier. The source addresses it as an external party: "your audiovisual company should be able to provide a camera or cameras" (DevOpsDays).

Those are genuinely different jobs: one is recruiting and training people, the other is writing a brief and holding a supplier to it.

Capture posture is the axis that reorders everything else. Nothing captured, recorded for later, and streamed live are three different events technically, and the difference dwarfs who is paying:

  • Nothing captured. Needs a working room and no pipeline at all.
  • Recorded for later. Needs a clean signal, a reliable file and somewhere to put it. Forgives almost every failure that lasts under a minute.
  • Streamed live. Forgives nothing, needs rehearsal and a dedicated operator (DevOpsDays), carries a takedown risk on published platforms, and consumes an uplink nobody has measured.

State which of the three a recommendation assumes whenever they differ.

When asked to execute a hybrid or streamed format, report what the format costs technically before it is locked, then stop. The format decision belongs upstream; your job is to make sure it is taken with that number visible.

The clearest published finances available say hybrid "AV support" ran "more than double the cost of a physical-only conference," alongside a $484,886 loss in the year that conference ran fully hybrid (ACM SIGCHI, published Nov 2023). It is an academic conference, not a developer one: cite the ratio, never the figure, and never attribute it to a developer conference.

Workflow

  1. Establish capture posture. Nothing, recorded, or streamed. Write it down. Everything downstream is a consequence of this line.
  2. Read the inputs rather than re-collecting them: the grid, the per-speaker A/V needs, the consent record per format, the accessibility decisions, and the venue's own answers.
  3. Pick the coverage tier (see below) per room, not for the event as a whole. A plenary room and a third breakout room rarely deserve the same tier.
  4. Draw the signal path before ordering anything: where audio is captured, where it is mixed, where the room's display feed splits from the recorded feed, and where the crew watches what is actually going out. See references/signal-path-and-redundancy.md.
  5. Engineer redundancy against named failures, not against a general fear of failure (see below). The failure list is sourced; use it rather than improvising one.
  6. Assign crew roles and pick training depth (see below). Name people, not functions.
  7. Write the venue technical specification as questions and hand it back to venue sourcing to put in front of the venue in writing. Do not state a bandwidth figure you do not have - ask for a guaranteed upstream number and get it in the contract. Template in references/av-supplier-brief.md.
  8. Write the supplier brief and hand it to whoever contracts the supplier. See references/av-supplier-brief.md.
  9. Hand the Media cost line to samber/dev-event-organizer-skills@event-budget with its tiering already split (see below). Supply the content; the budget decides the shape.
  10. Rehearse, if anything is live. Rehearsal is sourced as a requirement for streaming, not a nicety, and it is the step that gets cut first. It is also the only place a signal path gets tested end to end before an audience is in the room.
  11. Run the post-event pipeline: verify every file exists and is playable before the crew disperses, then edit, check against the consent record, publish, and send each speaker their own link.

Present the production plan section by section for validation, before anything is ordered:

  1. Capture posture and coverage tier.
  2. Signal path and redundancy.
  3. Crew and training.
  4. Venue spec and supplier brief.
  5. Budget and pipeline.

After the order goes in, changes cost money rather than a conversation.

If your harness has persistent memory, record per edition:

  • The venue's real answers on bandwidth, rigging and house equipment.
  • Which coverage tier each room actually got.
  • Every failure that happened and which redundancy caught it.
  • How long the pipeline took from event to published video.
  • What the supplier actually delivered against the brief.

A venue and a supplier used twice are worth not re-learning.

Coverage tier

Recording is the floor and streaming is the layer above it: that ordering is sourced, not a preference. Published guidance states it plainly - "whether or not you're able to livestream, it's important to record all the talks" (DevOpsDays) - and the same guide's own tiered-budget mechanic makes streaming the first thing a lean tier drops while recording survives.

Ranking (default, not a law - Q1, Q7, Q8 and Q11 re-rank it):

  • effort (equipment, people on the day, rehearsal, coordination with the venue's network): live stream on top of two cameras > two cameras with vision mixing > single operated camera > fixed camera on the board feed > smartphone floor > no capture

  • value (a talk that outlives the day, and a speaker with something to show for it): live stream on top of two cameras > two cameras with vision mixing == single operated camera > fixed camera on the board feed > smartphone floor > no capture - argued tie: both put a watchable, audible talk in the archive, which is the whole of the value for an audience watching later. The second camera buys slide detail and reaction shots, and the operator buys framing; neither buys a talk that did not otherwise exist.

  • compliance cost (the review it triggers, and what stops being reversible): live stream on top of two cameras > two cameras with vision mixing == single operated camera == fixed camera on the board feed == smartphone floor > no capture - argued tie: every recorded rung needs the same thing, a consent record covering that session's format before anything is published, and none of them is harder to obtain than the others. Streaming is the rung that changes the review, because a live feed is published before anyone can check it. A speaker's opt-out has to be honoured in the room rather than in an edit, and background music in a demo can take the stream down on the platform's own initiative (DevOpsDays). A published stream cannot be recalled from the people already watching it.

  • efficiency: fixed camera on the board feed > smartphone floor > single operated camera > two cameras with vision mixing > live stream on top of two cameras > no capture

  • Fixed camera on the board feed - the default and the sourced recommendation: a camera and a recording computer taking audio off the mixing board rather than the camera's own microphone. Near-zero on the day once set, and the board feed is what makes the result listenable. Move up one rung when slides carry the talk and a wide shot cannot read them, or when a plenary is the recording anyone will actually watch.

  • Smartphone floor - the sourced absolute minimum: "if you have no budget for recording talks, a smartphone is better than nothing." It sits second on efficiency rather than first because a phone on a tripod at the back of a room captures room audio, and a talk you cannot hear is not an archive. Use it for a room you were going to leave uncovered, never as the plan for the room that matters.

  • Single operated camera - a person framing the shot, following the speaker, and holding on the slides when the slides are the point. Buys watchability; costs one trained person per room per session.

  • Two cameras with vision mixing - a second angle plus somebody switching between feeds. The camera operator and the vision mixer are two separate named roles in sourced practice, not one person with more work.

  • Live stream on top of two cameras - the starved option: tops value and tops effort, so efficiency never picks it. It also needs the two things the source names explicitly and every organizer under-provisions: rehearsal ahead of time, and at least one person whose only job during the event is running it. Promotion conditions, keyed to Q2, Q2, Q12 and Q6/Q11: an audience that genuinely cannot travel and was promised access, a sponsor commitment that names streaming, a distributed community whose remote half is the point of the event, or a venue that already streams its own events and hands you the uplink.

  • Delete, do not demote: streaming with no rehearsal and no dedicated operator. It reads as the cheap version of streaming and it is not a rung on this ladder - it is the same cost with the failure built in, discovered live, in front of the exact audience the stream existed to serve. Parked at the bottom of a menu it reappears as "we'll just point the laptop at it."

Redundancy depth

...

ユーザーレビュー (0)

レビューを書く

効果
使いやすさ
ドキュメント
互換性

レビューなし

統計データ

インストール数4.3K
評価4.4 / 5.0
バージョン
更新日2026年10月23日
比較事例3 件

ユーザー評価

4.4(120)
5
37%
4
43%
3
13%
2
5%
1
2%

この Skill を評価

0.0

対応プラットフォーム

🤖claude-code

タイムライン

作成2026年10月4日
最終更新2026年10月23日
🎁 Agent 知識カード
アンケート