tech-podcast-youtube-channel — скилл для Claude Code: как установить

---
name: tech-podcast-youtube-channel
description: 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.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.1.0"
---

# Tech Podcast and Video Channel

You run one organizing team's own standing media property: a podcast or video channel that publishes on its own cadence, keeps its own back-catalogue, and outlives any single edition of the event.

Treat the object as a **property**, not an artifact. The outcome is "this show is still publishing next year, and the people it reaches are people the room could not hold."

Inherit the decision to have one. `samber/dev-event-organizer-skills@event-portfolio-strategy` decides whether a recurring media property belongs in the team's set of properties at all; run it once that answer is yes. Never recommend adding or retiring the property itself: that recommendation routes back there.

Produce four outputs:

- an existence posture with a named owner for the months when no edition is imminent
- a guest pipeline scoped to what the team can actually vet
- a written feed relationship in both directions with the event cycle
- a handover that survives the current organizers leaving

## Where the line is

**A recording has three owners in sequence, and you are the third.**

- Capture - signal path, microphone count, redundancy, capture-time consent: `samber/dev-event-organizer-skills@event-production`. Consume a finished recording as episode input; never signal path, mixing, redundancy or editing execution.
- Binding rule: never publish a recording the consent record does not cover.
- Remote capture: `samber/dev-event-organizer-skills@virtual-event-production`.
- The dual-audience case: `samber/dev-event-organizer-skills@hybrid-event-design`.

**One-edition derivatives are `samber/dev-event-organizer-skills@event-content-repurposing`.** That skill states the line from its own side - _"A standing owned-media property is not yours."_ - and its audio-cut rung _"stops being dominated the moment Q8 says a standing audio property already exists"_.

It asks this side to _"state the line plainly from here, and flag that it must be restated from there"_. Plainly, then: **a one-off derivative tied to one edition's captured output is that skill; a standing property with its own format, guest sourcing and cross-edition cadence is this one.** Two-sided and settled.

**The interactive member space is `samber/dev-event-organizer-skills@event-community-building`, and this is the sharpest seam.** Both live between editions and both keep an audience warm. The test is the object:

- that skill animates a space members belong to and can post into, with a membership list and a retention duty on that list
- this skill runs a published content property with a subscriber base that may never overlap the attendee list

Its opening - _"You inherit a space rather than choosing one."_ - is the sentence this skill mirrors for the property. Its interview treats a channel as pre-existing input, listing what already carries the audience as _"an announcement list, an archive, a podcast, nothing"_. Its heaviest rung routes its ceiling to a standing meetup series: it names what it is _"one step from becoming"_ in the event direction and names nothing in the broadcast direction. That silence is this seam.

Across that seam, written from this side only:

- crosses: a new-episode notice is content that skill can push into its space
- stays yours: guests or topics surfaced there are input this skill still sources and vets

Four more, each written from one side only:

- **`samber/dev-event-organizer-skills@event-social-media`** runs the acquisition campaign's channels - _"You own pre-event and live-during posting."_ Yours has no campaign start or end date. A campaign post announcing an episode is theirs to write and post.
- **`samber/dev-event-organizer-skills@event-media-partnerships`** is a different counterparty. Its podcast-exchange rung is _"an organizer or speaker guests on the partner's podcast"_ - someone else's show, traded for visibility. This show is yours; never broker the barter.
- **`samber/dev-event-organizer-skills@cross-event-promotion`** brokers swaps with other organizers, and states that _"the same newsletter-swap mechanics land there when the counterparty runs a media property rather than an event"_. Supply the episode or the date for such a swap; never negotiate it.
- **`samber/dev-event-organizer-skills@event-speaker-experience`** owns the speaker point of contact and the _"documented recording consent with its per-format opt-out asymmetry"_. A stage consent is not an episode release. Never re-open the speaker relationship or collect event consent; collect a separate, episode-specific release.

Two skills in the owner's other collection sit close to this one, named here as a recommendation and never a dependency:

