tech-podcast-youtube-channel

{
  "skill_name": "tech-podcast-youtube-channel",
  "evals": [
    {
      "id": 1,
      "prompt": "We run DevFest Lyonnais, about 600 people, once a year in March. Four volunteer organizers, all with day jobs. Our talk recordings already go up on our own Vimeo page within a month of each edition and the transcripts land on our blog. The team voted 3 to 1 to launch a fortnightly podcast starting in April, and two of us want the fortnightly rhythm on the website as soon as we agree on it. Nobody has said who would run it between March and next March. Write us the plan.",
      "expected_output": "A posture recommendation that declines the fortnightly show: no channel (or archive-only) recommended outright, both original-content rungs deleted rather than demoted because nobody owns the quiet months, the unagreed public rhythm refused, and the decline written down as a decision with a reopening condition.",
      "files": [],
      "expectations": [
        "Does not deliver a fortnightly episode plan or publishing calendar as the answer",
        "Recommends the no-channel posture, or archive-only, rather than an original-content channel",
        "States that no channel is a real answer and a legitimate outcome, not a failure to plan",
        "Deletes both original-content rungs from the menu rather than ranking or demoting them, on the grounds that nobody is named for the quiet months",
        "Identifies the absence of a named owner for the months between editions as the blocking fact",
        "Treats the existing Vimeo page and blog as evidence that the derivatives already have somewhere to publish",
        "Refuses to publish a fortnightly cadence that no named person has agreed to hold",
        "Names announcing a cadence nobody agreed to as a deleted option rather than a cheaper version of running a channel",
        "Invents no episode interval, publishing frequency or subscriber figure of its own",
        "States that the decline should be written down, with the condition that would reopen the question",
        "Asks whether a portfolio decision to have a recurring media property was ever made, or routes that question to samber/dev-event-organizer-skills@event-portfolio-strategy",
        "Specifies no microphones, recorders, editing software or signal-path detail",
        "Makes no claim that the show would sell tickets or fill seats"
      ]
    },
    {
      "id": 2,
      "prompt": "I host the show for Kubernetes Nord, one conference a year, around 900 people. We have four episodes recorded: three interviews with people who spoke at our last edition, and one roundtable with two of those speakers plus my co-organizer Priya and a surprise drop-in from a sponsor's staff engineer. All four speakers signed our standard recording consent when they confirmed their talks last year, which covers AV capture and publication of the talk video. Our lawyer is expensive and I would rather not go back to her. Can we publish all four this month, and what do I need on file?",
      "expected_output": "A refusal to treat the stage consent as covering the episodes, a requirement for an episode-specific release from every participant including hosts and the drop-in, the wording routed to counsel, and a named custodian with a retention decision.",
      "files": [],
      "expectations": [
        "States that the signed stage consent does not cover these episodes",
        "Requires a separate, episode-specific release for each episode",
        "Requires a release from every participant, not only the invited guests",
        "Explicitly includes the host and the co-organizer Priya among those who must sign",
        "Explicitly includes the sponsor's staff engineer who dropped into the roundtable",
        "States that releases are collected before recording, so the four already-recorded episodes cannot publish until the releases exist",
        "Refuses to publish any recording the consent record does not cover",
        "Distinguishes the two instruments by what each covers: a talk delivered to a room in a stated format with a stated opt-out, versus a conversation recorded for publication on a standing property",
        "Routes the release's actual wording to the organizer's own counsel rather than drafting enforceable terms",
        "Names no jurisdiction and quotes no retention period",
        "Names a single custodian who holds the episode release records",
        "Does not re-open the event's speaker relationship or amend the existing stage-consent instrument to cover the episodes"
      ]
    },
    {
      "id": 3,
      "prompt": "Our show for Berlin Infra Days is about 40 episodes in and we have burned through the 34 past speakers we had permission to contact. Two things on the table. Our platinum sponsor Vaultwright has offered us a guest every quarter, their VP of Engineering, no money changes hands, they just want the slot. And we are thinking of opening a public pitch-us form. Right now nobody on the team reviews anything, I book whoever replies first. What should the pipeline look like?",
      "expected_output": "A sourcing pipeline that deletes the sponsor-supplied slot and the unreviewed open pitch rather than ranking them, names a vetting owner with a checkable bar, and states the promotion conditions for the remaining rungs.",
      "files": [],
      "expectations": [
        "Deletes the sponsor-supplied guest slot from the sourcing menu rather than ranking it low or listing it as a cheap option",
        "States that a guest slot given because a sponsor asked for it converts the property into sponsor inventory",
        "Routes any sponsored episode to samber/dev-event-organizer-skills@event-sponsor-value-proposition as a sponsorship decision made there",
        "States that a sponsored episode must be disclosed as one if it happens",
        "Does not treat 'no money changes hands' as making the sponsor slot an editorial booking",
        "Deletes the open pitch from the menu while no vetting owner exists, rather than ranking it",
        "Requires a named vetting owner with a written bar before any public call opens",
        "States that a published call needs a stated bar, a named reviewer and a stated answer window",
        "States that booking whoever replies first is not a pipeline: availability is not fit and enthusiasm is not a bar",
        "Produces a vetting bar made of checkable questions rather than desirable attributes such as engaging or well-known",
        "Routes the conduct half of the bar to samber/dev-event-organizer-skills@event-code-of-conduct instead of restating a policy",
        "States the promotion conditions for cold outbound rather than recommending it unconditionally",
        "Reuses the qualification and outreach craft from samber/dev-event-organizer-skills@event-speaker-sourcing and samber/dev-event-organizer-skills@event-speaker-cold-outreach instead of rebuilding it for the show"
      ]
    },
    {
      "id": 4,
      "prompt": "Sponsorship lead for ShipIt Conf here. I need one page for the board on what our YouTube channel does for the conference. We have 12,000 subscribers, views are up 40% year over year, and I want a line in there saying the channel is our top-of-funnel for ticket sales, since we link the ticket page in every description. Our marketing agency's deck for a similar conference showed millions of added views and 30,000 new subscribers as proof their channel drove ticket sales. Write the page.",
      "expected_output": "A two-direction feed map with every path marked EXISTS or ASPIRATIONAL, the ticket-page path marked ASPIRATIONAL, the seats-filled claim refused, and the agency evidence identified as channel-growth numbers with no registration figure attached.",
      "files": [],
      "expectations": [
        "Refuses to state that the channel is top-of-funnel for ticket sales",
        "Marks the show-notes-to-ticket-page path ASPIRATIONAL rather than EXISTS",
        "States that a path counts as EXISTS only when a mechanism carries a person or a file, not because a link exists",
        "Points out that the cited agency case reports only channel-growth numbers with no ticket or registration figure attached to them",
        "Does not present the 12,000 subscribers or the 40% view growth as evidence of ticket conversion",
        "Writes the feed relationship in both directions, one line per path",
        "Marks every path in the map EXISTS or ASPIRATIONAL",
        "Includes event-to-channel paths covering finished recordings, the speaker pool to book from, and a reason to publish around an edition",
        "Includes channel-to-event paths covering a warm first contact with a prospective speaker, cross-promotion inventory a swap can use, and a surface that keeps working in the gap",
        "Argues reach and relationship value in place of a registration claim",
        "Invents no conversion rate, attribution figure or funnel percentage",
        "Does not decide here whether the channel is worth keeping in the portfolio, routing that to samber/dev-event-organizer-skills@event-portfolio-strategy"
      ]
    },
    {
      "id": 5,
      "prompt": "Maroua has hosted our show for four years and she is leaving in eleven weeks. The YouTube account and the podcast host are both under her personal Google account and her personal card. We have 61 episodes. Nobody else on the team has ever published an episode and we do not know who would take it over. What do we do in eleven weeks? I was going to add whoever volunteers as a second admin on her account and call it done.",
      "expected_output": "A documented ownership and access transfer as the default, the second-admin plan named as the exact failure the transfer prevents, the closed-archive fold presented as a live option given no successor, no invented overlap window, and a dated handover document naming the release custodian.",
      "files": [],
      "expectations": [
        "Recommends the documented ownership and access transfer as the default rung",
        "Names adding a second admin while the personal account stays owner of record as the failure the transfer exists to prevent",
        "States that the property becomes unrecoverable the day that personal account closes",
        "Requires moving every account off any individual's personal ownership, with a second named holder on each",
        "Does not recommend the named-successor-with-overlap rung as the default, since no successor exists",
        "Invents no overlap length, transfer window or notice period",
        "Does not borrow a transfer window from samber/dev-event-organizer-skills@event-team-structure or samber/dev-event-organizer-skills@event-community-building",
        "Presents folding into a closed archive as a live option, given 61 episodes and nobody named for the quiet months",
        "States what a closing note must carry if the show folds: that it ended, the date, where the back-catalogue stays reachable, who holds the account, and where the audience should go instead",
        "Names letting the feed lapse silently with no notice as a deleted option rather than a cheap version of the archive",
        "Requires the guest-release records to get a named custodian with the retention decision restated rather than assumed inherited",
        "Requires confirming that every published episode still resolves at its own address after the transfer, before the outgoing owner stops being reachable",
        "Requires the handover document to be dated and to fix a date for re-checking it on a schedule",
        "Requires recording what the show committed to publicly, so the incoming holder inherits the promise rather than discovering it"
      ]
    },
    {
      "id": 6,
      "prompt": "We recorded 14 talks at our last edition and our editor has already cut audio-only versions of all 14. Somebody on the team said that is our podcast, just push them to Spotify. I want to do this properly: what mics should we buy for the interview episodes, what is the right DAW, and should we get a second recorder for redundancy? Also we need a name.",
      "expected_output": "A refusal to specify equipment or editing tooling, the 14 cuts identified as one-edition derivatives rather than a channel, and the interview run before any posture is proposed, with archive-only as the likely default.",
      "files": [],
      "expectations": [
        "Declines to recommend specific microphones, recorders or editing software",
        "Routes signal path, microphone count, redundancy and editing execution to samber/dev-event-organizer-skills@event-production",
        "States that the 14 audio cuts are samber/dev-event-organizer-skills@event-content-repurposing's artifact, not a channel",
        "States that a derivative becomes an episode only once a property with its own format and cadence exists to receive it",
        "Runs interview questions about the posture, the quiet-month owner and the gap between editions before producing a plan",
        "Proposes the archive-only feed as the default posture, given derivatives already exist",
        "States that an archive-only feed needs a durable address, a purpose line a stranger can read, and a named holder of the account",
        "States that the archive-only feed makes no cadence promise",
        "Does not substitute a naming or branding exercise for the posture decision",
        "Promises no publishing rhythm for the interview episodes",
        "Requires checking that the existing consent record covers publication before the 14 cuts are pushed anywhere"
      ]
    },
    {
      "id": 7,
      "prompt": "Give me the one-liner we put on our site, plus our KPI sheet. The show is called Between Editions, run by our co-organizer Tomas, who has roughly three hours a week outside the two months around our conference. We want to commit publicly to something. For KPIs my co-founder wants subscriber growth targets, a listener-to-ticket conversion rate, and a rule that we drop the show if we miss three episodes in a row.",
      "expected_output": "A cadence-commitment sentence carrying what publishes, the rhythm, its named owner and the missed-cycle behaviour; the three requested KPIs declined or reshaped; the three completeness gates and the self-set measures supplied instead.",
      "files": [],
      "expectations": [
        "Writes a cadence sentence carrying all four elements: what the show publishes, on what rhythm, who owns that rhythm, and what happens when a cycle is missed",
        "Names Tomas as the owner inside the sentence",
        "Does not produce an unowned rhythm promise of the 'new episodes every other week' shape",
        "Derives any rhythm from the stated three hours a week and the two-month recovery window rather than from a generic publishing convention",
        "Deliberately under-promises, on the grounds that the argued failure is a property that stops rather than one that publishes rarely",
        "Declines the listener-to-ticket conversion rate as a measure, stating that no sourced figure ties channel activity to registrations",
        "Declines to set a subscriber growth target",
        "Declines the three-misses-in-a-row rule, stating that no numeric miss threshold is sourced",
        "Treats a repeated miss as a demotion signal on the existence-posture menu rather than as a discipline problem",
        "Reports pipeline depth as a count of guests named and agreed ahead of the next publish date, never as a rate",
        "Includes the release-coverage gate: every published episode has an episode-specific release from every participant, on file with a named holder",
        "Includes the named-quiet-month-owner gate, with the public cadence matching the one that person agreed to",
        "Includes the handover-readiness gate: a dated handover document naming a living holder for the platform account, the feed and the release records",
        "States the pass threshold as all three gates with zero exceptions"
      ]
    },
    {
      "id": 8,
      "prompt": "Two asks landed this week. A newsletter called Platform Weekly wants to swap: they will plug our show if our lead organizer guests on their podcast. And the organizers of RustFest Iberia want to trade promotion, their audience for ours, and want me to negotiate the terms. Separately, our listeners keep emailing questions and I want to spin up a Discord so they can talk to each other and to guests, moderated by whoever is around. Tell me how to handle all three.",
      "expected_output": "All three asks routed out: the barter to media partnerships, the swap negotiation to cross-event promotion, the Discord to community building, with what crosses each seam stated from this side only.",
      "files": [],
      "expectations": [
        "Does not broker or negotiate the Platform Weekly barter",
        "Routes the Platform Weekly exchange to samber/dev-event-organizer-skills@event-media-partnerships",
        "Identifies the organizer guesting on Platform Weekly's podcast as an appearance on someone else's show, distinct from this property",
        "Routes the RustFest Iberia swap negotiation to samber/dev-event-organizer-skills@cross-event-promotion",
        "States that this side supplies the episode or the date for such a swap and does not negotiate its terms",
        "Routes the Discord to samber/dev-event-organizer-skills@event-community-building",
        "States that publishing at people is not a space they belong to",
        "Names the need for a member list, replies or moderation as the signal that the object has become the community's rather than the show's",
        "Does not produce a moderation plan, membership retention duty or member-list design",
        "Rejects 'whoever is around' as a moderation arrangement rather than accepting it",
        "Keeps a new-episode notice as content that can cross into that space",
        "Keeps guests or topics surfaced in that space as input this side still sources and vets"
      ]
    },
    {
      "id": 9,
      "prompt": "We run four events a year: two meetups, a hackathon, and a two-day conference. My co-organizer Ines already hosts a weekly show of her own, and we have a part-time editor on retainer for 10 hours a month, paid out of the conference budget. Ines wants to go weekly with a conference-branded show and says it is obviously the best option because it reaches the most people. The rest of the team thinks she is wrong. Settle it.",
      "expected_output": "Brainstorming mode rather than a verdict: candidate shapes with trade-offs, the heavy-cadence promotion conditions checked one by one, the reach argument rejected because reach tracks effort exactly, and the existing assets named as the answers that moved specific rungs.",
      "files": [],
      "expectations": [
        "Enters brainstorming mode with two or three candidate shapes and their trade-offs, rather than issuing a single verdict, because the team disagrees on whether to run the channel at all",
        "Asks questions one at a time and validates each section before moving to the next",
        "States the heavy-cadence rung's promotion conditions as a set that must all hold, not as a single test",
        "Names the funded-or-committed owner condition, the in-house editor or co-organizer who already hosts a show condition, and the compounding condition",
        "Identifies the retained editor and Ines's existing weekly show as satisfying the in-house asset condition, and says which answer moved which rung",
        "Requires the one-off versus compounding answer before promoting the heavy rung",
        "Rejects 'it reaches the most people' as sufficient grounds, on the basis that reach tracks effort exactly across the menu",
        "States that efficiency never picks the heavy-cadence rung, because it tops reach, effort and compliance cost together",
        "Reports zero strict-dominance relations across the menu's pairs, so no rung dominates another",
        "States that the dominance result is vacuous by construction here and is never a pass, so the ratios must be challenged directly",
        "Names what the heavy rung is one step from becoming: a media operation with its own staffing question that no skill in this collection covers",
        "Distinguishes standing roles filled for a stated period, one each for booking, recording, editing and publishing, from per-episode improvisation",
        "States that one person holding every role is the low-cadence rung with an unsustainable rhythm attached, not the heavy rung",
        "Presents the outcome section by section, with approval sought per section"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "Should our conference start a podcast?", "should_trigger": true },
    {
      "query": "we want to launch a youtube channel for our event, where do we start",
      "should_trigger": true
    },
    {
      "query": "who should own our show in the months when there is no conference",
      "should_trigger": true
    },
    {
      "query": "our channel has published nothing since March and nobody has mentioned it",
      "should_trigger": true
    },
    {
      "query": "where do we find guests once we have interviewed all our past speakers",
      "should_trigger": true
    },
    {
      "query": "the organizer who hosts our show is leaving and the account is in her name",
      "should_trigger": true
    },
    { "query": "how often should we publish between editions", "should_trigger": true },
    {
      "query": "is it worth keeping something running for our audience between conferences that is not a chat server",
      "should_trigger": true
    },
    { "query": "we want to close down the show properly, what do we post", "should_trigger": true },
    {
      "query": "can we use last year's speaker recording consent for an episode",
      "should_trigger": true
    },
    { "query": "our sponsor wants a guest slot on our show every quarter", "should_trigger": true },
    {
      "query": "should we announce a fortnightly rhythm on the site before we have recorded anything",
      "should_trigger": true
    },
    {
      "query": "what does a handover doc for our conference's show need to say",
      "should_trigger": true
    },
    {
      "query": "we have 40 talk recordings and someone wants to turn them into a standing feed",
      "should_trigger": true
    },
    {
      "query": "do we need a separate release for everyone who appears on our episodes",
      "should_trigger": true
    },
    {
      "query": "our event and the thing we publish between editions, how do they actually feed each other",
      "should_trigger": true
    },
    { "query": "can I tell the board the channel drives ticket sales", "should_trigger": true },
    { "query": "we have run out of past speakers to interview", "should_trigger": true },
    {
      "query": "nobody agreed to run it between editions and we already announced a schedule",
      "should_trigger": true
    },
    { "query": "should we open a public call for guests", "should_trigger": true },
    {
      "query": "help me write the one-liner promising what we publish and how often",
      "should_trigger": true
    },
    { "query": "the person who has the login is quitting", "should_trigger": true },
    { "query": "what KPIs make sense for a conference-run show", "should_trigger": true },
    { "query": "we keep recording episodes faster than we publish them", "should_trigger": true },
    { "query": "our conference is annual, is a weekly show realistic", "should_trigger": true },
    {
      "query": "is starting one of these even a good idea for an all-volunteer team",
      "should_trigger": true
    },
    {
      "query": "we want something that keeps working in the gap between editions and reaches people who never come",
      "should_trigger": true
    },
    {
      "query": "how do we stop the show from just being this year's programme in audio",
      "should_trigger": true
    },
    { "query": "who vets a guest before we book them", "should_trigger": true },
    { "query": "what goes in the asset inventory for our show", "should_trigger": true },
    {
      "query": "our co-organizer wants to go weekly and the rest of us disagree",
      "should_trigger": true
    },
    { "query": "do we need to name someone for the quiet months", "should_trigger": true },
    { "query": "our archive is 60 episodes and we are stopping, what happens to it", "should_trigger": true },
    {
      "query": "we want to keep publishing between conferences but only just barely",
      "should_trigger": true
    },
    {
      "query": "how do I choose between just posting the recordings and doing real interviews",
      "should_trigger": true
    },
    { "query": "an audio cut of one talk, is that an episode", "should_trigger": true },
    {
      "query": "we are thinking of interviewing people who have nothing to do with the event",
      "should_trigger": true
    },
    { "query": "should our event's conduct policy bind the show", "should_trigger": true },
    {
      "query": "what happens to the guest release records when the organizing team changes",
      "should_trigger": true
    },
    {
      "query": "our subscribers are not the same people as our attendees, is that a problem",
      "should_trigger": true
    },
    {
      "query": "planning something recurring we publish outside the event weeks",
      "should_trigger": true
    },
    { "query": "we want a cross-edition thing with its own back catalogue", "should_trigger": true },
    { "query": "how long should the outgoing host and the new host overlap", "should_trigger": true },
    {
      "query": "we need the media side to survive the current organizers leaving",
      "should_trigger": true
    },
    {
      "query": "what should we commit to publicly about how often we publish",
      "should_trigger": true
    },
    { "query": "how many episodes should we have booked before we launch", "should_trigger": true },
    {
      "query": "our hackathon team wants to start interviewing past winners regularly",
      "should_trigger": true
    },
    { "query": "who holds the platform account for a community-run show", "should_trigger": true },
    { "query": "is it fine to just stop posting if nobody is listening", "should_trigger": true },
    {
      "query": "help me think through whether we sustain this thing or wind it down",
      "should_trigger": true
    },
    { "query": "we want to reach people the room cannot hold", "should_trigger": true },
    { "query": "cut our keynote into clips for LinkedIn", "should_trigger": false },
    {
      "query": "what formats should we make from this year's talk recordings",
      "should_trigger": false
    },
    { "query": "how many cameras and mics do we need for the main room", "should_trigger": false },
    { "query": "our AV vendor wants to know the signal path for the stage", "should_trigger": false },
    {
      "query": "set up a newsletter swap with another conference's organizers",
      "should_trigger": false
    },
    { "query": "a newsletter wants to trade visibility with us", "should_trigger": false },
    {
      "query": "our organizer is going on someone else's podcast next week, prep him",
      "should_trigger": false
    },
    { "query": "write the script for a six-minute product explainer video", "should_trigger": false },
    { "query": "we need a Discord for attendees between editions", "should_trigger": false },
    { "query": "how do we keep our meetup members warm between events", "should_trigger": false },
    { "query": "should we add a hackathon to our portfolio of events", "should_trigger": false },
    { "query": "we are deciding whether to retire our meetup series", "should_trigger": false },
    {
      "query": "plan our pre-event posting schedule on LinkedIn and Mastodon",
      "should_trigger": false
    },
    { "query": "who posts what during the conference days", "should_trigger": false },
    { "query": "collect bios and headshots from confirmed speakers", "should_trigger": false },
    { "query": "write the recording consent form for our stage talks", "should_trigger": false },
    { "query": "find speakers for our next edition outside the CFP", "should_trigger": false },
    { "query": "write the first cold email to a speaker we want on stage", "should_trigger": false },
    { "query": "design our call for papers timeline", "should_trigger": false },
    { "query": "how do we review CFP submissions blind", "should_trigger": false },
    { "query": "we need a code of conduct and a reporting path", "should_trigger": false },
    { "query": "price our sponsorship tiers for next year", "should_trigger": false },
    { "query": "what do gold sponsors actually get for their money", "should_trigger": false },
    { "query": "deliver everything we promised our signed sponsors", "should_trigger": false },
    { "query": "we are running a fully remote edition, which platform", "should_trigger": false },
    {
      "query": "design a hybrid event serving the room and the remote audience at once",
      "should_trigger": false
    },
    { "query": "structure our standing organizing team between editions", "should_trigger": false },
    { "query": "who succeeds our chair when she steps down next year", "should_trigger": false },
    {
      "query": "build the attendee email sequence from announcement to doors open",
      "should_trigger": false
    },
    { "query": "pitch tech press to cover our conference", "should_trigger": false },
    { "query": "turn three editions of debrief notes into operational trends", "should_trigger": false },
    { "query": "run the retro on the edition we just finished", "should_trigger": false },
    { "query": "design the expo floor traffic pattern past every booth", "should_trigger": false },
    { "query": "what date should our conference run on", "should_trigger": false },
    { "query": "lay the selected talks into a published session grid", "should_trigger": false },
    { "query": "write the minute-by-minute run of show for day one", "should_trigger": false },
    { "query": "set ticket prices for our first edition", "should_trigger": false },
    { "query": "build the budget and P&L for the conference", "should_trigger": false },
    { "query": "design the mentor programme for our hackathon", "should_trigger": false },
    { "query": "how do we judge hackathon projects fairly", "should_trigger": false },
    {
      "query": "optimize our video titles and descriptions to rank on YouTube",
      "should_trigger": false
    },
    { "query": "design a thumbnail that gets more clicks", "should_trigger": false },
    { "query": "pull the transcript out of this YouTube video", "should_trigger": false },
    { "query": "make a vertical short from this clip for the algorithm", "should_trigger": false },
    { "query": "edit this footage, trim the silences and add lower thirds", "should_trigger": false },
    { "query": "generate a video from this still image", "should_trigger": false },
    { "query": "write a launch video script for our new API", "should_trigger": false },
    { "query": "set up our YouTube ads campaign and pick the targeting", "should_trigger": false },
    { "query": "what is our social media strategy for the company brand", "should_trigger": false },
    {
      "query": "build a content calendar for our devtools company's channel, content pillars and short-form balance",
      "should_trigger": false
    },
    { "query": "download this podcast episode as an mp3", "should_trigger": false }
  ]
}

# Guest pipeline, the release instrument and the channel handover

Contents: each sourcing rung as a working artifact; the vetting bar; the stage-consent versus episode-release contrast; the channel asset inventory; the dated handover checklist.

Nothing in this file is legal advice: the release's actual wording, any music licensing question, the platform's terms and the retention period on stored recordings are review-triggered and route to the organizer's own counsel. No jurisdiction is named and no retention period is quoted, deliberately.

## Each sourcing rung as a working artifact

**Speaker-pool only.** A list, not a search: past and confirmed-upcoming speakers, with the date they last spoke, the topic they are known for, and a yes/no on whether the team is allowed to contact them about something other than the event. That last column is the one teams skip and the one that decides whether the rung is usable at all - permission to email someone about their talk is not permission to invite them onto a show. A named working instance: GOTO Conferences' interview series takes its own conference speakers "off the big stage" for a longer recorded conversation, sourcing guests from the same pool the conference already vetted rather than opening a search.

**Pool plus community nomination.** The same list with a second intake: names surfaced by the audience, each carrying who suggested them and why. A nomination is a candidate, never a booking - it enters the same vetting step as any other name, and the space it came from stays `samber/dev-event-organizer-skills@event-community-building`'s to run.

**Open pitch.** A published call with a stated bar, a named reviewer, and a stated answer window. Without all three it is not a pipeline; it is an inbox.

Reuse the intake discipline `samber/dev-event-organizer-skills@event-cfp-design` already has for the stage rather than inventing a second one.

**Cold outbound.** A shortlist with the reasoning attached to every name, then a first message that discloses what the show is, what the episode asks of them, and how the recording will be used. Apply the qualification craft from `samber/dev-event-organizer-skills@event-speaker-sourcing` and the outreach message craft from `samber/dev-event-organizer-skills@event-speaker-cold-outreach`, then adapt both. Those skills invite someone to a dated event with a room and an audience already committed, while a first episode of a small show offers a guest almost nothing verifiable. Make the honesty about reach stronger, not weaker.

**Negative example, all rungs.** A guest booked because they were available and enthusiastic, with no vetting step and no record of who checked what. Availability is not fit and enthusiasm is not a bar.

## The vetting bar

Write the bar before the first episode, in one short list, and have the person named in the interview apply it. Its purpose is not gatekeeping quality; it is that the show publishes under the event's name, so the event's conduct policy reaches it.

A workable bar asks four things and no more. These four are this skill's own construction, not an observed standard:

1. Does this person have something specific to say on a topic the audience recognises?
2. Is there anything in the public record the team would be answering for after publishing?
3. Has anyone on the organizing team worked with them before, and what did they say?
4. Does the guest understand the recording will be published, and how?

Route the conduct half to `samber/dev-event-organizer-skills@event-code-of-conduct` rather than restating a policy here - it owns the policy and the reporting path, and a show operating under a second, softer version of it is worse than one with none.

**Negative example.** A bar that lists desirable attributes ("engaging, well-known, technical") and nothing checkable. Nobody has ever failed that bar.

## Stage consent versus episode release

These are two instruments for two publications, and treating the first as covering the second is the failure mode this skill names first. A recording is never published past what the consent record covers.

|           | Stage consent                                                                                | Episode release                                                    |
| --------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| Owned by  | `samber/dev-event-organizer-skills@event-speaker-experience`, collected once at confirmation | this skill, collected per episode before recording                 |
| Covers    | a talk delivered to a room, in a stated format, with a stated opt-out                        | a conversation recorded for publication on a standing property     |
| Who signs | the speaker                                                                                  | every participant, including hosts and any third voice in the room |
| When      | in the acceptance ladder, before the event                                                   | before the first session of that episode, never from the schedule  |
| Held by   | the event's speaker record                                                                   | the named custodian in the handover document                       |

`samber/dev-event-organizer-skills@event-production` makes the same distinction from the technical side and states it as its own construction: consent for a conversational recording is obtained per participant, in writing, before the first session, because such a recording captures people who never agreed to be on stage.

**Negative example.** "They already signed the recording consent when they spoke last year." That instrument named a talk, a format and an opt-out for a different publication, and it does not reach an episode published months later on a different property.

## The channel asset inventory

One table, written at the same time as the first episode rather than at the first departure. Every row names a thing, its current holder, its holder after a departure, and - where the row stores anything about a person - its retention decision.

Rows worth having:

- the platform account and its recovery contact
- control of the feed itself
- every admin or editor role on the publishing surface
- the back-catalogue's stored master files and where they live
- the guest-release records
- the guest contact list
- any artwork, music or intro material and the terms it was obtained under
- the show's own name and any address it publishes at

**Negative example.** An inventory listing accounts only. The releases and the contact list are the rows that carry an obligation to people outside the team, and they are the rows that go missing first.

## The dated handover checklist

Applies to the documented-transfer rung and, unchanged, to the successor-with-overlap rung - the overlap adds time, not different steps.

1. Complete the asset inventory above and date it.
2. Move every account off any individual's personal ownership, with a second named holder on each.
3. Name the custodian of the guest-release records and write the retention decision beside them, restated rather than assumed inherited.
4. Confirm every published episode still resolves at its own address after the transfer, before the outgoing owner stops being reachable.
5. Record what the show committed to publicly, so the incoming holder inherits the promise rather than discovering it.
6. Fix a date to re-check the document on a schedule, not at the next resignation.

No overlap length or transfer window is sourced here. Do not borrow transfer windows from `samber/dev-event-organizer-skills@event-team-structure` or `samber/dev-event-organizer-skills@event-community-building`: those describe an organizing role, not a media property.

**Negative example.** Adding the successor as a second admin while the departing organizer's personal account stays the owner of record. It looks like the cheap version of the transfer and it is the failure the transfer exists to prevent - the day that account closes, the property is unrecoverable by anyone.

# Low-effort formats and the speaker-recruitment loop

Contents: where these claims come from; the format effort ladder in detail; short-clip sources; the flagship-only pattern; testing the speaker-recruitment loop.

## Where these claims come from

It is not established practice, carries no measured figure, and is not a benchmark. Present it as what some organizers report, and let the team's own record overrule it.

## The format effort ladder in detail

Cheapest first. Each rung names what it skips and what it still costs.

| Format                      | Skips                                          | Still costs                                                                                                                   |
| --------------------------- | ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| Unedited live stream        | editing, post-production, a separate recording | a host, a guest, a release covering live publication, a named publisher; nothing can be cut afterwards                        |
| Live stream reused as audio | a second recording session                     | exporting the audio and publishing it to a feed; the release must cover the audio use too                                     |
| Short clips from recordings | new recording                                  | finding the moment worth watching, then cutting, captioning and titling it                                                    |
| Produced podcast            | nothing                                        | recording, editing, show notes, feed publishing, per episode; the organizers reporting this ladder called it a very hard step |

Why the ladder matters here: Menu 1's cost is mostly the quiet-month hours. A format that skips editing turns the same hours into more episodes, so it can make a low-cadence original rung holdable where a produced format would not be.

Why it is not a menu rung: the ladder describes the cost of one episode, not how much the team promises. Mixing the two would let a cheap format hide an over-committed cadence.

## Short-clip sources

Clips need extraction work. Four sources:

- **Talk recordings** - the classic source, owned upstream by `samber/dev-event-organizer-skills@event-content-repurposing` for one edition's derivatives.
- **Invited-speaker sessions with automatic clip tools** - automatically generated clips from invited speaker sessions can drive engagement. Treat automatic clipping as a way to cut the finding cost, then review every clip by a human before publishing.
- **Behind-the-scenes of the organizing work** - setup, the team at work, decisions in progress. It needs no speaker release, but it does need consent from every identifiable person in the frame.
- **Key conference moments** - an opening, a full room, a closing. Check the badge photo opt-out owned by `samber/dev-event-organizer-skills@event-accessibility-inclusion` before using any shot with attendees.

A clip of a single edition's talk is that edition's derivative. It becomes this skill's object only when the standing channel publishes it as part of its own cadence.

## The flagship-only pattern

In practice, video channels often focus on their biggest conferences, with smaller meetups producing no channel content.

Read it as a symptom, not a strategy:

- the channel's cost is sized to the flagship's capture setup, so smaller events look too expensive to cover
- the quiet months stay empty, which is the lapse Menu 1 warns about

Two fixes, pick one by decision:

1. Cover the smaller events with the cheapest format on the ladder - an unedited stream or a phone-recorded short.
2. Declare the property archive-only and publish no cadence. A flagship-only channel is fine when nobody promised more.

## Testing the speaker-recruitment loop

The hypothesis: a well-watched channel makes prospective speakers want to come. It is a belief held by practitioners, not a measured effect.

1. Add one optional question to the call for speakers or the invitation reply: "Did our published videos play a part in your decision to speak?"
2. Record each answer against the speaker in the persistent record.
3. Report the count of yes answers, never a rate, at these sizes.
4. Move the feed-map line `channel -> speakers` from `ASPIRATIONAL` to `EXISTS` only when the team itself decides the answers support it, with its own self-set bar written down before reading them.

Never use the loop to justify a heavier Menu 1 rung on its own. It is a second reason to keep publishing, not a reason to promise more.

# Property shapes, cadence commitment and the feed relationship

Contents: the four existence rungs as artifacts; the cadence-commitment sentence; the two-direction feed map with a worked example; the closing note for a folded archive.

Do not invent an interval, duration, or audience figure in any rung: inventing one reads as precision and is wrong in most teams' first year. Derive these from your own context, not from this file.

## The four existence rungs as artifacts

Each rung is described by what someone can point at when it exists, not by how much work it sounds like.

**No channel.** The artifact is a decision written down: one line in the portfolio record saying the team considered a media property, declined it for a stated reason, and named the condition that would reopen the question. Without that line the question returns every planning cycle as if it were new.

**Archive-only feed.** One named feed with a stated purpose line ("recordings and cuts from our editions, published as they are finished"), fed by whatever the repurposing pipeline already produces. No booking calendar, no guest list, and - deliberately - no stated publishing rhythm, because the rhythm belongs to the edition cycle rather than to this feed.

What makes it a property rather than a folder: a durable address, a purpose line a stranger can read, and a named holder of the account.

**Low-cadence original channel.** Adds an episode plan: a list of intended episodes with a guest, a topic and a target publish window each, plus a named owner and a booking horizon. The plan's length is the real test - an owner who can name the next few episodes with agreed guests has a channel; an owner who can name only the next one has a queue of length one, which lapses on the first cancellation.

**Heavy-cadence original channel.** Adds standing roles rather than a longer list: someone books, someone records, someone edits, someone publishes, and the roles are filled for a stated period rather than per episode. When the same person holds every role, this is the low-cadence rung with an unsustainable rhythm attached, not the heavy rung.

A named instance at this rung: developer conference organizer Trifork runs two weekly interview series for its GOTO Conferences brand, one taking conference speakers off the stage for a longer conversation, one taking authors from that same speaker pool through the books they have written. Both are unified into a single podcast feed publishing every Friday since 2021, alongside a YouTube channel whose own description states new video released daily. The channel's own subscriber count grew from roughly 200,000 in late 2020 to more than a million, sustained across more than a decade of upload history.

Read it as evidence the rung's reach and cadence are reachable when the roles are actually staffed and funded year-round, not as a target to match with a volunteer team's spare hours.

## The cadence-commitment sentence

Write one sentence the team can be held to, publish it where listeners see it, and make it the sentence the owner agreed to rather than the one the team hopes for. Its job is to make the promise small enough to keep, because the argued failure this skill inherits from `samber/dev-event-organizer-skills@event-portfolio-strategy` is a property that stops publishing, not a property that publishes rarely.

The sentence carries four things:

- what the show publishes
- on what rhythm
- who owns that rhythm
- what happens when a cycle is missed

**Positive example.** "We publish an episode in the weeks around each edition and one in between, hosted by Ana, who blocks the recording days at the same time she blocks the venue calendar. If a cycle slips we say so in the feed rather than letting it pass quietly."

**Negative example.** "New episodes every other week!" - no owner, no rhythm the owner agreed to, no missed-cycle behaviour, and a promise the team makes to strangers before it has tested it once. This is the deleted rung on Menu 1, in the exact form it usually arrives.

## The two-direction feed map

One line per path, marked `EXISTS` or `ASPIRATIONAL`, in both directions. This map records how one property and one event cycle exchange material. It is not a portfolio decision and must not be used as one.

Worked example, for a team running one annual conference and a low-cadence show:

```
conference -> channel   EXISTS       talk recordings arrive as cuts; the back-catalogue stays alive in the gap
conference -> channel   EXISTS       confirmed speakers are the booking pool for the next episodes
channel    -> conference EXISTS      a past guest is a warm first contact for the next call for speakers
channel    -> conference ASPIRATIONAL show notes link to the ticket page; nobody has measured whether anyone follows it
channel    -> swap       EXISTS      episodes are the inventory another organizer's swap can trade against
channel    -> speakers   ASPIRATIONAL a well-watched channel makes prospective speakers want to come; practitioner hypothesis, untested here
```

The last line is the speaker-recruitment loop. It stays `ASPIRATIONAL` until the team's own speaker answers support it; the test is in [low-effort-formats-and-speaker-loop.md](low-effort-formats-and-speaker-loop.md).

The fourth line is the one that matters most, and it stays `ASPIRATIONAL` permanently unless the team measures it themselves: `samber/dev-event-organizer-skills@event-portfolio-strategy` states in its own words that whether a media property converts listeners into attendees is unmeasured, and that no figure in its record supports a conversion claim. Marking it `EXISTS` because a link exists is the failure.

**Negative example.** A map with every line marked `EXISTS` and none of them describing a mechanism - "the podcast promotes the conference, the conference promotes the podcast". Two properties sharing a logo look identical to two properties feeding each other until someone writes down what actually carries a person or a file from one to the other.

## The closing note for a folded archive

Written once, published in the feed and on the channel's own page, then left there. Its job is to make a stopped property read as finished rather than abandoned, which is the whole difference between the fold rung and the deleted silent-lapse rung.

It carries:

- that the show has ended
- the date it ended
- that the back-catalogue stays reachable and where
- who holds the account now
- where the audience should go instead, normally the standing member space `samber/dev-event-organizer-skills@event-community-building` runs, since that is the surface still answering

**Positive example.** "This show has ended as of this date. Every episode stays online at this address and the feed stays live for existing subscribers. The account is now held by the organizing team rather than any individual. For what happens between editions, the community space is where we are."

**Negative example.** Nothing at all, with the last episode left sitting as the most recent one. A stranger arriving through search cannot tell a finished show from a dead one, and the release records keep a live obligation nobody has been assigned.

---
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.
- **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.
- **Publishing only around the flagship edition.** Organizers report that their channels get posts mostly around their biggest conferences. The channel then reads as a conference archive with long silences, not a property. Fix: pick the cheapest format on the effort ladder for the quiet months, or choose archive-only by decision.
- **Starting with the hardest format.** A produced podcast as the first format spends the quiet-month hours on editing before the team knows whether it can hold any cadence. Fix: start at the unedited-stream rung of the effort ladder and climb only once a cadence has held.
- **Claiming the channel recruits speakers.** The speaker-recruitment loop is a practitioner hypothesis. Mark it aspirational until the team's own speaker answers support it.

## 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.
- **Speaker-loop answers** (self-set): speakers who said the published videos played a part in their decision, over speakers asked. Report the count. It is the only evidence that can move the speaker-recruitment path from aspirational to exists.
- **Quiet-month publishing** (self-set, binary per gap): at least one item published between editions. A gap with nothing in it is the flagship-only pattern.

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](references/property-shapes-and-cadence.md) - existence rungs, cadence commitment, feed relationship, archive closing note
- [references/guest-pipeline-and-release.md](references/guest-pipeline-and-release.md) - sourcing rungs, vetting bar, stage vs. episode release, asset inventory, handover checklist
- [references/low-effort-formats-and-speaker-loop.md](references/low-effort-formats-and-speaker-loop.md) - format effort ladder, short-clip sources, flagship-only pattern, speaker-recruitment loop test
- 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