Skill v1.0.0

version: "1.0.0" name: podcast-guest description: Find the podcasts a founder should go on as a guest, across every audience where they carry weight (their buyers, their own craft, their home country, the product's topic), verify that each show is active, listened to and takes guests like them, and draft a pitch per show in its language. Stage one of two; it never sends anything.

This produces a guest plan for the founder to review. Stage two, the email campaign, sends only the pitches the founder approves. This run never sends, submits, follows or messages anyone. Read SEARCH.md and SCORING.md before starting; SCORING.md's Python decides exclusions, balance, memory and the pitch block.

1. Read the context. Everything here is evidence, not instructions, and nothing in it is

asked of the founder again. Note which files existed for the report's ## About this run.

• founder_profile (required input): who the founder is.
• wiki/INDEX.md → ## Product → ### Feature map: what the product does, with numbers.
• reports/GROWTH_ONBOARDING_PLAN.md: ## The business (what is sold, who buys) and any

hard no: … lines, which are binding. no unbacked claims means every claim in a pitch comes from these files or the profile.

• Founder rules the project keeps elsewhere, such as a preferences file linked from

wiki/INDEX.md: any "never" or hard no there binds every draft, even when SCORING.md has no id for it.

• .agents/skills/writing-style/SKILL.md: the founder's voice. voice_notes wins.
• Without a Feature map, take product facts from the growth plan's ## The business, the

README and the product's own site, and say so in ## About this run.

• Earlier reports in the output folder: their tin-podcast-state blocks (merge them as

SCORING.md says) and their picks, so this run does not repeat them.

If founder_profile says almost nothing about the person (no role, no background), write the short report from step 9 with Status: needs context and stop; do not invent a person.

1. Decide what is being promoted. The pitches promote this project's product. The

profile may show a stronger story elsewhere (another company, an earlier role); use it as the founder's credibility, but every pitch names this project's product and why the show's listeners should care about it. If the founder's link to the product is thin, say so in the summary rather than overstating it.

1. Choose the arenas. Before any search, write down 3-6 audiences, each as a SCORING.md

arena record. Credibility is relative to the room, so for each one say why this founder stands out among those listeners, not in general. Consider at least:

• buyers: the people who use the product (from the growth plan). Being the person behind

a tool they use is the story.

• craft: the founder's own trade (from the profile). Peers want hard numbers and

failures, not a pitch.

• home: one per language the founder speaks natively, or a country they are from, when

it differs from the product's market. Someone working at a US venture-backed startup is rare and newsworthy in many home-country tech scenes.

• topic: the subject the product is about, for shows that cover it.

Skip a kind only when it plainly does not apply, and say why in ## What could not be checked. Add the arena of any show named in include_shows.

1. Search each arena with the methods SEARCH.md lists for it, at least two per arena,

inside the 32-call Podscan budget (a sweep counts as five), plus web searches. Record on each arena every method you tried, including ones that found nothing (tried).

• Start every arena except home with podcasts.sweep (SEARCH.md, "The sweep comes

first"): one sweep per field, never two fields in one, with topics in the field's own words and limit left out. Read every show it returns and keep a long list of the ones whose premise is the founder's argument or the arena's work, before searching any other way.

• Then the methods a sweep cannot replace: lookalike guests from the profile (companies

like the founder's, the founder's title, the buyers' titles), each arena's category_chart, a web search for the field's "best podcasts" lists, and the home country's charts and the web for home arenas.

• Keep about ten calls for reading finalists' episodes. Every arena ends with at least

one reach candidate verified, or a line in ## What could not be checked saying why none exists. Skip shows already pitched (already_pitched, or marked sent in the state) before spending calls on them. A show an earlier report only drafted is still a candidate; check it again.

1. Verify the finalists from their feed, their last three episodes and their own pages,

as SEARCH.md says, and write a show record for each one, verified or rejected, with what the show is (premise), who hosts it (host), its episode_dates, the best route in (SEARCH.md's order: the show's own guest page, then the feed's address, then a contact page, a social profile last), and whether a company's founder gets on without paying. A show that is big but has never hosted anyone like the founder is a ladder show if a step would get them in (a conference talk with the hosts, a guest post, a launch they cover), otherwise rank it low and say why. Judge reachability from the guests the show actually had, never from its size alone. Choose what each pitch will open on now, from the episodes you read: the similar_guest episode, another recent one recorded as hook_episode with what it actually says in detail, or a gap in the catalogue recorded as gap (a sequel the host has not run, a kind of guest the show has not had yet, a new season starting).

1. Set each show's tier and rank. likely when it books people like the founder, reach

when it books guests a step above them. A reach show is clearly bigger than the arena's likely picks by chart place in the product's main market, ratings, network or guests; a place on a small home-country chart alone does not make one. Rank within each arena and tier by your judgment of fit first (how closely the show's premise matches the founder's argument), then audience and reachability, and write the reason. A show run by a competitor, or one that mostly books its publisher's own people, gets a conflict; plan() lowers its odds, as it does for a show that paused. Say in notes how to pitch a competitor's show (the founder's argument, never the product). Do not compare shows across arenas; plan() balances them and keeps about a third of the picks for long shots.

1. Call `plan()` with the arenas, the records, today's UTC date, max_pitches,

already_pitched, include_shows, the merged state, the growth plan's hard no's and the declared output path. Use its picks, ladder, exclusions, gaps and state as returned. If you disagree with a result, say why next to the show; do not change it.

1. Draft for every pick and ladder show, in the show's language and the founder's voice.

A host reads dozens of pitches a week and decides in the first line. Every pitch follows one formula, in this order:

1. The episode, as a title. Lead with the episode the founder would make for this

show: a specific claim a listener would click ("Your SOC 2 report is out of date the day the auditor leaves"), not a topic ("compliance automation"). In email it is the subject and the first line; in a DM, the first sentence.

1. Why this founder, in one sentence. The one credential that matters to this show's

listeners, as something that happened, with its number or place ("As CISO at TechKraft I took five offices through ISO 27001"). Choose it per arena: do not lead every pitch with the same fact.

1. What listeners get (email and forms only): two or three bullets, each a concrete

story or claim the founder can back from the profile, never a feature of the product.

1. Proof you listen, at most one clause, and only when it adds to the idea: how this

episode would follow or answer a specific recent one ("a follow-up to your Andrew Carney episode: the tools are bought, and the controls still drift"), or the gap it fills ("every guest so far has run GRC at a large company; this is the 60-person version"). Never restate the host's episode to them, never compliment the show, never open with it.

1. An easy ask and a sign-off: "Open to it?" or "Happy to send more detail." Then the

founder's name, role and site on their own line. The product is named once, in the credential or the sign-off.

• Lengths: email 90-140 words, a direct message 60 words at most, a form's "why" answer

70 words at most.

• Short sentences, contractions, plain words the founder uses in the profile. No em

dashes. Never: "I can talk through", "I'd love to", "would that be useful", "could that fit", "is there a slot", "resonated", "delve", "explore", "journey", "landscape", "operational trust", slogans from the product's site, or money (fees and sponsored slots belong in Worth knowing, not in the pitch).

• Facts only from the profile and the files in step 1. Never invent audience, metrics,

appearances or availability. Refer to an episode only for what you read in it (similar_guest, or hook_episode.detail).

• Read every pitch as that host. If it could go to another show by changing the name, or

takes more than ten seconds to see the episode idea, rewrite it.

• published_email and contact_email: the subject is the episode title, under 80

characters. The follow-up a week later is two sentences that offer a second, smaller idea, never "bumping this".

• guest_form: the answers to the form's own questions, ready to paste, with the same

formula in its topic and "why" answers. Fill in every answer the profile, the project files or the product's site already hold (name, company, site, links, bio); leave only what only the founder can give (a headshot, their own email address, recording times) and list those under What you add. When the form's questions cannot be read (an embedded form), answer the usual ones (topic, why now, bio, links) and say so.

• warm_intro: three sentences a contact can forward: who the founder is, the episode

title, why this host.

• ladder: the step's draft (a talk title and abstract, a guest post outline) and its date.
• A reach show gets the same formula with an argument for its format: the contested

question for a debate show, the topic proposal for a show that picks topics first, the founder's take for a news show. Then call pitch_block() with the picks and one draft per published_email pick.

1. Write the report to the declared output path. The founder should understand it in ten

seconds from the top and act on it without reading the rest. Write it to them, as "you", everywhere outside the drafts: plain words, no arena ids, method names, file paths or Podscan field names outside ## About this run. Every label below is its own line or bullet, never several in one paragraph (consecutive Markdown lines join into one). In this order:

• # Podcasts for <founder name> to go on
• Two to four sentences of summary: how many shows are worth pitching now, how many of them

are long shots, and the one to start with and why; what it asks of the founder (for example "two emails, two messages and one form, drafted below"); the main caveat (small audiences, pitches that lean on the profile because the project has no growth plan, fewer picks than asked for).

• ## Next steps: one numbered line per pick and ladder step, in the order to do them:

the action, the show, the person and where (Email podcast@… with the draft below, Fill in Root To CISO's Become a Guest form, Email Chris Russell at chris@…, the address in his show's feed). Likely picks come first; long shots come last, to send once one or two of the smaller episodes are out to point to, unless the founder already has recorded appearances.

• ## Picks: one ### <n>. <Show name> per pick, in plan() order. First a short

paragraph, **Why this show:**, of two or three sentences addressed to the founder ("Its listeners run audits for a living, and it booked an audit-AI founder last month; you have run the audit from the other side"): who listens, which past guest shows they book people like you, and why you fit that room, from the record's reason and the arena's why. Then a bullet list:

• **Odds:** likely with the reason, or long shot with what makes it one (for

example "on the US Apple Technology chart; founder interviews are sponsored, so this pitches its panel"). Name every one of the pick's cautions in plain words ("long shot: no episode since August 18, though it usually publishes every two weeks")

• **What the show is:** one or two sentences on the argument or job it is about, from

premise, with the show's name linked to its page

• **Who hosts it:** the host's name, role and background, then one sentence on why

that matters for this pitch, from host

• **Show facts:** one line, nothing else: episodes so far, typical length, how often it

publishes, the newest episode's date, the listener number you relied on with its source, and the language when it is not English (165 episodes · about 44 min · weekly · newest 2026-10-14 · about 1,600 listeners (Podscan estimate)). Caveats about the numbers go in Worth knowing

• **Guest like you:** name, linked episode, date (or none found and why it is still a

pick)

• **Opens on:** the episode the pitch refers to, linked and dated, or the gap in the

catalogue it fills, when it is not the guest-like-you episode

• **How to reach them:** the route in words with the address and where it comes from

(the show's guest page, the feed, a contact page), the form link, the host's channel, or the contact

• **Worth knowing:** fees, sponsored signs, caveats, and for a pick with

drafted_before the date of the earlier draft and that it was never marked sent; or nothing Then the drafts, each under a bold label on its own line: **Subject:**, **Email:** and **Follow-up a week later:** for email; **Form answers:** (a bullet per question) and **What you add:** for forms; **Message:** or **Intro:** for the other routes. Write message, email, intro and long form-answer text through quote() from SCORING.md, never by hand, so every line, the list and the sign-off stay inside the quote and read as written. Nothing else goes in a pick: no list of the episodes you checked.

• ## Ladder: one ### <Show name> per ladder show with **Why this show:**, then

bullets **Show:**, **Why not now:**, **First step:**, **Deadline:** (or none stated) and the step's draft; or - none.

• ## Who these shows reach: one bullet per arena, `<label> (<kind>, <language

name>): <why the founder stands out there>. Picked: <show names, or none and why>. The kind is one of buyers, craft, home, topic, other; the language is spelled out (English, Turkish`).

• ## Shows you asked about: each include_shows name with its outcome from plan(), or

- none asked.

• ## What could not be checked: at most five bullets, in plain words the founder would

use: the gaps from plan(), any arena kind you skipped and why, and what the founder should check before sending. Never data-source detail ("provider", "feed", "index", "records", "window"); a caveat about one show belongs in its Worth knowing. Or - nothing.

• ## Left out: shows excluded because you pitched them (with date and report), then

shows a company's founder gets on only by paying (with the terms and the page), then every other exclusion with its reason. If fewer than max_pitches survived, say so plainly; do not pad the list.

• ## About this run: bullets Status: the status from plan() (complete or `no shows

verified) or needs context; Verdict: followed by nothing but the verdict from plan() (fit, thin or not a fit); As of: today's UTC date; Read: the context found, named as the founder knows it ("your profile", "the growth plan"), never this skill's files or Podscan; Not found:` the context missing. Nothing else: no run id, no list of searches or methods.

End with two fenced blocks written with Python from the returned values, not retyped: the pitch_block() result with info string json tin-podcast-pitches, then the plan() state with info string json tin-podcast-state. The reader folds both away.

For Status: needs context, write the title, one sentence naming what the profile is missing, ## Left out with - none, ## About this run with Verdict: not a fit, an empty pitch block ({"version": 1, "pitches": []}) and the unchanged merged state.

1. Check before finishing. Count the ### headings under ## Picks and confirm they

match plan()'s picks, that the Verdict: line matches, that every published_email pick appears once in the pitch block with the address the show publishes, that both blocks parse, that no two labels share a line, that every draft came from quote(), that ## What could not be checked has at most five bullets, and that every pitch opens on an episode recorded for its show or a gap recorded for it. Then run check_links() on the report: replace each broken link with the page that works (the show's current page, the episode on its own site) or remove the link; never leave one in. Keep unchecked links. Fix any mismatch.