---name: tech-podcast-youtube-channeldescription: 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: MITmetadata: author: Samuel Bertheversion: 1.0.1---

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.

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

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.
• Informal handoff - whoever is around gets the login. Last on efficiency: near-zero effort buying near-zero recoverability, and it is what happens by default rather than by choice.
• Delete, do not demote - letting the feed lapse silently, with the last episode left as the most recent one and no notice. Delete it from this menu and from the axis lines above. It looks like the free version of folding into an archive and it is the opposite: without a closing note the property reads as abandoned rather than complete, which is the exact failure samber/dev-event-organizer-skills@event-portfolio-strategy names, and the release records keep a live obligation with no custodian. Closing deliberately costs one post.

Failure modes

• Stating a cadence with no named owner. It reads as a commitment in the plan and as a dead show once the misses start repeating - no count is given here, because none is sourced. Fix: Q3 names the person before Menu 1 is chosen, or the posture is archive-only or no channel by decision.
• Reusing a stage consent as an episode release. A speaker agreed to be recorded on stage under a stated format and opt-out. A conversational episode is a different publication of a different recording, and samber/dev-event-organizer-skills@event-production already refuses to publish past the consent record.
• Absorbing the technical layer. Microphone counts, room choice, signal path and editing execution belong to samber/dev-event-organizer-skills@event-production. The moment a plan starts specifying equipment, it has left this skill.
• Turning a one-edition derivative into "the channel". An audio cut of one talk is samber/dev-event-organizer-skills@event-content-repurposing's artifact. It becomes an episode only when a property with a format and a cadence exists to receive it.
• Promising the channel will fill seats. No figure in this collection supports it, and samber/dev-event-organizer-skills@event-portfolio-strategy says so itself. The clearest named illustration of the failure is a marketing agency's own case study for GOTO Conferences: it states the engagement's goal as boosting ticket sales, then reports only channel-growth numbers - millions of added views, tens of thousands of added subscribers, a subscriber growth rate far above the channel's organic average - with no ticket or registration figure attached to them. Reach grew; the seats-filled claim was never measured. Argue reach and relationship value instead, and mark the registration path aspirational.
• Letting the show become the community. Publishing at people is not a space they belong to. If the plan starts needing a member list, replies or moderation, it is samber/dev-event-organizer-skills@event-community-building's object.
• Booking only the people already booked. The pool-only default is the efficient start, not the permanent shape - a show that only ever interviews this year's speakers becomes the programme in audio and reaches nobody new. Q5's pool size is the signal to promote a rung.
• Recording faster than the team can publish. Unpublished recordings are the visible form of an over-committed cadence, and they carry a live release obligation while returning nothing.

Measurement

Every threshold here is self-set, and this skill sets no numeric threshold at all - an argued opt-out. What the record carries:

• a named illustration of what a heavily-staffed, decade-old channel can reach (see Menu 1's heavy-cadence rung)
• no sourced conversion figure tying channel activity to event registrations
• no documented case disclosing a full transfer of a conference-run channel's platform account, back-catalogue and guest-release records between organizing teams; the nearest sourced precedents are a same-owner host succession and a deliberate retirement chosen over a handover (see Menu 3)

A number invented here would still read as false precision and be wrong in most teams' first year.

Three completeness gates, checkable against documents you built:

• Release coverage - every published episode has an episode-specific release from every participant, on file with a named holder.
• Named quiet-month owner - the posture has one, and the cadence stated in public is the one that person agreed to.
• Handover readiness - the handover document exists, is dated, and names a living holder for the platform account, the feed and the release records.

Self-set measures, declared before the cycle starts rather than read back from the first year:

• Cadence kept (binary per cycle): episodes committed versus episodes published. A miss that repeats is a demotion signal on Menu 1, not a discipline problem - no threshold is set here, because none is sourced.
• Pipeline depth: guests named and agreed ahead of the next publish date. Report the count, never a rate - the denominator is meaningless at these sizes.
• Back-catalogue reachability (gate-shaped): every published episode still resolves at its own address after a platform or account change.

Pass threshold, and iterate until met: the three gates, zero exceptions. A channel plan missing any one of them is not done, whatever its reach looks like.

Invocation examples

• "We run one conference a year and the team wants to start a podcast. Should we?"
• "Our channel has published nothing for months and nobody has said anything. What now?"
• "Where do we find guests once we've interviewed all our past speakers?"
• "The organizer who hosts our show is leaving and the account is in her name."

Expected output: a channel plan delivered section by section for approval.

1. The existence posture with its named quiet-month owner and the rungs rejected.
2. The cadence commitment written as a keepable sentence.
3. The guest pipeline with its vetting owner and bar.
4. The release instrument and its holder.
5. The two-direction feed relationship with each path marked exists or aspirational.
6. The dated handover document.
7. The three gates and the self-set measures.

Every unsourced element is labelled as this skill's own construction.

References

• references/property-shapes-and-cadence.md - existence rungs, cadence commitment, feed relationship, archive closing note
• references/guest-pipeline-and-release.md - sourcing rungs, vetting bar, stage vs. episode release, asset inventory, handover checklist
• samber/dev-event-organizer-skills@event-portfolio-strategy - portfolio decision that gates whether to have a media property at all
• samber/dev-event-organizer-skills@event-content-repurposing - one-edition derivatives versus standing property boundary
• samber/dev-event-organizer-skills@event-production - upstream recording capture and consent collection
• samber/dev-event-organizer-skills@event-speaker-experience - speaker contact and stage-consent management
• samber/dev-event-organizer-skills@event-community-building - audience space and member coordination
• samber/dev-event-organizer-skills@event-code-of-conduct - conduct policy and reporting path