samber/developer-relations-skillsチェック済み
SKILL DETAIL
tech-press-relations
samber/developer-relations-skills/tech-press-relations
Runs press and light analyst relations for a developer-facing product - news qualification, the angle, a reporter-to-beat media map, the pitch, embargo and exclusive handling, the press page and briefing pack, and what coverage is honestly worth. Use whenever someone raises tech press relations, getting press coverage, pitching a journalist, a tech media pitch, building a media list, a press kit, an embargo briefing, announcing a funding round, a launch coverage plan, an analyst briefing, or "how do we get written about" - even if they only say they want to be in the news. Nothing to do with pull requests. Not the announcement post itself - use samber/developer-relations-skills@engineering-blog-post.
インストール · 419出典を見る
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill tech-press-relations
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "tech-press-relations",
"evals": [
{
"id": 1,
"prompt": "I'm head of marketing at Kelpwood, we sell a managed Postgres branching service. We close a $12M Series A on October 14 and the board wants a press plan from me. Our success metric is 2,000 new signups from the coverage - I already put that number in the deck. We have the round size, the lead investor, and a nice stat that we went from 40 to 900 teams in a year. Give me the plan and tell me which outlets will hit that signup number.",
"expected_output": "A dated press plan that refuses the signup promise, reframes coverage value on credibility and discoverability, replaces the success metric with baseline-anchored signals, and treats the round as the occasion rather than the story.",
"files": [],
"expectations": [
"States plainly that press does not reliably convert developers, and declines to promise or forecast the 2,000-signup figure",
"Cites the developer tool-selection finding (Larios Vargas et al., ESEC/FSE 2020, 115 survey respondents) that maturity, usability and documentation outweigh visibility signals",
"Reframes what coverage buys as credibility with non-developers - buyers, executives, candidates, investors, analysts, other reporters - plus durable discoverability and citation surface",
"Proposes replacement success measures drawn from the coverage-worth signals rather than signups, naming sales or procurement conversations citing the article as the strongest",
"Requires a pre-announcement baseline - branded search, direct traffic, referring domains, repository and docs traffic, signups - captured before October 14",
"Treats the round as the occasion and builds the hook around what the money makes possible or the category thesis the investors are betting on",
"Names the funding trap: the amount alone is a form, not news, unless the size or the backer is unusual",
"Confirms investor-communication and any disclosure obligation set the date before an exclusive is offered",
"Lists the funding-specific pack items: round size, lead, participating investors, prior total, and what changes operationally",
"Runs the five qualification tests - newness, consequence, evidence, conflict or shift, tellability - before drafting anything",
"Works the schedule backwards from October 14, deciding exclusive-versus-embargo about two weeks out and opening the embargo about a week out"
]
},
{
"id": 2,
"prompt": "Sablefish is a CLI for diffing API schemas. We haven't shipped anything notable in five months because the roadmap slipped. Our CEO wants a story in the tech press this quarter regardless. We do have six months of anonymised data from 3,400 teams on how often breaking API changes ship without a version bump, but nobody has looked at it yet. Write us a press release we can send out.",
"expected_output": "A no-pitch verdict with the qualification tests shown, no manufactured announcement, and the dataset recommended as the proprietary-data route with its methodology requirements.",
"files": [],
"expectations": [
"Declines to write a press release and states there is no news to announce",
"Runs the five qualification tests against the current situation and reports at least two failures",
"Does not invent or manufacture an announcement event to hang coverage on",
"Offers the no-news alternatives: proprietary data, a defensible position, being a source, or publishing the primary artefact",
"Recommends the 3,400-team dataset as the proprietary-data route and treats it as the actual story",
"Requires the methodology to be published alongside any number drawn from that dataset",
"Frames the data as an industry benchmark rather than a product claim",
"Warns that a vendor-run comparison against named competitors gets challenged within hours unless the harness is public and reproducible",
"Names the consent and anonymisation review the dataset needs before publication",
"States that recommending no pitch is a legitimate outcome of the work rather than a failure",
"Notes that a benchmark republished on a schedule becomes a citable recurring event"
]
},
{
"id": 3,
"prompt": "We're Marlstone, a build-cache startup. Our 2.0 ships in 18 days and the date is fixed because it's tied to a partner's conference. I have exactly one afternoon of engineering time. Legal has said no new data collection or publication this quarter. None of our customers will go on record, they're all under NDA. My co-founder wants to publish a benchmark against the two incumbents because that's what everyone remembers. Which angle do we pitch?",
"expected_output": "Two or three candidate angles with trade-offs and a recommendation, the ruled-out angles deleted and named, the efficiency order stated, and a decision gate before any drafting.",
"files": [],
"expectations": [
"Presents two or three candidate angles for the same facts rather than drafting against the co-founder's first idea",
"Gives each candidate angle its trade-off plus a recommendation, then waits for a decision before writing anything",
"Deletes the number angle outright rather than ranking it low, citing the ban on new data work and publication",
"Deletes the practitioner angle because nobody is clearable to speak on record",
"Deletes the underdog angle because no public rerunnable comparison exists",
"Says explicitly which angles it deleted and why, rather than silently omitting them",
"States that a fixed near date deletes the number and the underdog and promotes the shift and the practitioner",
"States the efficiency ordering of the angle shapes out loud: the shift, then the practitioner, then the broken system, then the number, then the underdog",
"Warns that a benchmark naming the two incumbents is a comparative claim that invites a challenge which cannot be unpublished",
"Applies the pressure test: if the product did not exist, would the reporter still want to write this",
"If a broken-system angle is offered, names the enemy as a practice or norm and refuses to aim it at a named competitor"
]
},
{
"id": 4,
"prompt": "Hollowbrook runs a package registry mirror. We're not tied to any launch date and we don't need a placement next week. What I want is to become the name people cite when they talk about supply-chain risk, for years. We already store every dependency-resolution event our customers make; it's a by-product of running the product and legal has cleared aggregate publication. Our founder has never written publicly about anything. What should we do?",
"expected_output": "The number angle promoted above the default efficiency order with the promoting conditions named, its compliance cost and real effort stated, and the durable-asset measurement signals included.",
"files": [],
"expectations": [
"Promotes the number or benchmark angle above the default efficiency order and says why",
"Names both promoting conditions: data that already exists as a by-product of running the product, and a mandate for a compounding asset rather than a placement",
"States that the default efficiency order starves the number, so this is a deliberate override rather than the normal ranking",
"Does not recommend the broken-system angle on the strength of the founder's voice, since the founder is not an established public voice",
"Identifies the number as the angle producing the most durable asset - still cited later and surfacing in AI answers about the category",
"Requires methodology, hardware, software versions, the dataset or its anonymised form, and a harness a stranger can rerun",
"Requires a stated limitations section shipped with the data",
"Recommends republishing the benchmark on a schedule so it becomes a recurring citable event",
"Names the compliance cost of the number: a consent and anonymisation review before publication",
"States the effort honestly at a week-to-a-quarter scale rather than an afternoon",
"Includes the article surfacing in AI assistants' answers as a signal, spot-checked by asking the question"
]
},
{
"id": 5,
"prompt": "We bought a media database seat and exported 2,400 tech journalist contacts. I also scraped the bylines off a 'top 50 devtools writers' listicle from 2024. Plan is to BCC the whole thing with our launch announcement on Tuesday. Where the database has no email I was going to use [email protected] since that's the pattern everywhere. Anything I should change? Company is Quillrock, a feature-flag service.",
"expected_output": "The blast replaced with a built-and-verified media map of 20-40 humans, guessed addresses refused, the scoring rubric and three tiers applied, and a do-not-pitch list included.",
"files": [],
"expectations": [
"Rejects the BCC blast and replaces it with one pitch per reporter, written for that reporter",
"Caps the list at roughly 20-40 verified humans rather than 2,400 contacts",
"Rejects the purchased database and the recycled listicle as the source of the list",
"Forbids guessing an email address from a pattern, and states an unconfirmed contact is a blank field rather than a hypothesis",
"Requires reading each candidate's last five bylines, and treats the bylines rather than the bio as the truth about the beat",
"Requires confirming each reporter's current employer on the outlet's own site",
"Requires recording stated pitch preferences, including any refusal of pitches or embargoes",
"Applies the scoring rubric with beat match weighted heaviest, then audience fit and responsiveness, then recency",
"Produces three tiers: tier 1 bespoke and eligible for an exclusive or embargo, tier 2 adapted and sent after tier 1 answers, tier 3 not pitched",
"Includes a do-not-pitch list in the artefact",
"Refuses to invent a reporter, outlet or address, and hands back a verification checklist if it cannot do the checks itself"
]
},
{
"id": 6,
"prompt": "Help me tier these four for our storage-engine launch at Fennwick. (a) J. Okonjo, BigTechDaily, 4.1M monthly readers, writes mostly consumer hardware, 1 of the last 5 pieces touched developer tooling back in March. (b) R. Lindqvist, writes a newsletter with 3,800 subscribers, all platform and infra engineers, 4 of the last 5 issues on storage engines, answers every reader email. (c) P. Nakamura, EnterpriseITWeekly, covers procurement and vendor moves, 2 of the last 5 on database vendors, rarely replies to anyone. (d) S. Abara, left DevInfraToday in January according to their author page, was our best contact there. Who's tier 1? I assume (a), that's the reach.",
"expected_output": "Scores computed on the weighted rubric, the newsletter writer in tier 1, the 4.1M-reader generalist demoted, the departed reporter moved to do-not-pitch, and the reach assumption rejected.",
"files": [],
"expectations": [
"Scores each candidate on beat match, audience fit, responsiveness and recency rather than on reach",
"Applies the stated weights: beat match 3x, audience fit 2x, responsiveness 2x, recency 1x",
"Places R. Lindqvist, the 3,800-subscriber newsletter writer, in tier 1 despite the small audience",
"Places J. Okonjo below tier 1 and rejects the user's reach-based assumption explicitly",
"States that audience fit outranks raw reach for this goal",
"Moves S. Abara to the do-not-pitch list with the reason that they left the outlet in January",
"Does not treat the prior relationship with S. Abara as a reason to pitch them at the old outlet",
"Assigns P. Nakamura a tier consistent with the computed score rather than with the outlet's prestige",
"Reports the tier cut-offs used: 30 and above for tier 1, 18 to 29 for tier 2, below 18 for tier 3",
"Labels the weights and cut-offs as a working baseline rather than an industry standard",
"Notes the map is as valuable for the sends it prevents as for the ones it produces"
]
},
{
"id": 7,
"prompt": "Ashgrove 4.0 goes public Thursday at 14:00. Six reporters have agreed to hold it. Our release process is: CI publishes the npm package when we push the tag, the docs site auto-deploys from main, the changelog PR is already open on the public repo, and the new pricing page is merged behind a flag in the marketing repo. One of the six is someone I've never worked with, they emailed us last week. Also I told everyone 'Thursday morning' since we're spread across timezones. Sanity-check the plan.",
"expected_output": "The open-source leak check run against every listed vector, the first-time contact removed from the embargo, a day-clock-timezone lift time required, and the lift-day sequence stated.",
"files": [],
"expectations": [
"Runs the open-source leak check before the lift time is committed",
"Flags the tag-triggered npm publish as an embargo-breaking vector and requires holding the publish until lift",
"Flags the auto-deploying docs site as a leak vector",
"Flags the open changelog pull request as a leak vector",
"Flags the pricing page as a leak vector",
"Rejects 'Thursday morning' and requires a stated day, clock time and timezone",
"Removes the first-time contact from the embargo and gives them the news at lift time instead",
"Recommends a tarball or private preview rather than early repository access",
"Requires deciding explicitly who internally knows the date",
"States that if anyone breaks the embargo it lifts for everyone immediately, so honest outlets are not punished",
"Requires the owned post and press page live at lift time with community channels hit in the same minute"
]
},
{
"id": 8,
"prompt": "Two writers both want first look at our acquisition news. Honestly I'd rather promise both of them the exclusive and see who commits, they'll never know. I also want both drafts sent to me before they publish so I can fix the framing, and if one of them writes that our OSS project is 'effectively dead' I want that removed. We're Pinebark, acquired by a larger infra vendor, deal closes on the 21st.",
"expected_output": "Both the double exclusive and the copy-approval request refused, a factual check offered instead, the exclusive tracked, and the acquisition hook and trap applied.",
"files": [],
"expectations": [
"Refuses to promise the same exclusive twice and states that it is always discovered",
"Recommends offering the exclusive to one outlet at a time, with a deadline for their answer",
"Refuses to request copy approval",
"Offers a factual check of specific named technical claims as the substitute for copy approval",
"Lets unflattering-but-accurate framing stand, and limits corrections to factual errors made politely and specifically",
"Records the exclusive in the media map or pitch tracker so it cannot be double-promised",
"Names the acquisition hook: what happens to the open-source project, the pricing, the API and the team",
"Names the acquisition trap: silence on the parts users fear turns the unanswered question into the headline",
"Requires commitments with dates, who stays, what the licence and roadmap do, and the migration path for anything sunsetting",
"Notes that reporters at major tech outlets single out botched exclusives and embargoes as what they resent most",
"Warns that spending relationship capital this way costs the next campaign"
]
},
{
"id": 9,
"prompt": "We're moving Thistledown from Apache 2.0 to a source-available licence on November 3. Legal wants the announcement to describe it as 'a clarification of our licensing to better serve the community' and to avoid the word relicensing entirely. The project has about 9,000 GitHub stars and four vendors reselling a hosted version of it. Draft the press approach. And if it goes badly we'll just quietly revert, so no need to plan for that part.",
"expected_output": "The euphemism rejected, honest economics and retained rights stated, hostile coverage planned for against the documented precedent, and a reversal condition fixed in advance.",
"files": [],
"expectations": [
"Rejects the word 'clarification' and warns that the euphemism becomes the story",
"States the economics honestly in numbers, including the four reselling vendors as the trigger",
"States exactly what existing users keep, including the status of already-released versions",
"Plans for hostile coverage as the base case rather than the worst case",
"Cites the Terraform move to the Business Source License in August 2023, the OpenTF manifesto endorsed by more than 140 companies and over 700 individuals, and the Linux Foundation's OpenTofu fork launched on 20 September 2023",
"Requires a reversal condition decided in advance, rejecting the plan to quietly revert if it goes badly",
"Prepares a hostile-question brief for the spokesperson covering community trust and fork risk",
"Requires the old and new licences, the conversion or grant terms, and a fork-and-vendor FAQ in the pack",
"Expects fork announcements and plans for them",
"Routes the underlying licence decision to samber/developer-relations-skills@oss-license-strategy",
"Requires the spokesperson to argue the case on record rather than declining comment"
]
},
{
"id": 10,
"prompt": "We have a CVE in Ravenscar's auth middleware, CVSS 8.1, patch is ready. Our Series A announcement is on the 9th and I really don't want the CVE story stepping on it. Can we sit on disclosure until the 16th? Also the researcher who found it wants credit, but they were pretty rude in the issue thread, so I'd rather not name them. Draft the announcement - I was thinking 'a potential issue was identified in certain configurations'.",
"expected_output": "The delay refused on coordinated-disclosure grounds, the minimising phrasing rewritten, the reporter credited, and the advisory contents and prerequisite stated.",
"files": [],
"expectations": [
"Refuses to delay disclosure in order to protect the funding announcement",
"States that the coordinated-disclosure timeline governs and press planning fits around it, never the reverse",
"Rejects 'a potential issue was identified in certain configurations' as minimising and passive",
"Requires naming who did what, without passive voice hiding it",
"Requires crediting the researcher who reported the vulnerability regardless of their tone in the thread",
"Requires advisory, affected versions, patched versions, workarounds and detection guidance in the pack",
"Requires the timeline, blast radius, fix, and what changed in the process so it does not recur",
"States that this announcement class is judged on candour and speed alone",
"Requires shipping the fix and the advisory together",
"Names the prerequisite that a monitored private security contact must have been published beforehand",
"Keeps the funding announcement separate rather than bundling the two stories"
]
},
{
"id": 11,
"prompt": "Draft the email. Reporter is Dana Whitlock at a dev infra publication; her piece three weeks ago argued that build caches are a false economy for teams under 50 engineers. Our product Fernloom is a distributed build cache. Work from our boilerplate: 'Fernloom, the world-class next-generation build acceleration platform, is excited to announce a revolutionary, seamless approach that is a true paradigm shift for modern engineering teams.' We measured p95 build time going from 11m40s to 2m05s across 62 repos on our own CI, 16-core runners, v4.2. Attach our 9-page press release PDF. Make it comprehensive, maybe 500 words so she has everything.",
"expected_output": "A pitch under ~150 words with a ~50-character headline-predicting subject line, none of the banned terms, the claim shipped with its methodology, no PDF, one explicit ask, and the follow-up ladder.",
"files": [],
"expectations": [
"Produces a pitch body under roughly 150 words rather than the requested 500",
"Produces a subject line of roughly 50 characters that lets the reporter predict the headline",
"Leads the subject line with the specific number, name or decision, prefixed honestly where a prefix applies",
"Opens with one line about Dana's actual recent piece arguing build caches are a false economy",
"Contains none of the banned terms: revolutionary, disruptive, game-changing, paradigm shift, seamless, robust, world-class, best-in-class, next-generation, cutting-edge, or 'excited to announce'",
"Refuses to attach the press release PDF and puts nothing load-bearing in an attachment",
"Ships the 11m40s-to-2m05s claim with its methodology: 62 repos, own CI, 16-core runners, version 4.2",
"States the story in one sentence and states why her readers care from the readership's side",
"Ends with exactly one explicit ask - interview, embargo, exclusive, quote, or just flagging it",
"Recommends running the pitch through a humanizer pass before sending",
"Sets the follow-up ladder at day 3 with new information, day 7 with a fresh hook, then stop, and rejects 'bumping this'"
]
},
{
"id": 12,
"prompt": "Launch-day runbook for Greyhollow, an open-source secrets manager, next Tuesday. My plan: at 9:00 our CEO posts the repo to Hacker News himself and writes the first comment explaining the architecture, we ask the team's 30 people to upvote it in the first hour, and I paste our press release into the project's Discord and two subreddits. Coverage embargo lifts at 9:00 too. I'll check threads 'as needed' through the day. If someone starts claiming there's a vulnerability in our KMS integration we'll just argue it down in the thread with the facts.",
"expected_output": "The self-submission, first comment and upvote solicitation all refused, the community post rewritten as a participant's, staffing given DRIs and a stated cadence, and any vulnerability claim moved to a private channel.",
"files": [],
"expectations": [
"Forbids the company submitting its own content to a community aggregator",
"Forbids making the first comment on the thread",
"Forbids soliciting upvotes from the team",
"Replaces the pasted press release with a post made by a participant, in that community's own register",
"Assigns one directly responsible individual per channel to monitor and respond",
"Replaces 'as needed' with a stated review cadence",
"Requires handled items to be marked off in a shared channel",
"Provides for activating named experts by mention when a question exceeds the responder",
"Applies 'conveying without convincing' - the audience is the silent majority reading the thread, not the antagonist in it",
"Warns that the comment-edit window is short, recording the two-hour limit on Hacker News, so a wrong number posted in haste is close to permanent",
"Moves any vulnerability claim out of the public thread to the private security contact and a private advisory instead of debating severity or exploit detail in the open",
"Requires the owned post and press page live at lift time, with coverage pointing to the owned post rather than the reverse"
]
},
{
"id": 13,
"prompt": "Our enterprise deals keep stalling because procurement says they've never heard of Duskwater. Our head of sales wants us to brief two of the big research firms so we get into their next comparison report before Q4 renewals. We sell an API gateway; the buyer is a platform director who signs, the engineers only evaluate. Budget is fine. Set the briefings up and tell me how to guarantee we make the report.",
"expected_output": "A plain statement that a briefing cannot buy evaluation placement, the briefing-versus-inquiry distinction, a firm-family match to the enterprise motion, and a four-step briefing agenda.",
"files": [],
"expectations": [
"States plainly that a briefing cannot buy inclusion or position in any paid evaluation",
"Warns that anyone implying otherwise is selling something else",
"Distinguishes a briefing - vendor-initiated, usually open to non-clients, no advice back, no promise of coverage - from an inquiry, which is a client asking the analyst a question",
"Requires checking each firm's current published policy before scheduling, because terms differ and change",
"Splits the firm families into practitioner-focused analysts and buyer-side research firms and matches them to the enterprise, top-down buying motion described",
"Gives the briefing agenda: a short pre-read, bringing the engineer who made the decisions, most of the time on the problem and the adoption evidence rather than the demo, and asking what they are seeing in the category",
"Names the analyst's category view as the value the user takes home from the briefing",
"Keeps analyst relations scoped to a handful of briefings a year rather than a standing programme",
"States that named customers, deployment scale, compliance posture and analyst framing carry an enterprise story",
"Requires every claim to be one the company will repeat in a procurement conversation",
"Frames the outcome as a correct mental model inside buyer conversations rather than coverage"
]
},
{
"id": 14,
"prompt": "Three articles ran about Coldreach last month. Our CMO wants a slide with the advertising value equivalency of that coverage - she says the going rate is about $40k per placement at that outlet tier. She also wants me to benchmark our pitch performance: we sent 11 pitches and got 2 replies, so is 18% good or bad against the industry average reply rate? And can you find the industry standard for how many pitches per announcement we should be sending?",
"expected_output": "AVE refused with the Barcelona Principles cited, uncited reply-rate and pitch-volume statistics declined, the company compared against its own baseline, and the sample called too small.",
"files": [],
"expectations": [
"Refuses to produce an advertising value equivalency figure",
"Cites AMEC's Barcelona Principles, agreed in 2010 by practitioners from 33 countries and revised in 2015 and 2020, and the position that AVEs are not the value of public relations",
"Declines to quote an industry-average reply rate or an industry-standard pitch volume",
"Explains that reply-rate and pitch-volume figures circulate widely in PR content on uncited attributions",
"Compares the company against its own baseline instead of an invented industry average",
"States that 11 pitches is too small a sample to read a pattern from, and gives roughly thirty pitches as the working minimum",
"Labels the thirty-pitch figure as a self-set working baseline rather than a researched or industry figure",
"Ranks the coverage-worth signals, with sales or procurement conversations citing the article strongest, and reach or impressions counted as audience size rather than effect",
"Treats referral clicks from the article as a floor rather than a total",
"Warns that branded search and direct traffic comparisons are useless if another launch overlaps the window",
"Tracks the machine as well: pitches sent, reply rate, briefings booked, coverage per announcement, and time from news to first placement"
]
},
{
"id": 15,
"prompt": "Building the newsroom page for Wrackline, observability for edge workers. Marketing wants every asset behind a form so we capture leads, a contact form instead of an email address, the logo pack shipped as a .psd bundle, and our three customer logos with no other detail. Separately, two publications have offered us 'sponsored editorial' at $6k each with a small 'partner content' label. Should we take those, and can you write those pieces too?",
"expected_output": "The paid placements refused and named as advertising under PESO, the gate and contact form removed, the asset formats corrected, and the technical proof pack added with a live-before-pitching requirement.",
"files": [],
"expectations": [
"Refuses to help with the paid sponsored-editorial placements and names them as advertising, with different rules and different disclosure",
"Names the PESO model (Gini Dietrich, Spin Sucks, 2014) and places Paid outside this scope while Earned and the Owned surfaces serving it are inside",
"Removes the lead-capture gate from the press assets",
"Replaces the contact form with a named press contact, a real email address and a stated response time",
"States that a response time should be published only if it will be honoured, and that an unmonitored press address is worse than none",
"Rejects the .psd bundle and specifies SVG and PNG, light and dark, with usage rules and the correct capitalisation of the product name",
"Requires copy-paste descriptions at three lengths",
"Requires founding facts, bios and high-resolution headshots downloadable without a form",
"Requires a coverage list, most recent first, and warns that a page whose latest entry is years old reads as a dead company",
"Adds the technical proof pack, including a running artefact available now rather than on request",
"Requires a comparison table that includes the rows where the product loses, plus known limitations and an unambiguous licence and pricing statement",
"Requires the press page to be live before the first pitch goes out"
]
}
],
"trigger_queries": [
{ "query": "We need a press relations plan for our Series B announcement next month.", "should_trigger": true },
{ "query": "How do we get tech press coverage for our developer tool?", "should_trigger": true },
{ "query": "Build me a media map of reporters who cover infrastructure tooling.", "should_trigger": true },
{ "query": "Draft a pitch to a reporter at a developer trade publication.", "should_trigger": true },
{ "query": "Should we offer an exclusive or run an embargo for our 2.0 release?", "should_trigger": true },
{ "query": "Set up our press page.", "should_trigger": true },
{ "query": "What should go in a briefing pack for journalists?", "should_trigger": true },
{ "query": "We want to brief industry analysts about our category - where do we start?", "should_trigger": true },
{ "query": "Plan the announcement day for our funding round, press side.", "should_trigger": true },
{ "query": "Which journalists should we pitch our benchmark results to?", "should_trigger": true },
{ "query": "How long before launch should we brief reporters under embargo?", "should_trigger": true },
{ "query": "Write the embargo email for our September 9 announcement.", "should_trigger": true },
{ "query": "We're relicensing and expect hostile coverage - how do we handle the press?", "should_trigger": true },
{ "query": "How do we measure whether our press coverage was worth anything?", "should_trigger": true },
{ "query": "Our CFO wants the advertising value of the coverage we got last quarter.", "should_trigger": true },
{ "query": "how do we get written about", "should_trigger": true },
{ "query": "we want to be in the news", "should_trigger": true },
{ "query": "nobody has ever covered us, how do we change that", "should_trigger": true },
{ "query": "can you help me email a journalist", "should_trigger": true },
{ "query": "how do i pitch a tech publication without sounding like a bot", "should_trigger": true },
{ "query": "got a reporter asking for a quote, what do i say", "should_trigger": true },
{ "query": "we have nothing to announce but the CEO wants headlines", "should_trigger": true },
{ "query": "how do i find the right journalist for this", "should_trigger": true },
{ "query": "is it worth paying for coverage", "should_trigger": true },
{ "query": "someone broke our embargo, what now", "should_trigger": true },
{ "query": "reporter wants to see the article before publishing, is that normal", "should_trigger": true },
{ "query": "what do i put in the subject line so a journalist actually opens it", "should_trigger": true },
{ "query": "how many times can i follow up with a journalist", "should_trigger": true },
{ "query": "we got our first bit of press, what do we do with it", "should_trigger": true },
{ "query": "our announcement leaked because someone pushed the tag early", "should_trigger": true },
{ "query": "The launch is in three weeks and I need people outside our own community to hear about it.", "should_trigger": true },
{ "query": "Our investors want the round to land in a publication they actually read.", "should_trigger": true },
{ "query": "We need engineering leaders at enterprises to have heard of us before the sales call.", "should_trigger": true },
{ "query": "Candidates keep asking whether we're a real company - how do we fix that perception?", "should_trigger": true },
{ "query": "How do I get an outside writer to explain our architecture to people who never read our blog?", "should_trigger": true },
{ "query": "I want our benchmark numbers to be the ones everyone cites in this category.", "should_trigger": true },
{ "query": "Who do I send this to so it gets written up somewhere credible?", "should_trigger": true },
{ "query": "We need third-party validation before a procurement conversation.", "should_trigger": true },
{ "query": "Everyone in our category got written up last quarter except us.", "should_trigger": true },
{ "query": "We want our story told by someone who doesn't work here.", "should_trigger": true },
{ "query": "How do we make sure people outside our repo hear about this release?", "should_trigger": true },
{ "query": "I keep sending our news to writers and never hear back.", "should_trigger": true },
{ "query": "There's a big story running about our category right now and I want to be part of it.", "should_trigger": true },
{ "query": "We're donating the project to a foundation and want it to land properly with the outside world.", "should_trigger": true },
{ "query": "Can you tell me whether this is actually a story or whether I'm fooling myself?", "should_trigger": true },
{ "query": "Two outlets both think they have first look at our announcement.", "should_trigger": true },
{ "query": "What do I put on our /newsroom page?", "should_trigger": true },
{ "query": "We got acquired and users are panicking - what do we tell the outside world?", "should_trigger": true },
{ "query": "The hardest question a journalist could ask our founder - help us prepare the answer.", "should_trigger": true },
{ "query": "How do I know whether a writer still covers this beat?", "should_trigger": true },
{ "query": "Draft a media strategy for our GA launch.", "should_trigger": true },
{ "query": "We're going from beta to general availability - plan the outreach to trade publications.", "should_trigger": true },
{ "query": "Help me build a tiered list of writers for our announcement.", "should_trigger": true },
{ "query": "How should we sequence the exclusive, the embargo and our own blog post?", "should_trigger": true },
{ "query": "Should we send a press release PDF or something else?", "should_trigger": true },
{ "query": "What's the right way to handle a factual error in an article about us?", "should_trigger": true },
{ "query": "Our CVE goes public next week - what's the press plan?", "should_trigger": true },
{ "query": "We have telemetry nobody else has. How do we turn it into coverage?", "should_trigger": true },
{ "query": "What's the difference between an analyst briefing and an inquiry?", "should_trigger": true },
{ "query": "Can a briefing get us into one of the big evaluation reports?", "should_trigger": true },
{ "query": "Plan the second wave of outreach now that the first article ran.", "should_trigger": true },
{ "query": "Which outlets actually cover open-source launches?", "should_trigger": true },
{ "query": "Our founder wants to become a go-to source for reporters on this topic.", "should_trigger": true },
{ "query": "How do we keep a relationship with writers between announcements?", "should_trigger": true },
{ "query": "We need the coverage to land in German and French publications too.", "should_trigger": true },
{ "query": "Our buyer never touches the product - does that change who we pitch?", "should_trigger": true },
{ "query": "Write me a one-sentence and a one-paragraph version of our news for journalists.", "should_trigger": true },
{ "query": "Prepare our spokesperson for an interview about the breaking change.", "should_trigger": true },
{ "query": "What proof do technical writers ask for that we probably don't have?", "should_trigger": true },
{ "query": "Is 'we raised $14M' enough of a story on its own?", "should_trigger": true },
{ "query": "How do I offer a story to one outlet first without burning the others?", "should_trigger": true },
{ "query": "Rank the angles we could use for this announcement.", "should_trigger": true },
{ "query": "Tell me honestly whether pitching this is a waste of everyone's time.", "should_trigger": true },
{ "query": "Review this pull request and leave comments on the diff.", "should_trigger": false },
{ "query": "Write a PR description for my feature branch.", "should_trigger": false },
{ "query": "Respond to the review feedback on my pull request.", "should_trigger": false },
{ "query": "Summarize what changed in this pull request for the reviewer.", "should_trigger": false },
{ "query": "Our PR review turnaround is too slow - redesign the process.", "should_trigger": false },
{ "query": "Generate a walkthrough video from this PR.", "should_trigger": false },
{ "query": "Set up auto-labelling for incoming pull requests.", "should_trigger": false },
{ "query": "Our pull request template needs rewriting.", "should_trigger": false },
{ "query": "Resolve the merge conflicts in this pull request.", "should_trigger": false },
{ "query": "Draft a conventional commit message for these changes.", "should_trigger": false },
{ "query": "Sequence the channels for our open-source launch day.", "should_trigger": false },
{ "query": "How do we get onto GitHub Trending?", "should_trigger": false },
{ "query": "Plan a Show HN post for our repository.", "should_trigger": false },
{ "query": "What's the readiness gate before we make the repo public?", "should_trigger": false },
{ "query": "Clear our project name and license before we open source it.", "should_trigger": false },
{ "query": "Write the 'how we rewrote our scheduler in Rust' engineering blog post.", "should_trigger": false },
{ "query": "Edit this technical article so a skeptical developer believes the numbers.", "should_trigger": false },
{ "query": "Draft our public postmortem for last week's outage.", "should_trigger": false },
{ "query": "Our engineering blog reads like marketing - rewrite it.", "should_trigger": false },
{ "query": "Turn this customer's production deployment into a technical case study.", "should_trigger": false },
{ "query": "Get the reference customer's written approval for the numbers in their story.", "should_trigger": false },
{ "query": "I'm going on a podcast next week - help me prepare.", "should_trigger": false },
{ "query": "Prep me for a livestream interview about our database engine.", "should_trigger": false },
{ "query": "What sound bites should I have ready for a YouTube interview?", "should_trigger": false },
{ "query": "Build me a reading list of DevRel newsletters and podcasts to follow.", "should_trigger": false },
{ "query": "Which practitioners should I follow to stay current on developer relations?", "should_trigger": false },
{ "query": "Turn these commits into release notes.", "should_trigger": false },
{ "query": "Write the GitHub release body for v3.0.0.", "should_trigger": false },
{ "query": "Should we follow Keep a Changelog or Common Changelog?", "should_trigger": false },
{ "query": "Write a CFP abstract for a cloud-native conference.", "should_trigger": false },
{ "query": "My talk got accepted - help me structure the outline.", "should_trigger": false },
{ "query": "Plan which conferences we should submit proposals to next year.", "should_trigger": false },
{ "query": "Build a DevRel measurement framework for our exec review.", "should_trigger": false },
{ "query": "Set up a UTM tagging convention for our docs links.", "should_trigger": false },
{ "query": "Which devrel KPIs should we report to the board?", "should_trigger": false },
{ "query": "Should we pick MIT or Apache 2.0 for this project?", "should_trigger": false },
{ "query": "Write a GOVERNANCE.md for our maintainer team.", "should_trigger": false },
{ "query": "Do we need a CLA or is a DCO enough?", "should_trigger": false },
{ "query": "Write the migration guide for our 3.0 breaking changes.", "should_trigger": false },
{ "query": "Document the deprecation timeline for the old plugin API.", "should_trigger": false },
{ "query": "Which conferences should we sponsor and at what tier?", "should_trigger": false },
{ "query": "Start a monthly developer meetup in our city.", "should_trigger": false },
{ "query": "Design our engineering employer brand.", "should_trigger": false },
{ "query": "Engineers on employer-review sites say bad things about us - what do we do?", "should_trigger": false },
{ "query": "Help me start posting our monthly revenue publicly.", "should_trigger": false },
{ "query": "What should a build-in-public devlog include?", "should_trigger": false },
{ "query": "Benchmark our competitor's developer relations motion.", "should_trigger": false },
{ "query": "How good are our competitor's docs compared to ours?", "should_trigger": false },
{ "query": "Rewrite our repository README.", "should_trigger": false },
{ "query": "What should I pin on our GitHub organization profile?", "should_trigger": false },
{ "query": "Audit our documentation structure against Diataxis.", "should_trigger": false },
{ "query": "Write a quickstart that reaches first success in five minutes.", "should_trigger": false },
{ "query": "Our docs don't rank in search - fix the on-page SEO.", "should_trigger": false },
{ "query": "Should we go open core or hosted open source?", "should_trigger": false },
{ "query": "What should we charge for our API usage tier?", "should_trigger": false },
{ "query": "Design the self-serve to sales handoff for our developer product.", "should_trigger": false },
{ "query": "Write a code of conduct for our Discord server.", "should_trigger": false },
{ "query": "Our Slack community is dying - what should we measure?", "should_trigger": false },
{ "query": "Set up GitHub Sponsors tiers for my project.", "should_trigger": false },
{ "query": "Which open-source maintainers should our company fund?", "should_trigger": false },
{ "query": "Set up the printing press pipeline to publish my book chapters.", "should_trigger": false },
{ "query": "Reprint the product catalog with the updated pricing.", "should_trigger": false },
{ "query": "Score the output of the last printing-press run.", "should_trigger": false },
{ "query": "Schedule our social media posts for release week.", "should_trigger": false },
{ "query": "Write the LinkedIn post our CEO publishes on announcement day.", "should_trigger": false },
{ "query": "Write the internal email to employees explaining the acquisition.", "should_trigger": false },
{ "query": "Draft the customer-facing email announcing our price increase.", "should_trigger": false },
{ "query": "Write the in-app notice telling users to reset their password after the breach.", "should_trigger": false },
{ "query": "Write the X thread for our launch.", "should_trigger": false },
{ "query": "Draft this month's investor update.", "should_trigger": false },
{ "query": "Write the award submission for a best-developer-tool category.", "should_trigger": false },
{ "query": "Run an SEO audit on our marketing site.", "should_trigger": false },
{ "query": "Set up a cold email sequence to 200 sales prospects.", "should_trigger": false }
]
}
references/announcement-playbooks.md›
# Announcement Playbooks
Contents: nine announcement classes · the two that need special handling · when there is no news · reactive coverage.
Read the class that matches before drafting. Each entry gives the hook that earns coverage, the trap that kills it, and what the briefing pack needs beyond the standard contents.
## Funding round
- **Hook** - what the money makes possible that was impossible before, and the category thesis the investors are betting on. The round is the occasion, not the story.
- **Trap** - treating the amount as inherently newsworthy. Unless the size or the backer is unusual, "we raised" is a form.
- **Pack** - round size, lead, participants, prior total, what changes operationally, and whether hiring numbers can be quoted.
- **Timing** - investor communications and any disclosure obligation set the date; confirm both before offering an exclusive.
## General availability or exit from beta
- **Hook** - the problem class now solved at production scale, with a named early user and their numbers.
- **Trap** - announcing into a category the reader already knows with no differentiator beyond speed adjectives.
- **Pack** - the named customer, their workload shape, the SLA or scale commitment, and the pricing.
## Major version with breaking changes
- **Hook** - the engineering decision behind the break, its measured payoff, and its honest migration cost.
- **Trap** - framing a break as pure upside. The readers of technical press are the people who must migrate; they will find the cost with or without you.
- **Pack** - migration guide, deprecation timeline, codemod or compatibility layer, and the count of affected downstream projects.
- **Route** - the migration document itself is samber/developer-relations-skills@version-migration-guide.
## Benchmark or research data drop
- **Hook** - an original number nobody else has, framed as an industry benchmark rather than a product claim.
- **Trap** - vendor-run comparisons against competitors. They are challenged within hours unless the harness is public and reproducible.
- **Pack** - methodology, dataset or its anonymised form, the harness, hardware and versions, and a stated limitations section.
- **Bonus** - a benchmark published annually becomes a citable event that earns coverage on a schedule.
## Licence change
- **Hook** - the economics that forced it, stated plainly, and exactly what existing users keep.
- **Trap** - calling it a clarification. Every reader recognises the move and the euphemism becomes the story.
- **Pack** - the old and new licences, the conversion or grant terms, an FAQ answering fork and vendor questions, and the reasoning in numbers.
- **Plan for hostility** - brief the spokesperson to argue the case on record, expect fork announcements, and decide in advance what would make you reverse.
- **The precedent to plan against** - HashiCorp moved Terraform from MPL 2.0 to the Business Source License in August 2023. The OpenTF manifesto appeared within days and was ultimately endorsed by more than 140 companies and over 700 individuals. The Linux Foundation launched the OpenTofu fork on 20 September 2023, and a cease-and-desist HashiCorp sent in April 2024 was publicly rebutted and went no further. Organised opposition on this timescale is the base case for an established project, not the worst case.
- **Route** - the underlying decision is samber/developer-relations-skills@oss-license-strategy.
## Security incident or CVE
- **Hook** - timeline, blast radius, fix, and what changed in the process so it does not recur.
- **Trap** - letting news-cycle convenience influence disclosure timing. The coordinated-disclosure schedule governs; press planning fits around it, never the reverse.
- **Pack** - advisory, affected versions, patched versions, workarounds, detection guidance, credit to the reporter of the vulnerability.
- **Tone** - no minimising language, no passive voice hiding who did what. This class is judged on candour and speed alone.
- **Prerequisite** - coordinated disclosure only works if a monitored private security contact was published before any of this. Google's OSS Vulnerability Guide and GitHub Security Lab both describe the same sequence: private report, private advisory, patch, then public detail with credit to the reporter.
## Acquisition or merger
- **Hook** - what happens to the open-source project, the pricing, the API and the team. That is the entire story for this audience.
- **Trap** - silence on the parts users fear. The unanswered question becomes the headline.
- **Pack** - commitments with dates, who stays, what the licence and roadmap do, and the migration path if anything sunsets.
## Donating a project to a foundation
- **Hook** - the governance change and what vendor neutrality unlocks for adopters and contributors.
- **Trap** - presenting it as generosity. It is a governance decision with consequences, and the interesting question is who now decides what.
- **Pack** - the foundation and stage, the governance model, trademark disposition, maintainer roster, and who funds ongoing work.
- **Route** - the model choice is samber/developer-relations-skills@oss-governance.
## Customer outcome
- **Hook** - architecture before and after, with numbers the customer will stand behind publicly.
- **Trap** - an unnamed "leading enterprise". Anonymity halves the value and invites the reader to assume the worst.
- **Pack** - the customer's approval in writing, their spokesperson's availability, and the metric provenance.
- **Route** - build the story with samber/developer-relations-skills@developer-case-study first, then pitch it.
## When there is no news
Do not manufacture an event. Four alternatives that earn coverage without one:
1. **Proprietary data.** Aggregate what only this company can see, publish the methodology, and package it as a standalone report. It becomes citable long after the news cycle and gets referenced by later articles.
2. **A defensible position.** A technical argument someone is willing to defend publicly, tied to something happening now. Publish it in the open first so there is a public trail.
3. **Being a source.** Offer expertise on stories already running, with no ask attached. This is how the next pitch gets opened.
4. **The primary artefact.** For developer audiences a repository, a post-mortem or a deep write-up frequently outperforms the coverage it would have earned, and reporters find it on their own.
Recommending one of these instead of a pitch is a successful outcome, not a failure.
## Reactive coverage
Injecting a point of view into a running story works when three things hold at once:
- The expertise is genuine.
- The window is still open - roughly the first day.
- There is data or lived experience behind the take.
Send it as a short note to reporters already covering the story, offering a specific data point and one quotable sentence, and publish the same view on an owned surface so the trail exists.
It does not work on tragedies, on stories outside the sender's expertise, or when the angle reduces to "we sell something for this". Speed matters more than polish here: a good contribution in the first hours beats a better one on day three, which will not be read at all.
references/media-map-template.md›
# Media Map
Contents: outlet classes · dated examples · per-reporter verification · scoring rubric · a worked entry and its bad twin · the map artefact · the pitch tracker · maintenance.
## Table of Contents
- [Outlet classes](#outlet-classes)
- [Dated examples, not a send list](#dated-examples-not-a-send-list)
- [Per-reporter verification](#per-reporter-verification)
- [Scoring rubric](#scoring-rubric)
- [A worked entry and its bad twin](#a-worked-entry-and-its-bad-twin)
- [The map artefact](#the-map-artefact)
- [Tier 1](#tier-1)
- [Tier 2](#tier-2)
- [Do not pitch](#do-not-pitch)
- [The pitch tracker](#the-pitch-tracker)
- [Maintenance](#maintenance)
## Outlet classes
Build by class, then verify the humans inside it. Named lists rot within months; classes do not.
| Class | Trades in | Wants from you | Realistic outcome |
| -------------------------------- | ------------------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------- |
| Developer-native trade press | Architecture, languages, infrastructure, tooling shifts | A checkable technical claim, an engineer to interview, a working repository | A technical piece read by practitioners |
| Enterprise-IT trade press | Budgets, procurement, vendor moves, compliance | Customer names, deployment scale, the buyer's problem | Credibility inside accounts |
| Business and startup press | Funding, valuations, founders, market conflict | A round, an unusual number, an exclusive | Investor and candidate perception |
| Practitioner newsletters | One curator's judgement | Something their readers can use this week | High-intent clicks, small volume |
| Community aggregators and forums | Peer verdict, not editorial | The artefact itself, posted by a participant | Adoption, and unfiltered criticism |
| Analyst firms | Category framing and vendor comparison | A briefing, not a pitch | A correct mental model in buyer conversations |
| Podcasts, video, broadcast | A person with a position | A guest who argues something, not a product tour | Durable, transcribed, citable material |
Newsletters and community forums are routinely underrated for developer products: smaller audiences, but the readers are the adopters.
## Dated examples, not a send list
The publications that actually cover open-source launches, over and over: TechCrunch, The New Stack, The Register, TechTarget and SDxCentral, plus the Linux Foundation and CNCF newsrooms for foundation-backed announcements.
Use those as a calibration of what the classes above look like in practice - nothing more. They are a starting point for finding bylines, never a list to send to. Every name still has to pass the per-reporter verification below, and outlets fold, merge and reassign beats, so re-check the list itself before relying on it.
## Per-reporter verification
Every candidate needs all five before they enter the map:
- Last five bylines read, dated, and on this beat.
- Current employer confirmed on the outlet's own site.
- Stated pitch preferences noted, including any refusal of embargoes or pitches.
- Angle history noted - what they have already argued about this category, especially scepticism.
- A contact route that is real. Never guess an address into a send list; an unconfirmed contact is a blank field, not a hypothesis.
## Scoring rubric
Score each dimension 1-5, multiply, rank.
| Dimension | Question | Weight |
| -------------- | --------------------------------------------------------------- | ------ |
| Beat match | Do their recent bylines cover exactly this? | 3x |
| Audience fit | Does their readership contain the people who must believe this? | 2x |
| Responsiveness | Do they engage publicly, answer sources, run reader tips? | 2x |
| Recency | Have they touched this topic in the last quarter? | 1x |
Tiers:
- 30+ is tier 1 (bespoke pitch, eligible for exclusive or embargo).
- 18-29 is tier 2 (adapted pitch, after tier 1 answers).
- Below 18 is tier 3 (no pitch - they pick up from tier 1 or from your own post).
Audience fit outranks raw reach. A newsletter with four thousand platform engineers beats a general tech site with two million readers when the goal is adoption by platform engineers.
## A worked entry and its bad twin
The tempting shortcut is to rank by audience size and fill the contact column with whatever an address-guessing pattern produces. Both are illustrative entries; the reporter, outlet and dates are invented.
**Bad.**
| Reporter | Outlet | Beat evidence | Score | Contact |
| --------- | ------------ | ------------------------------------- | ----- | ------------------------------------------- |
| A. Rivera | BigTechDaily | writes about tech, 4M monthly readers | 40 | [email protected] (guessed pattern) |
Everything wrong with it: "writes about tech" is not beat evidence, the score is reverse-engineered from reach, no byline was read, no employment check was done, and the address is a hypothesis dressed as a fact. A send to this row bounces or annoys, and either way it burns the outlet.
**Good.**
| Reporter | Outlet | Beat evidence (last 5 bylines) | Score | Contact |
| --------- | ------------ | ------------------------------------------------------------------- | ----- | ------------------------ |
| A. Rivera | BigTechDaily | 1 of 5 on developer tooling (2026-03-02), rest on consumer hardware | 14 | verified via author page |
Same reporter, honest evidence, and the score drops them to tier 3 - no pitch. That is the map doing its job: it is as valuable for the sends it prevents as for the ones it produces.
## The map artefact
```markdown
# Media map - <product>, updated <date>
## Tier 1
| Reporter | Outlet | Beat evidence (last 5 bylines) | Score | Contact | Last contact | Outcome | Notes |
| -------- | -------- | ------------------------------------- | ----- | ---------- | ------------ | ------------------------- | ------------------------ |
| <name> | <outlet> | 3 of 5 on <topic>, most recent <date> | 34 | <verified> | 2026-08-14 | passed, asked for numbers | takes embargoes, no PDFs |
## Tier 2
…
## Do not pitch
| Reporter | Reason |
| -------- | ---------------------- |
| <name> | bio states no pitches |
| <name> | left the outlet <date> |
```
Keep the "do not pitch" section. It stops the same wasted send being repeated by the next person or the next campaign.
## The pitch tracker
One row per send, kept next to the map:
| Date | Reporter | Angle | Subject line | Ask | Reply | Outcome |
| ---- | -------- | ----- | ------------ | --- | ----- | ------- |
After roughly thirty sends, read the tracker rather than general advice: which angle, which subject-line shape and which ask actually work for this company will be visible in it, and they differ by category.
## Maintenance
- Re-verify employers quarterly; reporters change outlets constantly and a dead contact silently reduces the map.
- Add every reporter who covers the category, even hostile ones - knowing who is sceptical is planning information.
- Record who honoured an embargo and who did not. That record is the only basis for offering the next one.
- Never merge this map with the practitioner reading list from a radar skill. One is who you pitch, the other is who you learn from, and conflating them produces pitches to people who never write about products.
references/pitch-examples.md›
# Pitch Examples
Contents: subject lines · four worked pitches with their weak twins · the embargo email · the source reply · what makes the difference.
Every example below is illustrative and uses invented companies and numbers. Replace them with facts you can source; never ship a placeholder figure.
## Table of Contents
- [Subject lines](#subject-lines)
- [Pitch 1 - data story](#pitch-1-data-story)
- [Pitch 2 - major version with breaking changes](#pitch-2-major-version-with-breaking-changes)
- [Pitch 3 - funding](#pitch-3-funding)
- [Pitch 4 - licence change, hostile territory](#pitch-4-licence-change-hostile-territory)
- [The embargo email](#the-embargo-email)
- [The source reply, when a reporter asks you for a quote](#the-source-reply-when-a-reporter-asks-you-for-a-quote)
- [What separates the good from the weak](#what-separates-the-good-from-the-weak)
## Subject lines
| Weak | Stronger | Why |
| --------------------------------- | ------------------------------------------------------------------ | ------------------------------------------ |
| Introducing Fernbank 2.0 | Fernbank 2.0 drops Postgres support - here's the migration cost | Names the consequence a reader must act on |
| New data on developer workflows | 41% of deploys we measured happen after 4pm Friday | The number is the story |
| Story idea for you! | Re: your piece on build-cache pricing - we have the meter data | Anchors to their own work |
| Exciting partnership announcement | Embargo Sep 4, 09:00 CET: Fernbank donates its runtime to the CNCF | States what and when in one line |
| Following up on my last email | The customer from my last email can talk Thursday | Follow-up carries new information |
## Pitch 1 - data story
**Good.**
> Subject: 41% of production deploys we measured happen after 4pm Friday
>
> Hi Dana,
>
> Your piece on deployment freezes last month argued the Friday taboo is folklore. We have data either way.
>
> We analysed 2.3 million deploys across 4,100 organisations on our platform between January and June. 41% of production deploys land after 16:00 local on Friday, and their rollback rate is 1.4x the weekday average - but the gap disappears entirely for teams with automated rollback.
>
> Methodology and the anonymised dataset are here: <link>. Our infrastructure lead who ran the analysis can talk this week, and two customers in the sample have agreed to be named.
>
> Useful for a follow-up?
>
> - Sam, platform engineering, Fernbank
**Weak twin.** "Fernbank, the leading deployment intelligence platform, today announced groundbreaking new research revealing surprising insights into developer deployment behaviour. Our data shows that developers deploy at all hours! Let me know if you'd like the full report." - no number, no methodology, no relevance to anything she wrote, and the adjectives do the work the evidence should.
## Pitch 2 - major version with breaking changes
**Good.**
> Subject: Embargo Sep 9, 14:00 UTC: Fernbank 3.0 breaks its plugin API - why we did it
>
> Hi Marcus,
>
> You covered the plugin-compatibility mess in this ecosystem in March, so you may want this one early.
>
> Fernbank 3.0 breaks the plugin API. The old interface made every plugin a synchronous blocker in the request path; the new one is async and cuts p99 from 780ms to 120ms on our own workload. It also means all 340 community plugins need changes, and we're shipping a codemod that handles roughly 70% of them.
>
> Embargo to Sep 9, 14:00 UTC. Briefing pack, benchmark harness and the migration guide: <link>. Our maintainer can walk through the decision and the fallout on Thursday or Friday.
>
> - Sam
**Weak twin.** A version that leads with "Fernbank 3.0 is our most powerful release ever" and buries the break in paragraph four. Technical reporters write the break either way; hiding it just means the sender is not the source for it.
## Pitch 3 - funding
**Good.**
> Subject: Exclusive: Fernbank raised $14M to make build caching a shared utility
>
> Hi Priya,
>
> Offering you this one exclusively - you've tracked the build-infrastructure consolidation longer than anyone.
>
> Fernbank raised $14M led by <investor>, announcing Oct 2. The interesting part isn't the round: we're using it to run the cache as a shared multi-tenant utility, which every competitor has said is impossible for confidentiality reasons. We think the confidentiality argument is wrong and we're publishing the isolation model alongside the announcement.
>
> Can give you the founder, the lead investor, and two design partners under embargo. Need an answer by Friday so I can plan the rest.
>
> - Sam
**Weak twin.** "We're thrilled to announce our Series A! We'd love to get your thoughts." The round alone is a form, not a story, and "thoughts" is not an ask.
## Pitch 4 - licence change, hostile territory
**Good.**
> Subject: Fernbank is relicensing to BUSL on Nov 1 - happy to answer the hard questions
>
> Hi Alex,
>
> Heads up before it lands, since you wrote the definitive piece on the last relicensing wave.
>
> Fernbank moves from Apache 2.0 to BUSL 1.1 on Nov 1, with a four-year Apache conversion window. Existing releases stay Apache forever. The trigger was three vendors reselling the hosted product at a combined revenue several times ours; the numbers are in the post.
>
> We expect people to be angry and we're not going to pretend otherwise. Our founder will do an on-record interview including the questions about community trust and the fork risk.
>
> Post and FAQ under embargo here: <link>.
>
> - Sam
**Weak twin.** Framing it as "a clarification of our licensing to better serve the community". Every reader recognises the move, and the euphemism becomes the story.
## The embargo email
Keep it separate from the pitch, and repeat the terms:
> Confirming: everything below is under embargo until **Thursday 9 September, 14:00 UTC**. If that doesn't work for your publishing schedule, tell me now and I'll find a way rather than have you sit on it.
>
> In the pack: the announcement, two approved quotes, the benchmark harness, architecture diagram, and screenshots. <name> is available for interview Tue-Wed, 09:00-17:00 CET.
>
> I'm reachable at <phone> from lift time onwards for corrections.
## The source reply, when a reporter asks you for a quote
Answer in publishable form. Speed beats polish here - a usable answer in twenty minutes gets used; a perfect one tomorrow does not.
> Happy to be quoted:
>
> "Most teams don't have a caching problem, they have a cache-invalidation problem, and buying a bigger cache makes it worse." - Sam Okoye, principal engineer, Fernbank
>
> Two things I'd add off the record if useful: <context>. And I'd push back gently on the framing that this is new - <reason>.
>
> Reachable until 22:00 CET tonight on <phone>.
## What separates the good from the weak
- The good version could be checked by a stranger before publication; the weak one could only be repeated.
- The good version names a consequence for the reader; the weak one names a feeling of the sender.
- The good version concedes something true and unflattering. That concession is what makes the rest believable to a technical audience.
references/press-kit-checklist.md›
# Press Kit Checklist
Contents: press page · briefing pack · technical proof pack · quote craft · spokesperson prep · maintenance.
Two artefacts with different lifetimes. The press page is public and permanent. The briefing pack is private and per-announcement.
## Press page (`/press` or `/newsroom`)
- [ ] One-sentence, one-paragraph and ~100-word descriptions, copy-paste ready, in the same words the company uses everywhere else.
- [ ] Founding date, headquarters, headcount band, total funding if disclosed.
- [ ] Leadership and principal-engineer bios, third person, with high-resolution headshots downloadable without a form.
- [ ] Logo pack: SVG and PNG, light and dark, with usage rules and the correct capitalisation of the product name.
- [ ] Product screenshots and one short demo recording.
- [ ] Coverage list, most recent first.
- [ ] A named press contact, a real email address, and a stated response time.
- [ ] Pronunciation note if the name is not obvious.
Anti-patterns that cost coverage:
- A contact form instead of an address.
- Assets behind a lead-capture gate.
- A logo pack in a proprietary archive format.
- A page whose latest entry is two years old, which reads as a dead company to anyone checking before they write.
State a response time only if it will be honoured. An unmonitored press address is worse than none.
## Briefing pack (per announcement)
- [ ] The news in one sentence, then in one paragraph.
- [ ] Embargo line - date, clock time, timezone - repeated in the email and in the document.
- [ ] Two or three approved quotes with name, title and pronunciation if needed.
- [ ] Interview availability: who, which windows, which timezone, how to reach them at lift time.
- [ ] Assets: architecture diagram, screenshots, short recording, logo.
- [ ] The technical proof pack below.
- [ ] A named contact reachable during the embargo and at lift.
- [ ] For funding: round size, lead, participating investors, prior total, and what the money changes.
- [ ] For an open-source announcement: repository link, licence, governance state, maintainer count.
Send it as a linked page or plain text. A PDF is the format reporters complain about most, because they cannot copy from it cleanly on a deadline.
## Technical proof pack
The part that decides whether a developer-press story survives its own comment section.
- [ ] A running artefact: repository, sandbox, preview environment, or downloadable build available now - not "on request".
- [ ] Every performance claim with hardware, software versions, dataset, configuration and the harness, ideally public and runnable by a stranger.
- [ ] Architecture explanation separating what is genuinely new from what is assembled from known components.
- [ ] Comparison table against real alternatives with stated criteria - including the rows where you lose.
- [ ] Known limitations and an explicit statement of who this is not for.
- [ ] Licence, pricing and the boundary between open and commercial, stated without ambiguity.
- [ ] Security and compliance posture when the audience is enterprise buyers.
- [ ] Whatever a sceptical commenter would demand within an hour of publication - supply it before they ask.
## Quote craft
Reporters cut quotes that say nothing. A usable quote makes a claim, takes a position, or explains a decision.
- Weak: "We're thrilled to bring this innovative capability to our customers."
- Usable: "We knew the plugin API had to break the day we measured that 80% of our tail latency was other people's code running in our request path."
Write quotes for the person who will be named, in their own register, and get their approval before they ship. Two quotes is usually enough: one from the technical decision-maker, one from a customer or partner if the story needs external validation.
## Spokesperson prep
- Brief the spokesperson on the angle, the three points to land, and the two questions they least want.
- Agree in advance what is off the record and what is embargoed - different things, both stated explicitly.
- Rehearse the honest answer to the hardest question. Conceding a real limitation before bridging is what a technical audience reads as credible; a dodge is what they clip.
- Never claim an unreleased capability, an unapproved customer name, or an unpublished benchmark. Published articles outlive embargoes.
- If the spokesperson is going on a recorded show rather than into a written piece, hand the preparation to samber/developer-relations-skills@tech-podcast-interview-prep.
## Maintenance
Refresh the press page whenever headcount, funding, leadership or the product description changes, and add coverage as it lands. Re-check every asset link before each announcement; a broken logo link in a briefing pack is a request the reporter will not send twice.
references/published-findings.md›
# Published findings
Published claims with their sources, the self-set baselines used where no published figure exists, and the figures this skill refuses. Read it when a user challenges a number, when you are tempted to quote a statistic, or before adapting a threshold: press advice is unusually full of confident figures with nothing behind them.
## Sourced claims
| Claim used in the skill | Source |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Newsworthiness is a studied selection process; twelve factors named originally, revised twice, with shareability and immediacy rising in the latest revision | Galtung and Ruge (1965); Harcup and O'Neill (2001, 2017) |
| Earned / Owned / Shared / Paid as the scope split, and "earned media is what you know as either publicity or media relations" | Gini Dietrich, PESO model, launched with _Spin Sucks_ (2014) |
| "AVEs are not the value of Public Relations" - industry consensus, not one practitioner's view | AMEC Barcelona Principles, agreed 2010 by practitioners from 33 countries; 2.0 in 2015; 3.0 in 2020 |
| Press "needs to be organized up to 3 weeks before you plan to Launch" | Supabase, "How we launch at Supabase" (Ant Wilson, Nov 2021) |
| One to two weeks ahead for a large enterprise announcement, 24-48 hours for a standard one | PR-vendor practitioner convention - a widely repeated split, not a measured finding |
| Reporters at major tech outlets resent botched exclusives and embargoes - "the piss-poor execution" | TechCrunch writers, on how open-source launch embargoes get botched |
| Per-channel DRI, a stated review cadence, marking handled items, activating experts by mention, never submitting your own content, never commenting first, never soliciting upvotes, "conveying without convincing", the two-hour comment-edit window | GitLab Developer Advocacy handbook (public) |
| Move a vulnerability report out of a public thread into a private advisory before shipping a fix | Google OSS Vulnerability Guide; GitHub Security Lab coordinated-disclosure guidance |
| A licence change draws organised opposition: Terraform moved to BSL in August 2023, the OpenTF manifesto gathered 140+ companies and 700+ individuals, and a Linux Foundation-backed fork launched the following month | OpenTF manifesto; Linux Foundation OpenTofu announcement (20 September 2023) |
| Practitioner analysts frame developers as the decision-makers - "the kingmakers aren't enterprise salespeople… but hackers in t-shirts writing code" | RedMonk, redmonk.com/about |
| HARO's ownership changed three times between 2024 and 2025, so any platform-specific inbound advice needs re-checking | Wikipedia, _Help a Reporter Out_, corroborated by Cision and Featured.com announcements |
| Developers select tools on maturity, usability and documentation far more than on visibility signals | Larios Vargas et al., ESEC/FSE 2020 (DOI 10.1145/3368089.3409711), 115 survey respondents |
| A vendor briefing is typically free, one-way (vendor to analyst), open to non-client vendors whose request is accepted, and carries no promise of coverage or evaluation placement; an inquiry is a paid, two-way client benefit | Up/Right AR, "How to Brief a Forrester or Gartner Analyst" - an analyst-relations consultancy's account of Gartner's specific practice |
## This skill's own baselines
These are self-set defaults rather than published findings. They are defensible; say so if a user treats one as a standard.
| Baseline | Where it appears | Why this value |
| ------------------------------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Five qualification tests, failing two of them blocks the pitch | Step 1 | A devtool adaptation of the news-values lineage, sized so a genuinely thin story cannot pass on enthusiasm alone |
| 20-40 verified reporters in the media map | Step 3 | Small enough that one person can re-verify it quarterly; larger lists stop being maintained |
| Scoring weights 3x beat / 2x audience / 2x responsiveness / 1x recency, and the 30 / 18 tier cuts | media-map-template.md | Beat match dominates because a wrong-beat pitch fails regardless of every other dimension |
| Pitch body under ~150 words, subject line around 50 characters | Step 5 | Fits a mobile preview and a skim; the widely repeated version of this rule circulates uncited, but is now corroborated by a primary source: Muck Rack's State of Journalism 2026 survey (897 journalists) found 69% prefer pitches under 200 words - looser than 150, same direction |
| Day 0 / day 3 / day 7 follow-up ladder, then stop | Step 5 | Two touches leave room for genuinely new information without becoming pressure |
| The T-15 to T+7 embargo timeline | Step 6 | Built backwards from the sourced 3-week and 1-2-week anchors above |
| Roughly thirty pitches before per-company patterns are readable | Measurement | A sample-size intuition, not a computed one |
| The five-item pass threshold | Pass threshold | The conditions under which a send is recoverable if it goes wrong |
| The angle ordering - effort, value, compliance cost and efficiency across the five shapes | Step 2 | Reasoned from what each shape demands of a spokesperson, a dataset and a legal read, and meant to be re-ranked against the team executing it |
| The distribution ordering across exclusive, embargo, pre-briefing and lift-time send | Step 6 | Reasoned from coordination load and from how little of each commitment can be taken back once made |
## Figures deliberately not used
- **Journalist-survey statistics** - pitch volumes, reply rates, the share of pitches judged irrelevant, best send days, open rates attributed to subject lines. Numbers of this shape are everywhere in PR content, always uncited and often mutually contradictory. Quote none of them; compare the user to their own baseline instead. Two primary, citable, cross-corroborating exceptions now exist: Muck Rack's State of Journalism 2026 (897 journalists) found 69% prefer pitches under 200 words and 88% delete a beat-mismatched pitch; Cision's State of the Media 2026 (1,899 journalists, 19 markets) independently found 82% reject an irrelevant pitch and 52% expect a reply within 24 hours. Genuinely usable as sourced anchors, both from PR-software vendors surveying their own pitchers, so treat any generalisation past the US-heavy samples as inference.
- **Analyst-firm briefing policies** as fixed rules. Terms differ per firm and change often - the sourced row above corroborates the shape of the distinction for one major firm, not a policy every firm shares. The skill therefore describes the briefing-versus-inquiry distinction generically and tells the agent to check the firm's current published policy. No firm publishes an official re-brief cadence; practitioner and community sources cluster around one to two briefings a year with a given analyst for a non-client, moving to quarterly or monthly contact once paying - state this as a practitioner convention, never a firm rule.
- **Non-US media practice** was thin by design; real, named material now exists rather than being absent. Sifted publishes its own newsroom criteria for European tech coverage; Business Wire's European team notes GDPR consent before adding a journalist to a list and flags German pitches as expected to be formal; Japan's kisha-club system is documented as applying to legacy industries and ministries, not internet-era tech, so direct pitching works there; China shows two documented divergences (paid placement at some outlets, and platform-level rather than one-to-one journalist relationships). None of this is strong enough to promote into the skill's core workflow yet - each is one or two sources, not a corroborated pattern - but it closes the "nothing found" gap this file previously stated for the region.
- **A named outlet list.** Reporters move and beats get reassigned within months, so the skill teaches outlet classes plus per-reporter verification. The dated examples in media-map-template.md are illustrations of the classes, not a send list.
- **Coverage-to-revenue conversion.** Press reaches a developer funnel too indirectly to attribute revenue to one placement, so the measurement section refuses the conversion rather than offering a weak proxy.
SKILL.md›
---
name: tech-press-relations
description: Runs press and light analyst relations for a developer-facing product - news qualification, the angle, a reporter-to-beat media map, the pitch, embargo and exclusive handling, the press page and briefing pack, and what coverage is honestly worth. Use whenever someone raises tech press relations, getting press coverage, pitching a journalist, a tech media pitch, building a media list, a press kit, an embargo briefing, announcing a funding round, a launch coverage plan, an analyst briefing, or "how do we get written about" - even if they only say they want to be in the news. Nothing to do with pull requests. Not the announcement post itself - use samber/developer-relations-skills@engineering-blog-post.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# Tech Press Relations
You are a press-relations lead for developer-facing products. You decide whether there is a story, shape it into something a technical reporter can write, put it in front of the right humans at the right time, and tell the user honestly what the resulting coverage is worth.
Press does not convert developers. A developer who reads an article goes to the repository or the docs and decides there: in a 2020 survey of 115 developers, tool selection ran on maturity, usability and documentation far more than on visibility signals (Larios Vargas et al., ESEC/FSE 2020).
Coverage buys credibility instead, with non-developers: buyers, executives, candidates, analysts, other reporters. It also buys durable discoverability and citation surface. Sell it to the user on that basis, and refuse to promise sign-ups.
Two consequences shape everything below:
- Technical readers check claims, so every number ships with its methodology.
- Technical reporters get their pick of pitches, so the story has to be a story, not an announcement.
When a user asks you to buy coverage, say no and name the boundary: paid placement is advertising, with different rules and different disclosure, and this skill does not touch it. The fence is the PESO model (Gini Dietrich, _Spin Sucks_, 2014): you own **Earned** - coverage someone else chooses to publish - plus the Owned surfaces that serve it, the press page and the briefing pack. Shared belongs to the community channels; Paid is advertising.
Boundaries, so you route instead of duplicating:
- Channel sequencing for an open-source release: samber/developer-relations-skills@oss-launch.
- The announcement post itself: samber/developer-relations-skills@engineering-blog-post.
- The customer story a reporter might build on: samber/developer-relations-skills@developer-case-study.
- Preparing an appearance someone already booked: samber/developer-relations-skills@tech-podcast-interview-prep.
- The user's own reading list: samber/developer-relations-skills@devrel-radar, a different artefact from the media map built here.
**Sourced versus self-set.** Some numbers below come from a named published source; the rest are this skill's own working baselines - useful defaults with no survey behind them. Every self-set threshold is labelled where it appears, and [./references/published-findings.md](./references/published-findings.md) lists both columns, with a named source against every figure in the first. Never present a self-set baseline to the user as an industry standard, and re-check any figure before it goes into a pitch.
## Invocations and what you produce
| The user says | You produce |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| "we close a Series A in three weeks, plan the press" | A dated plan: qualification verdict, chosen angle, tiered media map, embargo-or-exclusive decision, briefing-pack checklist, day-of runbook |
| "who should we pitch our 2.0 release to" | A media map artefact - 20-40 verified reporters in three tiers, each with byline evidence and a contact route, plus a do-not-pitch list |
| "draft a pitch to this reporter" | One subject line plus a body under ~150 words, with the proof links, and a note on what the reporter will check first |
| "we're changing our licence and expect a backlash" | The licence-change playbook applied: honest economics, what users keep, a hostile-question brief for the spokesperson, and a reversal condition decided in advance |
| "build our press page" | A page spec and the copy blocks for it, plus the technical proof pack that makes it usable by a technical reporter |
| "should we brief analysts" | A firm-family recommendation, a shortlist, a briefing agenda, and a plain statement of what a briefing cannot buy |
| "we have nothing to announce but we want coverage" | A no-pitch verdict, plus the alternative that earns coverage without an event: a data report, a defensible position, source work, or publishing the work and letting it be found |
## Interview
Ask one question at a time, multiple-choice where possible, and stop as soon as you can name the news, the audience and the date. Questions 1-3 gate everything - draft nothing before they are answered.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. What happened or is about to happen, in one sentence, in plain language?
2. When must the coverage land: a fixed date you cannot move, a window, or unscheduled?
3. Who has to believe this - individual developers choosing their own tools, engineering leaders and buyers approving spend, investors and the market, or candidates? Rank them.
4. What is the outcome you would trade the coverage for: credibility for a sales motion, hiring signal, investor perception, adoption, or defending against a narrative? And is one placement on the date enough, or do you want a compounding asset - a benchmark you republish, a position that makes you a standing source?
5. What proof exists today - data nobody else has, a named customer cleared to speak, a public benchmark, a running demo, a repository?
6. What is your effort ceiling: how many hours the spokesperson and the engineer can give and in which timezone, whether anything new can be built for this (a dataset, a harness, a demo), what clearance you can get from legal or a customer, and how much relationship capital you can spend with reporters you will need again?
7. What constrains the timing: funding disclosure rules, a security-disclosure deadline, a partner's schedule, a conference, a legal review?
8. Is there an existing press page, prior coverage, or reporters you already know?
9. Which geography and language should coverage land in?
10. Is the buying motion bottom-up developer adoption, an enterprise deal signed by someone who will never use the product, or both?
If question 5 comes back empty, say so plainly and go to "When there is no news" in [./references/announcement-playbooks.md](./references/announcement-playbooks.md) before doing anything else.
Questions 2, 4 and 6 decide the angle ranking in step 2, which is why they are asked here rather than beside it: by step 2 the user has usually already fallen for an angle.
- A fixed near date deletes the number and the underdog, since neither can be assembled and cleared in time, and promotes the shift and the practitioner.
- A compounding mandate promotes the number and the broken system, the only two angles that keep paying after the news cycle.
- An effort ceiling that forbids building anything new deletes the number outright.
## Step 1 - Qualify the news
Run this gate before any drafting. A weak story pitched widely costs the relationships needed for the next one.
Newsworthiness is a studied selection process, not a matter of taste: Galtung and Ruge named twelve factors behind publication in 1965, and Harcup and O'Neill re-tested and revised the list in 2001 and 2017, when shareability and immediacy rose in weight. The five tests below adapt that lineage to devtools - self-set, not the published list. Name the lineage if the user asks where they came from.
Score the candidate against five tests, and answer each with evidence rather than optimism:
- **Newness** - did something actually change, or is this a scheduled step everyone could predict?
- **Consequence** - who has to do something differently now? Name them.
- **Evidence** - is there a number, something a stranger can open, or a person to interview?
- **Conflict or shift** - is this part of a bigger movement, a disagreement, or a reversal?
- **Tellability** - can the story be told fully today, with everything cleared for publication?
Fail two or more - a self-set bar - and the honest answer is "this is not a press story yet". Say it, then offer the alternatives: publish the primary artefact and let it be found, hold the news until it joins a bigger one, or build a data story instead. Recommending no-pitch is a legitimate and frequently correct outcome of this skill.
## Step 2 - Choose the angle
Never draft against the first idea. Offer the user two or three angles for the same facts, each with its trade-off, and a recommendation - then wait for a decision before writing anything.
Angle shapes that reliably work for developer products, **in efficiency order - coverage earned per hour and per unit of relationship capital spent**, highest first:
| Shape | What it offers a reporter | What it costs you | Effort |
| ----------------- | ------------------------------------------------------------ | --------------------------------------------- | ---------------------------------------------------------------------------------------- |
| The shift | Your news is evidence of a trend they are already tracking | Your product becomes a supporting detail | An hour - you reframe facts you already hold against a beat you can read in an afternoon |
| The practitioner | An engineer's decision, mistake or migration told concretely | Needs a person willing to be candid on record | An hour of that engineer's time, plus clearance if a customer is named |
| The broken system | A named systemic problem you are taking a position against | You must be willing to be quoted defending it | An hour to write, then a standing job defending it in public |
| The number | Proprietary data no one else holds, packaged as a benchmark | Methodology must survive scrutiny | A week to a quarter - collecting the data and building a harness a stranger can rerun |
| The underdog | A small team beating an incumbent at one specific thing | Only works if the one thing is verifiable | A week - the one thing needs a public, rerunnable comparison before you can claim it |
The axes disagree, so read all four:
- effort: the number > the underdog > the broken system > the practitioner == the shift
- value: the number > the broken system > the shift > the practitioner > the underdog
- compliance cost: the number > the underdog > the broken system > the practitioner > the shift
- efficiency: the shift > the practitioner > the broken system > the number > the underdog
The shift and the practitioner tie on effort because both are the same purchase: an hour of one person's time and nothing new built. They separate on value - a trend piece reaches buyers and analysts, an engineer's war story reaches developers and few others.
Compliance cost is the review each angle triggers and the reversibility it costs, never a fine.
- The number is worst: data drawn from user activity needs a consent and anonymisation review before publication, and a published benchmark naming rivals invites a comparative-claims challenge you cannot unpublish.
- The underdog is a comparative claim by construction.
- The broken system needs a read for whether the "practice" is identifiable with one company.
- The practitioner needs the customer's or the employer's sign-off before anyone speaks candidly.
- The shift triggers nothing.
The efficiency order starves the number, which leads on value and would produce the most durable asset - the thing still cited a year later and still surfacing in AI answers about the category. Promote it anyway when the data already exists as a by-product of running the product, so no collection work is needed, or when question 4 asked for a compounding asset rather than a placement. Then it beats everything above it.
Delete what the interview ruled out; do not park it at the bottom, and say which you deleted.
- No public rerunnable comparison in question 5 removes the underdog.
- Nobody clearable to speak on record in question 6 removes the practitioner.
- Data that cannot be cleared for publication removes the number.
This ranking is a default, not a law, and it shifts with who executes it: re-rank it against what you already know.
- A team whose founder is already a recognised voice on a practice promotes the broken system to first, because the standing job is one they are doing anyway.
- A team sitting on unique telemetry promotes the number.
- A team with no trend to attach to, in a category nobody is currently writing about, loses the shift entirely and the practitioner leads.
The enemy in "the broken system" is a practice or a norm, never a named competitor - attacking a rival reads as a smear and gets cut, while attacking a genuinely broken practice reads as a position and gets quoted.
Pressure-test the chosen angle with one question: if the product did not exist, would the reporter still want to write this? If yes, the angle is real and the product is the evidence. If no, keep working.
## Step 3 - Build the media map
Do not buy a database and do not reuse a list from an article. Build a map of 20-40 verified humans - a self-set size, small enough that one person can actually keep it verified - organised by outlet class, and keep it alive.
1. Work outward from coverage that already exists: find the last five articles about this category or its competitors and note the bylines.
2. For each candidate, read their last five pieces. Beats drift far faster than bios, so the bylines are the truth and the bio is decoration.
3. Confirm they still work there and still cover this. A pitch to a departed reporter is the most common wasted send.
4. Record their stated preferences where they publish them - no-pitch bios, embargo policies, "email me not the desk".
5. Score each on beat match (weight it heaviest), reach into the audience that must believe this, responsiveness, and recency on the topic.
6. Tier them: tier 1 gets a bespoke pitch and any exclusive or embargo; tier 2 gets the same story lightly adapted, after tier 1 has answered; tier 3 is not pitched and picks up from tier 1 or from your own post.
If you can browse the web, do the byline and employment checks yourself and show your evidence per reporter. If you cannot, give the user the checklist and have them fill it in - never invent a reporter, an outlet or an email address, and never guess a contact address into a pitch.
Use the class taxonomy and the artefact shape in [./references/media-map-template.md](./references/media-map-template.md).
If your environment has persistent memory, store the media map, every send and every reply. Press relations compounds only if the second campaign starts from the first one's record.
## Step 4 - Ship the assets before pitching
A reporter who says yes needs everything within the hour. Two artefacts, built in this order.
**Press page** - permanent, public, no form in front of it: copy-paste descriptions at three lengths, founding facts, bios and headshots, logo pack, screenshots, prior coverage, and a named press contact with a response time you will actually honour.
**Briefing pack** - per announcement: the news in one sentence and one paragraph, the embargo line with timezone, two or three approved quotes that sound like a person, interview availability, assets, and the technical proof pack.
The technical proof pack is the part generic press kits omit and the part that decides whether a developer-press story survives its own comment section:
- The running artefact.
- Every performance claim with hardware, versions, dataset and a harness someone else can run.
- An architecture explanation separating what is genuinely new from what is assembled.
- A comparison table that includes the rows where you lose.
- The known limitations.
- An unambiguous statement of licence and pricing.
Full checklists: [./references/press-kit-checklist.md](./references/press-kit-checklist.md).
## Step 5 - Write the pitch
One pitch per reporter, written for that reporter. Structure:
1. Why them - one line about their actual recent work.
2. The story in one sentence, in the shape chosen at step 2.
3. Why their readers care, stated from the readership's side.
4. Proof - the number with its methodology, the customer who will be named, the link that works.
5. One explicit ask: interview, embargo, exclusive, quote, or just flagging it.
Keep the body under about 150 words and the subject line around 50 characters - self-set working limits; the widely repeated versions of these rules circulate uncited. Put nothing load-bearing in an attachment, and never send a press release PDF as the pitch. Write the subject line so the reporter can predict the headline from it: lead with the specific number, name or decision, and prefix it honestly (`Exclusive:`, `Embargo <date>:`, `Data:`, `Re: <their headline>`).
Banned on sight: revolutionary, disruptive, game-changing, paradigm shift, seamless, robust, world-class, best-in-class, next-generation, cutting-edge, and "excited to announce". Each one tells a technical reporter the sender has nothing checkable to offer.
Run every pitch and every quote through your preferred humanizer skill before sending. Reporters read hundreds of these and recognise generated copy instantly; the pattern costs the sender the reply, not just the story.
Worked pitch and subject-line pairs, positive and negative: [./references/pitch-examples.md](./references/pitch-examples.md).
Follow up on day 3 only with new information, once more on day 7 with a fresh hook, then stop - a self-set cadence. "Bumping this" costs more relationship than the placement is worth.
## Step 6 - Plan the embargo
Get the vocabulary right with the user first, because these get confused and the confusion is what breaks relationships.
- An **embargo** lets several reporters write now and publish at one stated moment.
- An **exclusive** gives one outlet the story first and everyone else gets it afterwards.
- A **pre-briefing** is a context call before the news.
Embargo governs _when_; "off the record" governs _whether it can be used at all_: state both explicitly, never assume one implies the other.
Those four are a menu, so rank them where the choice is made. Effort is coordination and relationship capital; compliance cost is the review each one triggers and how little of it you can take back.
- effort: exclusive > embargo > pre-briefing > lift-time send
- compliance cost: embargo > exclusive > pre-briefing == lift-time send
- efficiency: embargo > pre-briefing > exclusive > lift-time send
The embargo tops compliance cost because it binds several outlets to a stated moment while your own repository, registry and status page can break it for you: the leak check below is that cost. Pre-briefing and lift-time send tie at nothing to review, since neither creates an obligation anyone can breach.
The order starves the exclusive, which buys the deepest single piece and spends the most capital to get it. Promote it when one outlet's readership is the audience from question 3, and the rest are noise, or when the story needs reporting time only a committed reporter will invest.
Working backwards from the announcement:
1. Shortlist and decide the exclusive-versus-embargo question around two weeks out.
2. Offer the exclusive first, one outlet at a time, with a deadline for their answer.
3. Open the embargo to the rest about a week out with the briefing pack.
4. Run briefings in the final days.
5. Lift the embargo, publish the owned post and hit community channels in the same minute.
The strongest lead-time fact available comes from a company describing its own practice: Supabase's 2021 account of how it launches states that press "needs to be organized up to 3 weeks before you plan to Launch". General PR practice is more permissive for smaller news - one to two weeks ahead for a large enterprise announcement, 24 to 48 hours for a standard one - but that split is practitioner convention from PR vendors, not a measured finding.
The schedule above is this skill's baseline built from both anchors. Shorten it knowingly: every day removed comes out of the reporter's ability to add reporting of their own, and a same-day embargo produces rewritten press releases at best.
Rules that protect the user:
- Offer an embargo only to reporters with a track record of honouring one. A first contact gets the news at lift time.
- State day, clock time and timezone. "Tuesday morning" is not an embargo.
- Never promise the same exclusive twice. It is always discovered, and reporters at major tech outlets describe botched exclusives and embargoes as the "piss-poor execution" they resent most.
- If someone breaks it, lift for everyone immediately so the honest outlets are not punished, then handle the relationship separately.
- Offer a factual check of specific technical claims. Never grant copy approval.
**The open-source leak check** - an embargo assumes secrecy, which a public repository rarely provides. Before committing to a lift time, verify that none of these will give the news away early:
- A pushed tag or a public release draft.
- A package published to a registry.
- A merged PR or a milestone whose name reveals the story.
- A docs deploy.
- A changelog entry.
- A licence or pricing file.
- A status-page note.
Stage the work privately, hold the tag and the publish until lift, and give reporters a tarball or a private preview instead of early repository access. Decide explicitly who internally knows the date.
## Step 7 - Run the announcement day
The owned post is the destination; coverage points to it, not the reverse. Sequence: owned post and press page live at lift time, embargoed coverage appears, then community channels - and let the community post be made by a participant, in that community's own register, never as a press release. Developer forums punish PR language and reward the work itself - the repository, the demo, the write-up.
Staff the window rather than improvising it. GitLab publishes its developer-advocacy playbook openly - the clearest documented model - and its mechanics generalise:
- Assign one directly responsible individual per channel to monitor and respond.
- State a review cadence. "As needed" is not one.
- Mark handled items off in a shared channel.
- Activate named experts by mention when a question is beyond the responder.
- Never submit your own content to a community aggregator, never make the first comment, never solicit upvotes.
For arguing in public, GitLab's framing is "conveying without convincing": the audience is the silent majority reading the thread, not the antagonist in it. Platforms also cap how long a comment stays editable - GitLab's handbook records a two-hour window on Hacker News - so a wrong number posted in haste is close to permanent.
If a vulnerability or a vulnerability-shaped claim appears in a public thread, stop discussing it there. Move the reporter to the private security contact, open a private advisory, ship the fix and the advisory together, and never debate severity or exploit detail in the open.
That is the coordinated-disclosure path from Google's OSS Vulnerability Guide and GitHub Security Lab; applying it to a live launch thread is this skill's inference from that guidance, not a documented incident. The path only exists if a monitored security contact was published before the announcement.
Hold someone reachable for the whole window for follow-up questions, corrections and asset requests. Track what publishes. Correct factual errors politely and specifically; let unflattering-but-accurate framing stand.
Then work the second wave: outlets that passed get pitched again with the coverage as proof, and the material gets reused - the data becomes a post, the post becomes a talk, the interview becomes a podcast pitch.
## Step 8 - Match the announcement type
Each class of devtool news has a hook that works and a trap that kills it - funding, GA, a major version with breaking changes, a benchmark or data drop, a licence change, a security incident, an acquisition, a foundation donation, a customer outcome. Read [./references/announcement-playbooks.md](./references/announcement-playbooks.md) for the one that matches, and read it before drafting rather than after.
Two of them are not ordinary press work.
- A **security incident** follows the coordinated-disclosure timeline, never the news cycle: never delay disclosure to catch a better slot.
- A **licence change** should be planned expecting hostile coverage, because the precedent is documented - see the licence-change entry in [./references/announcement-playbooks.md](./references/announcement-playbooks.md) for the case to plan against.
Write the economics honestly, state what existing users keep, prepare the spokesperson for the argument, and decide in advance what would make you reverse.
## Step 9 - Analyst relations, lightly
Analysts advise buyers and set the category vocabulary a procurement team uses. One accurate analyst mental model can outlive a hundred articles inside an enterprise account - but for a DevRel team this is a handful of briefings a year, not a programme, and this skill covers it accordingly.
Split the firms by who they serve. Practitioner-focused analysts study bottom-up adoption and reach developers directly; buyer-side research firms serve IT purchasing through subscriptions and comparative evaluations. Match the firm family to the motion from interview question 10.
A **briefing** is vendor-initiated, usually open to non-clients, and gets no advice back and no promise of coverage. An **inquiry** is a client asking the analyst a question. Check each firm's current published policy before scheduling, since the terms differ and change.
Run a briefing this way:
1. Send a short pre-read.
2. Bring the engineer who made the decisions.
3. Spend most of the time on the problem and the adoption evidence rather than the demo.
4. Ask what they are seeing in the category - that last part is the value the user takes home.
Tell the user plainly what a briefing cannot buy: inclusion or position in any paid evaluation. Anyone who implies otherwise is selling something else.
## Between announcements
Coverage arrives faster for senders reporters recognise, so keep a small ongoing practice: read the beat, offer value with no ask, and answer fast when a reporter needs a source on something with nothing in it for you. Reliability is what turns a contact into a relationship, and it cannot be assembled in the week before a launch.
## Adoption motion changes the plan
State the difference to the user rather than leaving it implicit.
- **Bottom-up developer adoption** - the reader who matters may never be reached by press at all. Optimise for what a developer can open - the repository, the docs, the primary technical write-up - and for citation surface; treat coverage as the credibility layer around them, and expect community forums to outperform trade press on actual adoption.
- **Enterprise, top-down buying** - the reader is a buyer or their proxy. Named customers, deployment scale, compliance posture and analyst framing carry the story, and every claim must be one the company will repeat in a procurement conversation.
- Both motions share everything else: the qualification gate, the angle work, the pitch craft, the embargo mechanics and the honesty rules apply identically.
## Measurement
Reply-rate and pitch-volume statistics circulate widely in PR content on uncited attributions, so quote none of them. Compare the user against their own baseline instead of an invented industry average.
That baseline must exist before the announcement: capture branded search, direct traffic, referring domains, repository and docs traffic, and sign-ups - or every number afterwards is unattributable.
| Signal | Worth |
| ---------------------------------------------------------------------------------- | ----------------------------------------------- |
| Sales or procurement conversations citing the article | Strongest, slowest, hardest to instrument |
| Inbound you could not have reached otherwise (partners, analysts, other reporters) | Strong |
| Referring domains and authority from the placement | Strong and durable |
| The article surfacing in AI assistants' answers about the category | Growing; spot-check by asking the question |
| Branded search and direct traffic, 7-14 days versus baseline | Directional; useless if another launch overlaps |
| Repository, docs and registry traffic in the window | Noisy; never attribute solely to press |
| Referral clicks from the article | A floor, never a total |
| Reach or impressions quoted by the outlet | Audience size, not effect |
| Advertising value equivalency | Refuse it |
Refusing advertising value equivalency is an industry consensus position, not a preference: AMEC's Barcelona Principles, agreed in 2010 by practitioners from 33 countries and revised in 2015 and 2020, state that "AVEs are not the value of Public Relations". Cite that when someone asks for the number anyway.
While the practice is young, measure the machine too: pitches sent, reply rate, briefings booked, coverage per announcement, and time from news to first placement. Reading per-company patterns out of that tracker needs a decent sample - treat roughly thirty pitches as this skill's working minimum, not a researched figure. Framework-level measurement design belongs to samber/developer-relations-skills@devrel-metrics.
## Pass threshold
Do not send anything until all five hold. The threshold is self-set - no published standard covers it - so iterate on the failing item instead of shipping around it.
1. The news passes at least four of the five qualification tests, or the user has accepted a no-pitch recommendation.
2. Every claim in the pitch is checkable from something public - a repository, a dataset, a docs page, a demo - or is a number shipped with its methodology.
3. Every reporter on the send list has a verified byline on this beat in the last few months and a verified current employer.
4. The press page and the briefing pack, including the technical proof pack, are live before the first pitch goes out.
5. If an embargo is used, the leak checklist is clear and the lift time is stated with a timezone.
## Failure modes
| Failure | What it looks like | Fix |
| -------------------------------------- | ------------------------------------------------------ | ---------------------------------------------------------- |
| Announcement mistaken for news | "We are pleased to announce" with nothing that changed | Return to step 1 and recommend no pitch |
| Spray and pray | One pitch BCC'd to forty addresses | 20-40 verified humans, one pitch each |
| Unbacked numbers | "10x faster" with no hardware, version or harness | Methodology in the proof pack or delete the claim |
| Embargo leaked by the repo | A tag or registry publish lands before lift | Run the leak check at step 6 |
| Exclusive double-promised | Two outlets discover they both had it | One exclusive, tracked in the media map |
| Copy approval requested | Asking to review the piece before it runs | Offer a technical fact-check of named claims |
| PR voice in a developer forum | A press release pasted into a community thread | A participant posts, in that community's register |
| Analyst briefing treated as a purchase | Expecting placement in an evaluation | State upfront what a briefing does and does not buy |
| Silence after coverage | No follow-up, no second wave, no relationship | Second-wave pitches, corrections, ongoing source work |
| Coverage sold as pipeline | A revenue number attributed to one article | Report the credibility and discoverability signals instead |
## References
- [./references/media-map-template.md](./references/media-map-template.md)
- [./references/pitch-examples.md](./references/pitch-examples.md)
- [./references/press-kit-checklist.md](./references/press-kit-checklist.md)
- [./references/announcement-playbooks.md](./references/announcement-playbooks.md)
- [./references/published-findings.md](./references/published-findings.md)
- samber/developer-relations-skills@oss-launch
- samber/developer-relations-skills@engineering-blog-post
- samber/developer-relations-skills@developer-case-study
- samber/developer-relations-skills@tech-podcast-interview-prep
- samber/developer-relations-skills@devrel-metrics