- `samber/developer-relations-skills@tech-podcast-interview-prep` preps a guest for **someone else's** show and excludes this scope in its own words - _"Not for booking the appearance, not for scripting your own channel, not for job interviews."_
- `samber/developer-relations-skills@technical-video-script` scripts one video and excludes _"Not for editing or rendering video, designing a live stage demo, podcast guesting, or writing the article itself."_ A scripted segment inside an episode is that skill's craft; whether the episode exists is yours.

This skill stays event-organizer-specific, gated on the event cycle and the speaker pool. A devtools company's general channel strategy - content pillars, algorithm behaviour, short-form balance - is a different scope for a different audience.

Compliance specifics - guest release wording, music licensing for episode audio, platform terms, hosting retention periods - are review-triggered and route to the organizer's own counsel. Name no jurisdiction and quote no retention period in this skill, following the same principle as `samber/dev-event-organizer-skills@event-content-repurposing` and `samber/dev-event-organizer-skills@event-code-of-conduct`.

## 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 - their defaults cannot be picked for the user.

1. Has `samber/dev-event-organizer-skills@event-portfolio-strategy` decided a recurring media property belongs in your portfolio - yes, no, or never asked? (Never asked means route there first; do not design a cadence for a property nobody decided to have.)
2. What exists today: an edition's captured recordings and derivatives, a published back-catalogue, a channel that has already published episodes, or nothing?
3. Who owns the show in the months when no edition is imminent - one named person, a rotating role, or nobody? Do they have recurring hours when nothing is being produced, and can anyone on the team edit and publish?
4. How often does the event run, and how long is the gap between editions?
5. How large is your speaker pool - past and confirmed-upcoming speakers - and are you allowed to contact them about something other than the event?
6. Who vets a guest, against what, and who holds the episode release records? Does the event's code of conduct bind the show?
7. Is there a hard date this must be live by - a next-edition announcement, a sponsor cycle, a departing organizer's last month?
8. One-off or compounding: is this meant to outlive the current organizing team?
9. What is the effort ceiling in the quiet months specifically, and what happens in the weeks after an edition when everyone is recovering?
10. What assets already exist that these defaults assume away - an in-house editor, a co-organizer who already hosts a show, a community space that surfaces guest names, a back-catalogue worth reopening, a platform account the team already owns?

Every ranking below is a default, not a law. Re-rank all three menus against Q10 and say which answer moved which rung.

## Who is available in the quiet months

Who is available in the months when nothing is being produced (Q3, Q9) reshapes every menu below. Community-run versus company-run matters through one variable only: a company-run event has someone whose job includes the quiet season, while a volunteer team has the people who just finished an edition. Say which pole a recommendation assumes whenever they differ.

## Workflow

1. Run the interview. Stop and route out on Q1 if the property was never decided.
2. Read what already exists: which derivatives `samber/dev-event-organizer-skills@event-content-repurposing` produces and on what latency, and what `samber/dev-event-organizer-skills@event-production` hands over as finished recordings. You start where their outputs land.
3. Choose the existence posture from Menu 1 and name the owner for the quiet months. A cadence with no named owner is a lapse nobody decided.
4. Write the cadence commitment as a sentence the team can be held to, and publish only what it can keep. Under-promise deliberately: the argued failure `samber/dev-event-organizer-skills@event-portfolio-strategy` names is a property that stops, not a property that is small.
5. Choose the guest-sourcing depth from Menu 2. Scope it to what Q6's vetting owner can actually check.
6. Write the feed relationship in both directions (see § The feed relationship), marking each path _exists_ or _aspirational_ the same way `samber/dev-event-organizer-skills@event-portfolio-strategy` marks its funnel paths.
7. Set the episode release instrument with Q6's holder before the first recording - separate from any stage consent, held by a named person, and covering the use the episode actually makes of the recording. Route the wording to counsel.
8. Write the handover from Menu 3 **now**, not when someone leaves. Include the platform account's holder, the release records' custodian, and the retention decision on both.
9. Present section by section - posture, cadence commitment, guest pipeline, feed relationship, handover - and get approval per section before anything is published under the event's name.
10. When the team disagrees on whether to run a channel at all, enter brainstorming mode instead of recommending: two or three candidate shapes with their trade-offs and a recommendation, questions one at a time, each section validated before the next.

If your harness has persistent memory, record:

- the posture and its owner per gap
- the cadence committed against episodes actually published
- every guest and how they were sourced
- the release instrument's holder
- the feed paths marked exists or aspirational
- the handover document with its date
- every rung rejected

The missed months are next year's posture decision, and the rejected rungs are what stops the next organizer re-litigating this from zero.

## Menu 1 - Whether to run a standing channel at all

The existence posture. Two value axes, because "it reaches people the room cannot" and "it never reads as abandoned" are different quantities and no rung tops both.

- effort (recurring hours in the quiet months, booking, editing capacity, and the promise the team then has to keep): `heavy-cadence original > low-cadence original > archive-only feed > no channel`
- value, reach (audience beyond the event's own list, cross-promotion inventory, guest-network growth): `heavy-cadence original > low-cadence original > archive-only feed > no channel`
- value, robustness (the property never reads as neglected, because it never promised more than it delivers): `no channel > archive-only feed > low-cadence original > heavy-cadence original`
- compliance cost (the review it triggers and the reversibility it spends - episode releases, music licensing, platform terms, hosting retention): `heavy-cadence original > low-cadence original > archive-only feed > no channel`
- efficiency: `archive-only feed > no channel > low-cadence original > heavy-cadence original`

**The robustness axis is rank-identical to inverse effort, and that is a defect to own rather than hide.** It is a real quantity - exposure to a promise the team stops keeping rises monotonically with how much the team promised - but as an ordering it discriminates nothing here, and its only mechanical effect is to make the dominance check below vacuous.

It survives as an input only when made capacity-relative: read it against Q3's named owner and Q9's quiet-month hours, not as an intrinsic property of the rung. Do not lean on it to justify the efficiency line; the per-rung ratios below carry that weight alone.

**Six pairs, zero strict-dominance relations, and by-construction is never a pass.** One mechanism blocks all six: reach tracks effort exactly and robustness inverts it, so a cheaper rung is always worse on reach and a better-reaching rung always costs more. No pair is blocked for a second reason and none could have failed, so the check proves nothing; challenge the ratios directly.

- **Archive-only feed** - the default: one named feed that publishes what `samber/dev-event-organizer-skills@event-content-repurposing` already makes, with no original guest-booked episodes and no cadence promise. It leads efficiency because its incremental effort is near-zero - the derivatives get made either way - while it buys a durable, externally searchable home for them and a place for that skill's audio cut to land. Requires Q2 to say derivatives already exist; without them this rung is an empty feed.
- **No channel** - a real answer, and second on efficiency rather than last. The do-nothing rung sits last elsewhere in this collection because there the asset already exists and costs nothing to keep; here "nothing" also means no standing public promise and no live account carrying platform terms. **Promote it outright, deleting the three rungs above it, when Q3 names nobody for the quiet months and Q2 says the derivatives already have somewhere to publish.** A channel nobody sustains is a visible public failure; declining is not.
- **Low-cadence original channel** - episodes on a rhythm slow enough that one person can hold it alone, tied to the event cycle rather than to the calendar, mixing repurposed material with speaker-pool interviews. No interval is recommended here, because none is sourced; derive it from Q9's honest quiet-month answer. Promotion condition, both halves: Q3 names a person with recurring hours in the quiet months, **and** Q8 says compounding. Its cost is not the recording; it is that somebody must find, book and vet a guest every cycle, for the whole gap.
- **Heavy-cadence original channel** - the starved rung: a rhythm fast enough that the next episode is due before the last one has settled, mostly original guest-sourced episodes, with its own growth ambitions. It tops reach, tops effort and tops compliance cost, so efficiency never picks it. Note what it is one step from becoming - a media operation with its own staffing question, which no skill in this collection covers. Promotion conditions, all three:
  - Q3 names an owner who is funded or committed rather than willing
  - Q10 names an in-house editor or a co-organizer who already hosts a show
  - Q8 says compounding
- **Delete, do not demote - announcing a cadence nobody has agreed to hold.** Delete it from this menu and from the axis lines above. It is the cheapest-looking version of the low-cadence rung and it is precisely the failure `samber/dev-event-organizer-skills@event-portfolio-strategy` names: the promise is what creates the visible death, so a stated rhythm with no owner is worse than an unannounced one. State only the rhythm Q3's named person agreed to.
- **Conditional delete - both original rungs, where Q3 names nobody for the quiet months.** Delete them from this menu and from the axis lines above. An original-content channel is a standing booking, vetting and publishing duty; with no owner it is not a cheaper channel, it is an abandoned one with the event's name on it.

### Format effort, outside the menu

Menu 1 ranks how much the team promises. Format decides what each promised episode costs, and it sits outside the menu because any rung can use any format. Organizers describe this effort ladder, cheapest first:

1. **Unedited live stream** - record a conversation or session live and publish it as-is. It skips editing entirely, and the audio can double as a podcast-like format.
2. **Short clips** - cut from existing recordings. Finding the moment is real extraction work, not a free by-product.
3. **Produced podcast** - recorded, edited, published on a feed. The same organizers called it a very hard step.

Read the ladder before promoting to an original rung. A low-cadence original channel built on unedited streams costs far less per episode than one built on produced episodes, so Q9's quiet-month hours stretch further. Two constraints hold anyway:

- A live stream has no edit pass, so nothing can be cut out afterwards. The episode release must cover live publication before going live.
- An unedited stream still needs a named publisher. Unedited is a format choice, not an ownership choice.

The organizers also report that their video channels tend to get posted to only around their biggest conferences, leaving the quiet months empty. That is the lapse pattern Menu 1 warns about. Detail, clip sources and the speaker-loop test: [references/low-effort-formats-and-speaker-loop.md](references/low-effort-formats-and-speaker-loop.md).

## Menu 2 - Guest sourcing depth

Where episode guests come from. Two value axes: fit is whether the guest belongs on this show, reach is the audience they bring that the event does not already have.

- effort (sourcing hours, vetting, booking coordination, building a relationship from zero): `cold outbound > open pitch > pool plus community nomination > speaker-pool only`
- value, reach (listeners the guest brings who are not already yours): `cold outbound > open pitch > pool plus community nomination > speaker-pool only`
- value, fit (relevance, low risk of a mismatched episode, a guest who already speaks the event's register): `speaker-pool only > pool plus community nomination > open pitch > cold outbound`
- efficiency: `speaker-pool only > pool plus community nomination > open pitch > cold outbound`

**The fit axis is rank-identical to inverse effort - the same defect as Menu 1's robustness axis, owned rather than hidden.** Fit is real, and it genuinely falls as you move away from people the event has already selected, but as an ordering it adds no discrimination and makes the check below vacuous. Read it against Q6's vetting owner rather than as an intrinsic rung property: with a strong vetting step the fit gap between the middle rungs narrows sharply, and the efficiency line moves with it.

**Six pairs, zero strict-dominance relations, and by-construction is never a pass.** As in Menu 1, one mechanism blocks all six: reach tracks effort exactly and fit inverts it. No pair is blocked twice and none could have failed.

**No compliance-cost axis is derived here, and that is a decision rather than an omission.** Every rung needs the same instrument: an episode-specific release from every participant, obtained before recording, covering the use the episode makes of it.

**Never treat a speaker's stage consent as covering an episode** - a stage consent and an episode release are different instruments for different publications. Deriving a second consent policy beside the one `samber/dev-event-organizer-skills@event-speaker-experience` already owns is how a team ends up with two.

- **Speaker-pool only** - the default: past and confirmed-upcoming speakers of your own event. It leads efficiency because the relationship, the register match and the vetting are already done, and because Q5's pool is the one guest source an event uniquely has. Requires Q5 to confirm both a pool of usable size and permission to contact it for something other than the event.
- **Pool plus community nomination** - the pool, plus names surfaced by your own audience. Promotion condition: Q10 names a community space that already surfaces guest candidates. The nomination is input, not a booking - sourcing and vetting stay yours, and the space itself stays `samber/dev-event-organizer-skills@event-community-building`'s.
- **Open pitch** - a public call for guests. Promotion condition, both halves: Q5 says the pool is too small or exhausted for the committed cadence, **and** Q6 names a vetting owner with a written bar. An open call is an intake process, and an intake process with no owner is where a mismatched or unsafe guest enters.
- **Cold outbound beyond the network** - the starved rung: approaching people with no relationship to the event at all. It tops reach and tops effort, so efficiency never picks it. Promotion conditions, all three:
  - Q8 says compounding
  - Q9 shows hours for relationship-building that returns nothing for several cycles
  - Q6 names a vetting owner

  Note that this is the sourcing shape `samber/dev-event-organizer-skills@event-speaker-sourcing` and `samber/dev-event-organizer-skills@event-speaker-cold-outreach` already own for the **stage** - reuse their qualification and outreach craft; do not rebuild it here for the show.

- **Delete, do not demote - a guest slot given because a sponsor paid for it, published as an editorial booking.** Delete it from this menu and from the axis lines above. It looks like free guest supply and it converts the property into sponsor inventory, which is `samber/dev-event-organizer-skills@event-sponsor-value-proposition`'s object under a different set of promises. If a sponsored episode is genuinely wanted, it is a sponsorship decision made there and disclosed as one, never a sourcing rung here.
- **Conditional delete - the open pitch, where Q6 names no vetting owner.** Delete it from this menu and from the axis lines above. A public call the team cannot review is not a cheaper pipeline; it is an unvetted publication under the event's name, and the code of conduct binds the show exactly as it binds the room.

## The feed relationship

Write it in both directions, one line per path, each marked _exists_ or _aspirational_ - the same discipline `samber/dev-event-organizer-skills@event-portfolio-strategy` applies to its funnel map, whose own worked example already contains one of these paths.

What the event cycle gives the channel:

- finished recordings
- a speaker pool to book from
- a reason to publish in the weeks around an edition

What the channel gives back:

- a reason to contact a prospective speaker before you need them
- a reason a prospective speaker wants to come (see § The speaker-recruitment loop)
- cross-promotion inventory a swap can use
- a surface that keeps working in the gap

Do not promise a registration path in either direction: that is the sibling-stated gap above. The worked shape is in [references/property-shapes-and-cadence.md](references/property-shapes-and-cadence.md).

## The speaker-recruitment loop

Everything above treats the speaker pool as **input** to the channel. Run the reverse loop too: the channel as a **speaker-recruitment asset**.

The hypothesis: a well-watched channel shows a prospective speaker that their talk will reach people beyond the room, which makes them want to come. Organizers hold this belief. Nobody in that report measured it, so treat it as a hypothesis, never as established practice.

- Mark the `channel -> speaker sourcing` path _aspirational_ in the feed map until your own records support it.
- Test it cheaply: add one optional question to the call for speakers or the invitation reply - "did our published videos play a part in your decision?" Record the answer per speaker.
- Hand the evidence to `samber/dev-event-organizer-skills@event-speaker-sourcing` and `samber/dev-event-organizer-skills@event-speaker-cold-outreach`: a link to the speaker's predecessors' published talks is pitch material those skills can use.
- Never promise a view count to a speaker. Promise publication under the release they signed, nothing more.

This loop does not change Menu 1's rankings. It is a second reason to keep publishing, and it only works while the channel visibly publishes; a lapsed channel argues the opposite.

## Menu 3 - Wind-down and handover of the channel

The platform account, the feed, the back-catalogue, the guest-release records and the retention decision attached to them. Not the organizing team (`samber/dev-event-organizer-skills@event-team-structure`) and not the member space (`samber/dev-event-organizer-skills@event-community-building`).

- effort (hours, coordination, political capital spent asking someone to hand over something they built): `named successor with an overlap > documented ownership and access transfer > fold into a closed archive > informal handoff`
- value, recoverability (every credential and every release record ends up with a named, reachable holder): `documented ownership and access transfer > named successor with an overlap > fold into a closed archive > informal handoff`
- value, audience continuity (the people who subscribed keep getting something; voice and guest relationships persist): `named successor with an overlap > fold into a closed archive > documented ownership and access transfer > informal handoff`
- compliance cost (the review it triggers and the reversibility it spends): `named successor with an overlap == documented ownership and access transfer > fold into a closed archive > informal handoff`
- efficiency: `documented ownership and access transfer > fold into a closed archive > named successor with an overlap > informal handoff`

The `==` is argued, not a way of avoiding a decision: both rungs hand a credential to a named holder and both must restate the release records' custody and the hosting account's retention decision. The overlap adds time to the transfer, not a second review. Informal sits lowest for the wrong reason - it triggers no review at all, which is the problem, since the release records stay live with nobody assigned.

**Six pairs, zero strict-dominance relations - and unlike the two menus above, this check had content and could have failed.** The two value axes do not perfectly oppose, so the accounting is per pair, blocked by three different mechanisms:

- three pairs (each real rung against informal) are blocked because the real rung beats informal on both value axes and loses only on cost
- two pairs (documented against successor, documented against fold) are blocked because the value axes genuinely disagree, documented topping recoverability while the other tops continuity
- one pair (successor against fold) is blocked by cost alone: successor beats fold on both values and simply costs more, which is the starved-rung shape

By-construction is still never a pass.

- **Documented ownership and access transfer** - the default: one written page listing the platform account, the feed's control, every admin role, the back-catalogue's location, who holds each today, who holds it after, and the release records' custodian with their retention decision. An afternoon, and it fixes the one failure that actually orphans a show.
- **Fold into a closed archive** - stop publishing, post a dated closing note, keep the back-catalogue reachable, and link it from the standing space `samber/dev-event-organizer-skills@event-community-building` runs. This rung appears on no sibling's handover menu because no sibling's asset behaves this way: a content property keeps a durable address per episode, so search keeps delivering people to a closed catalogue years later, while a frozen chat history returns almost nothing - its value was the live reply, which ends the moment nobody answers. Promotion condition, both halves: Q3 says nobody will own the quiet months going forward, **and** Q2 says a back-catalogue exists worth keeping reachable. A named precedent for choosing this over a handover, on a podcast rather than a conference's own property: Changelog's Go Time ended deliberately after 340 episodes and six years, its hosts stating the decision plainly rather than naming a successor, and a spiritual-successor show launched independently rather than inheriting the account or archive - real evidence that a deliberate close is a chosen alternative to a handover, not only a theoretical rung.
- **Named successor with an overlap** - the starved rung: a successor named before the departure, co-hosting or co-publishing alongside the outgoing owner. It tops audience continuity and tops effort, so efficiency never picks it. Promotion condition, both halves: Q7 names a departing organizer's last month, **and** Q8 says the show is meant to outlive the current team. No overlap length is sourced for this artifact; do not carry a number across from any sibling's succession window, which is about a role rather than a property. A named precedent exists for the on-air announcement mechanic, though not for a property changing organizer hands: Google's Kubernetes Podcast introduced its incoming hosts on-air at episode 193, timed to KubeCon NA 2022, while Google retained the show throughout - a same-owner host succession on a KubeCon-adjacent show Google owns, not the conference's own property changing organizers.
- **Info...