samber/developer-relations-skills已通过检查
SKILL DETAIL
developer-relations-kickoff
samber/developer-relations-skills/developer-relations-kickoff
Before starting any developer-relations work - and again at the start of each new session on an existing DevRel project - routes the current task to the right skill of the samber/developer-relations-skills collection, or says plainly that none fits, then bootstraps or resumes the project's shared devrel-context.md artifact. Covers documentation, open source, community, events, technical content, program strategy, devtools business strategy, employer brand and measurement; the output is a routing short-list plus an ordered skill chain. Run it at every project start even when the collection's skills are already in daily use elsewhere, at each periodic DevRel check-in, and whenever routing is unclear - a devrel kickoff, a new developer-relations project, "which devrel skill do I need", devrel, docs or open-source skill routing, or a recurring developer-program review - even if the user only describes a devrel problem and never asks which skill to use.
安装量 · 427查看来源
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill developer-relations-kickoff
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "developer-relations-kickoff",
"evals": [
{
"id": 1,
"prompt": "I'm the first developer relations hire at Halberd Metrics - 40 people, we sell a time-series database, $2.4M ARR. Most signups are bottom-up from individual engineers, but our two AEs close the six-figure deals with a VP Eng signing. My CEO's brief was literally 'do developer relations': in the same conversation he listed developer adoption, sales enablement, developer enablement, product feedback, ecosystem partnerships, contributor community and employer branding as things he expects from me. I start Monday. I have a $60k annual budget and I can request engineering time with about a week's notice. What should I actually do first?",
"expected_output": "A cold-start kickoff that flags the seven-driver answer as an absent strategy, promotes the program and company foundations class to the top of the short-list instead of opening at diagnosis, delivers an ordered dependency chain starting at devrel-strategy, and writes devrel-context.md.",
"files": [],
"expectations": [
"Flags that naming all seven business drivers means no driver is actually funded, and treats that as a strategy problem rather than a workload problem",
"Promotes the program and company foundations class to the first rung of the short-list instead of opening the short-list at the diagnosis class",
"Names `samber/developer-relations-skills@devrel-strategy` as the route for the immediate task or as the first link of the chain",
"States out loud which interview answer moved which class off its default position",
"Delivers an ordered chain rather than a single route, given that nothing formal exists yet",
"Presents the chain in dependency order and states that it is not ranked by efficiency or value",
"Every chain link states what it hands to the next link",
"The short-list holds between 5 and 8 entries",
"Every short-list entry names both the bottleneck it attacks and what the session costs",
"Asks at most 7 interview questions, one per message",
"Records the adoption motion as both individual self-serve and organization-buys rather than collapsing it to one",
"Writes or updates `devrel-context.md`, including a session-log line, before the session ends",
"Recommends no skill name outside the collection's own routing tables"
]
},
{
"id": 2,
"prompt": "Run my devrel check-in. Here's the devrel-context.md that sits in our repo root:\n\n# DevRel context\n_Last updated: 2026-07-02_\n\n## Product and audience\n- Product: Kestrel Queue, an open-source Rust job queue; a hosted control plane is in private beta.\n- Adoption motion: individual self-serve today; organization buys once the hosted plane ships.\n- Primary segment: platform engineers at 50-300 person companies.\n\n## Program\n- Funded driver: developer adoption.\n- Pillar mix: enablement 40%, community 30%, advocacy 20%, marketing 10%.\n- Stage and team: two people, one of them full-time.\n\n## Surfaces owned\n- Docs: docs.kestrelqueue.dev, Docusaurus, the platform team merges.\n- Community: Discord, 1,400 members, opened 2025-11.\n\n## Measurement\n- Weekly active docs readers, Discord message volume. Blind spot: no signup attribution.\n\n## State\n- In flight: quickstart rewrite, about 60% done.\n- Decided: no certification program, no paid community tier.\n- Open: whether to run our own user conference in 2027.\n- Constraints: no engineering support for docs; the result has to land before the 1.0 release on 2026-10-15; compounding assets preferred over one-off wins; ceiling is roughly six hours a week; VP Engineering signs off.\n\n## Stakeholders\n- VP Engineering - sign-off on anything touching the release train.\n\n## Session log\n- 2026-06-19 - \"docs are confusing\" -> developer-docs-structure-audit -> logged three misplaced pages.\n\nToday I want to get the 1.0 release communication right.",
"expected_output": "A warm-start run: five-line state summary, only the session-goal question asked, the release date used to re-rank, a route to changelog-writing and/or version-migration-guide, and a patched artifact with a new session-log line.",
"files": [],
"expectations": [
"Treats this as a warm start solely because `devrel-context.md` exists, and never asks the user whether this is a new or existing project",
"Produces a state summary of exactly 5 lines",
"The state summary covers product and audience motion, funded driver and pillar mix, program stage and team shape, in-flight work, and the active constraint",
"Asks only the session-goal question and asks no other interview question",
"Does not re-ask the landing date, the one-off-versus-compounding horizon or the effort ceiling, taking all three from the artifact",
"Uses the 2026-10-15 release date to re-rank, promoting the release and support cadence class",
"Routes the immediate task to `samber/developer-relations-skills@changelog-writing` and/or `samber/developer-relations-skills@version-migration-guide`, and says which of the two applies and why",
"Treats the certification decision as settled rather than as a live option",
"Removes `samber/developer-relations-skills@developer-education-strategy` from the short-list rather than ranking it last",
"Appends a new dated session-log line to the artifact",
"Patches only the artifact fields that changed rather than rebuilding the file",
"If the 2027 user conference is raised, flags it as organizer-side work belonging to `samber/dev-event-organizer-skills` rather than to a skill in this collection"
]
},
{
"id": 3,
"prompt": "Solvang Robotics here. Our SDK users are already up and running - they've done the install, they've made their first successful call, most have been in production for months. What they keep opening support tickets about is one specific page: how to rotate their signing key without dropping in-flight jobs. It's a single task, they already understand the concepts, they just need the procedure. Which of your docs skills do I use for that, and can you start it?",
"expected_output": "A plain statement that the collection has no skill for task-oriented how-to guides, with the gap named and the near neighbours explicitly ruled out rather than stretched.",
"files": [],
"expectations": [
"States plainly that the collection has no skill for task-oriented how-to guides",
"Names the how-to guide gap explicitly rather than routing to the nearest neighbour",
"Does not route to `samber/developer-relations-skills@developer-tutorial`",
"Does not route to `samber/developer-relations-skills@developer-quickstart-guide`",
"Does not route to `samber/developer-relations-skills@developer-troubleshooting-docs`",
"Explains that a quickstart serves a reader who has never run the thing, which this reader has",
"Explains that a tutorial teaches a concept by building something, which this reader did not ask for",
"Does not invent a skill name to cover the gap",
"Does not route to `samber/developer-relations-skills@developer-docs-structure-audit`, which operates on the whole docs set rather than one page",
"Notes that conflating a tutorial with a how-to guide fails both readers",
"Writes or updates `devrel-context.md` with a session-log line recording the gap"
]
},
{
"id": 4,
"prompt": "We're Tessellate Data. Two things on my plate this month. First: we've committed to running our own 600-person user conference in Lisbon next June - I need to sort the venue, the ticketing tiers, the CFP we'll be running ourselves, and a sponsor prospectus so we can sell booths. Second: this autumn we want to sponsor three other people's conferences, budget around $85k total, and my CFO wants proof afterwards that the money did something. Where do we start?",
"expected_output": "The two halves routed differently: the Lisbon conference recommended to samber/dev-event-organizer-skills as organizer-side work, the autumn sponsorship buying routed to developer-event-sponsorship inside this collection.",
"files": [],
"expectations": [
"Splits the request into two parts and routes them differently rather than answering both with one skill",
"Recommends installing `samber/dev-event-organizer-skills` for the Lisbon conference work",
"Does not route the Lisbon conference to `samber/developer-relations-skills@developer-meetup-program`",
"Does not route the organizer-run CFP to `samber/developer-relations-skills@conference-cfp-submission`",
"Does not route the sponsor prospectus to `samber/developer-relations-skills@developer-event-sponsorship` or `samber/developer-relations-skills@oss-sponsors-fundraising`",
"Routes the autumn sponsorship buying to `samber/developer-relations-skills@developer-event-sponsorship`",
"States the events boundary as who is paying: this collection covers the speaker and the sponsor, the sibling collection covers the organizer",
"Presents the sibling collection as a recommendation, never as a dependency this collection needs to function",
"Does not improvise organizer-side advice on venue, ticketing or prospectus pricing",
"Notes that the fixed June date promotes event-related work for that season",
"Does not claim a developer-relations skill exists for organizer-side sponsorship sales",
"Writes or updates `devrel-context.md` with a session-log line"
]
},
{
"id": 5,
"prompt": "Ferrograph - we're opening our internal API to customers in Q1. On my list: decide the rate-limit headers and what a 429 response body looks like, design idempotency keys so retried writes don't double-charge, spec the webhook retry and replay behaviour, and then document the whole thing for external developers, including making it readable by coding agents that integrate unattended. Which skills cover this?",
"expected_output": "API surface design recommended to samber/developer-platform-skills; the documentation half kept in this collection and routed to coding-agent-docs-optimization, with the boundary stated.",
"files": [],
"expectations": [
"Separates API surface design from documenting that surface and routes each differently",
"Recommends installing `samber/developer-platform-skills` for the rate limits, error shape, idempotency and webhook design",
"Keeps the documentation work inside this collection",
"Routes the agent-readable documentation work to `samber/developer-relations-skills@coding-agent-docs-optimization`",
"Does not route rate-limit or idempotency design to any developer-relations skill",
"States the platform boundary as who builds the surface: this collection documents and evangelizes it, the sibling collection designs it",
"Presents `samber/developer-platform-skills` as a recommendation rather than a dependency",
"Does not improvise the rate-limit, idempotency or webhook design itself",
"Does not invent a developer-relations skill name for API design",
"Routes exactly one skill for the immediate task rather than listing every documentation skill as equally applicable",
"Writes or updates `devrel-context.md` with a session-log line"
]
},
{
"id": 6,
"prompt": "Quarry Labs. Our web analytics tool says 4,100 people read the quickstart last month. Our CRM says 190 of those became accounts. Our product database says 96 accounts were created last month from any source at all. Three tools, three answers, and after my last monthly update our CEO said he's stopped believing any number I put in front of him. Fix this.",
"expected_output": "A route to devrel-analytics on the grounds that disagreeing tools is an instrumentation problem, with devrel-metrics placed later rather than chosen now.",
"files": [],
"expectations": [
"Routes the immediate task to `samber/developer-relations-skills@devrel-analytics`",
"Does not route the immediate task to `samber/developer-relations-skills@devrel-metrics`",
"Names the symptom - numbers disagreeing between tools - as an instrumentation problem rather than a framework problem",
"Identifies the identity spine and event taxonomy as what the routed skill supplies",
"Places `samber/developer-relations-skills@devrel-metrics` later rather than dropping it from the output",
"If a chain is offered, states what each link hands to the next",
"Does not route to `samber/developer-relations-skills@developer-community-health`",
"Does not route to `samber/developer-relations-skills@devrel-competitor-analysis`",
"Distinguishes \"leadership isn't convinced\" from \"our numbers disagree between tools\" and says which one this is",
"Does not attempt to reconcile the 4,100 / 190 / 96 figures itself or invent an attribution number",
"Writes or updates `devrel-context.md` with a session-log line recording the measurement blind spot"
]
},
{
"id": 7,
"prompt": "Norbury Systems. We opened a Discord five weeks ago. 118 members, maybe 20 messages on a good day, three of which are mine. My VP wants a community health dashboard on the next board deck in a fortnight. Build me the metrics.",
"expected_output": "The health measurement deferred to a not-now entry with the day-90 baseline condition attached, and today's session routed to work that is actionable at five weeks.",
"files": [],
"expectations": [
"Declines to run `samber/developer-relations-skills@developer-community-health` now",
"Moves it to a \"not now\" list with an explicit unblocking condition rather than onto the short-list",
"States the unblocking condition as a baseline that does not exist until roughly 90 days of activity",
"Attributes the day-90 gate to `samber/developer-relations-skills@developer-community-launch`'s own working convention",
"Does not drop the health skill from the output entirely, since it has a stated unblocking condition",
"Routes today's work to a skill that is actionable at five weeks, such as `samber/developer-relations-skills@developer-community-launch` or `samber/developer-relations-skills@developer-community-moderation`",
"Notes that moderation rules are written before the first incident rather than after it",
"Does not invent community health benchmark numbers for a five-week-old Discord",
"Does not propose a periodic measurement routine, since no baseline exists to trend against",
"Keeps the community skills in timeline order - launch, then moderation, then health, then champions - rather than jumping to the measurement end",
"Writes or updates `devrel-context.md` with a session-log line"
]
},
{
"id": 8,
"prompt": "Ardent Cloud, Series B, 140 people. We've set aside $4,000 a month to put into open-source projects we depend on. I need to work out which projects, how much each gets, and which tier to pick on their sponsor pages - plus something I can show the board that proves the money did anything at all. Separately, our own Ardent-maintained CLI has about 3k stars and a couple of people have asked how they could fund it; that's a later problem, not this month's.",
"expected_output": "A route to oss-sponsors-brand-strategy for the company-side portfolio, with oss-sponsors-fundraising moved to not-now, and the who-pays-whom disambiguation stated.",
"files": [],
"expectations": [
"Routes the immediate task to `samber/developer-relations-skills@oss-sponsors-brand-strategy`",
"Does not route the immediate task to `samber/developer-relations-skills@oss-sponsors-fundraising`",
"States the disambiguation as who is paying whom, read from the subject of the question",
"Identifies \"which tier should we pick on this maintainer's page\" as company-side work despite the maintainer's page being named",
"Moves `samber/developer-relations-skills@oss-sponsors-fundraising` to the \"not now\" list rather than onto the short-list",
"Gives that not-now entry an explicit unblocking condition",
"Does not route to `samber/developer-relations-skills@developer-event-sponsorship`",
"Does not route the project-by-project allocation to `samber/developer-relations-skills@devrel-budget-allocation`",
"Does not invent per-project funding amounts",
"Treats the board-proof requirement as inside the routed skill's scope rather than as a separate skill",
"Writes or updates `devrel-context.md` with a session-log line"
]
},
{
"id": 9,
"prompt": "Loamside. Two asks. One: we're hiring a senior developer advocate and I need the job posting, a breakdown of what each interview stage is actually testing, and a scorecard so my panel stops arguing about gut feel. Two: every quarter I have to stand in front of the exec team and defend the devrel budget with a narrative deck, and I am genuinely bad at it - last quarter they cut us 20% because I couldn't tell the story. Sort both.",
"expected_output": "The hiring ask routed to devrel-hiring with career and employer-branding ruled out, and the exec-facing report named plainly as a coverage gap rather than routed to metrics or budget allocation.",
"files": [],
"expectations": [
"Routes the hiring ask to `samber/developer-relations-skills@devrel-hiring`",
"Does not route the hiring ask to `samber/developer-relations-skills@devrel-career`",
"Does not route the hiring ask to `samber/developer-relations-skills@tech-employer-branding`",
"States that `samber/developer-relations-skills@devrel-career` is the candidate side of the same role knowledge",
"States that `samber/developer-relations-skills@tech-employer-branding` covers the engineering employer brand, not one role's interview loop",
"States plainly that the collection has no skill for the exec-facing DevRel report narrative and budget defense",
"Does not route the exec deck to `samber/developer-relations-skills@devrel-metrics`",
"Does not route the exec deck to `samber/developer-relations-skills@devrel-budget-allocation`",
"Does not invent a skill name for the exec report",
"Names the exec-report gap in the output's gap section rather than only in passing",
"Does not offer to build the slide deck, which the collection also does not cover",
"Writes or updates `devrel-context.md` with a session-log line"
]
},
{
"id": 10,
"prompt": "Plimsoll - open-source observability agent, MIT, 11k stars, three maintainers but only I do anything non-code. We tag a release most Thursdays. We run a Discord with about 900 people. CFP season for next year's conferences opens in three weeks. Our issue backlog is at 340 open and nobody is assigned to it - honestly nobody wants to be. Set up whatever recurring automation you can so this stuff stops falling through. Our harness supports scheduled jobs and can also react to repository events like tag pushes.",
"expected_output": "Between two and four routines, each shown as a dry-run with an output channel, ranked by value per unit of standing effort with the release-tag pass first, the queue review withheld for lack of an owner, and the tag-push event used as a trigger.",
"files": [],
"expectations": [
"Proposes no more than 4 routines",
"Proposes at least 2 routines",
"Shows every proposed routine as a dry-run before creating anything",
"Gives every proposed routine an explicit output channel",
"Places the release-tag documentation pass at the first rung rather than the cheapest routine",
"Does not place the kickoff re-invocation first on the grounds that it costs almost nothing",
"States the routine ranking out loud as value per unit of standing effort",
"Includes a periodic re-invocation of this kickoff among the proposed routines",
"Uses the tag-push event as the release routine's trigger rather than a weekly schedule",
"Promotes the CFP deadline sweep for the season because CFP season opens in three weeks",
"Withholds or demotes the issue and pull-request queue review because nobody owns the follow-through it generates",
"Lists routines already installed and retires obsolete ones before adding new ones",
"Names the skill each routine runs in `owner/repo@skill` form"
]
},
{
"id": 11,
"prompt": "Before we go any further, save all of this to your memory so I don't have to repeat it every session, and commit it to the repo while you're at it. We're Vantablack Systems. Funded driver is developer adoption. Q1 pricing is going to $79 per seat but that is not announced until February. We banned a Discord member last month - handle @rkoenig-dev, he was harassing one of our maintainers in DMs, the full incident report is in our internal folder. We're paying EUR 18,000 for the platinum tier at DevConf under an NDA that says we can't disclose the rate. And Northwind Freight is by far our best deployment story but their legal team hasn't cleared us to name them yet.",
"expected_output": "The permitted facts written into devrel-context.md first and the memory entry derived from it, with the moderation case, unannounced pricing, NDA rate and uncleared customer name excluded and the exclusion stated, and no silent commit.",
"files": [],
"expectations": [
"Writes the durable facts into `devrel-context.md` first and derives the memory entry from the artifact, never the reverse",
"States that the artifact stays the source of truth because memory is invisible and unreviewable to teammates",
"Excludes the moderation case and the banned member's handle from memory",
"Excludes the unannounced Q1 pricing from memory",
"Excludes the NDA-bound DevConf sponsorship rate from memory",
"Excludes the uncleared Northwind Freight customer name from memory",
"States the exclusion list at the moment it first writes memory",
"Does not commit the memory to the repository silently",
"Shows the diff and asks for approval before committing anything to the repository",
"Persists the funded driver - developer adoption - as a fact that is permitted in memory",
"Names where memory may live: local to the user's environment, a team knowledge base, or a `memories/` directory in a git repository",
"Creates or names an index file listing each memory entry with a one-line hook",
"Does not refuse the whole request outright - persists the permitted facts while excluding the banned categories"
]
},
{
"id": 12,
"prompt": "Here's what's in our repo - tell me what developer relations work we should be doing.\n\n$ ls -a\n.github/ docs/ src/ README.md LICENSE CHANGELOG.md CODE_OF_CONDUCT.md mkdocs.yml AGENTS.md\n\n$ git log --oneline --since='6 months ago' | wc -l\n7\n\n$ git log -1 --date=short --format='%ad'\n2026-06-30\n\nWe're Copperline, an Apache-2.0 Python library for schema migrations, about 2,200 stars. We do take outside pull requests - three got merged this year.",
"expected_output": "Detection run over the listed evidence first, the missing CONTRIBUTING file read as a routing signal, the stalled log read as a reason to diagnose before building, and a capped interview that skips what the inventory already answered.",
"files": [],
"expectations": [
"Runs detection over the listed files and git output before asking any interview question",
"Does not ask the user whether a README, LICENSE, changelog or code of conduct exists",
"Treats the absence of a CONTRIBUTING file as a routing signal in its own right",
"Promotes `samber/developer-relations-skills@oss-contributor-onboarding` inside the first-run surfaces class because CONTRIBUTING is missing",
"Reads 7 commits in six months with the last dated 2026-06-30 as a stalled project",
"Points at diagnosis before any build work because of that stall",
"Notes that `mkdocs.yml` means a docs site already exists, and does not ask whether one does",
"Notes that `AGENTS.md` is an agent-instruction file already present, and offers to patch it with the project's invariants rather than asking whether one exists",
"Asks at most 7 questions, one per message",
"Skips interview questions the file inventory already answered and says which ones it skipped",
"Does not ask the user whether this is a cold or warm start - that is decided only by whether `devrel-context.md` exists",
"Creates `devrel-context.md` with a session-log line without scaffolding directories the project has not earned"
]
},
{
"id": 13,
"prompt": "Wolfsbane Analytics. Our 'Getting Started' page is doing two jobs badly. Roughly half the people landing on it have never touched change data capture at all and want to understand what our replication model actually does before they'll trust it with production data. The other half already run CDC somewhere else and just want one table replicated into our warehouse inside ten minutes so they can show their lead it works. Rewrite the page.",
"expected_output": "The page split by reader state into two different routes - quickstart for the verified-success reader, tutorial for the concept learner - presented unranked, with the structure audit ruled out as whole-set work.",
"files": [],
"expectations": [
"Refuses to produce one page serving both readers",
"Routes the ten-minute, verified-success reader to `samber/developer-relations-skills@developer-quickstart-guide`",
"Routes the concept-learning reader to `samber/developer-relations-skills@developer-tutorial`",
"States the fork as the reader's state rather than as what the page will be called",
"Does not route to `samber/developer-relations-skills@developer-docs-structure-audit` for rewriting one page",
"States that the structure audit operates on the whole docs set, never on one page",
"Does not present the two routes as ranked against each other",
"Explains that conflating them fails both readers: the learner gets an unexplained recipe, the working developer gets a lecture",
"Does not route to `samber/developer-relations-skills@readme-optimization`",
"Does not write the replacement page itself in place of routing",
"Offers the docs chain only if the task genuinely decomposes, and states what each link hands to the next if it does",
"Writes or updates `devrel-context.md` with a session-log line"
]
},
{
"id": 14,
"prompt": "I maintain Thistledown on my own - a TypeScript date library, 6,800 stars, MIT, no company behind it, no revenue, and I genuinely don't want any. I've got maybe four hours this Saturday and then I'm back to the day job and won't touch it for months. What's worth doing with those four hours?",
"expected_output": "Commercial skills deleted outright rather than demoted, the short-list cut to two entries from the diagnosis and first-run surfaces classes, and exactly one routine proposed.",
"files": [],
"expectations": [
"Deletes `samber/developer-relations-skills@devtools-pricing-strategy` from the short-list entirely",
"Deletes `samber/developer-relations-skills@devtools-business-model` from the short-list entirely",
"Deletes `samber/developer-relations-skills@developer-first-gtm` from the short-list entirely",
"Does not park any of those three at the bottom of the short-list as a demoted option",
"Cuts the short-list to exactly two entries",
"Draws both entries from the diagnosis class or the first-run surfaces class",
"Names both the bottleneck attacked and the cost on each of the two entries",
"Proposes exactly one routine",
"That routine is the periodic re-invocation of this kickoff",
"Does not propose the issue and pull-request queue review as a routine",
"Does not recommend opening a community venue inside a four-hour ceiling",
"Writes `devrel-context.md` with a session-log line rather than scaffolding a larger working tree"
]
}
],
"trigger_queries": [
{ "query": "Which devrel skill do I need for this?", "should_trigger": true },
{ "query": "Start a new developer relations project with me", "should_trigger": true },
{ "query": "Run my devrel check-in", "should_trigger": true },
{ "query": "We just open-sourced our SDK and nobody uses it - where do I start?", "should_trigger": true },
{ "query": "I'm the first DevRel hire here and I have no idea what to do first", "should_trigger": true },
{ "query": "which of your developer relations skills covers this", "should_trigger": true },
{ "query": "kick off a devrel project", "should_trigger": true },
{ "query": "I need help figuring out which skill applies to my docs problem", "should_trigger": true },
{ "query": "Can you route this to the right developer-relations skill?", "should_trigger": true },
{ "query": "Our developer program review is due - walk me through it", "should_trigger": true },
{ "query": "new devrel engagement, let's set it up", "should_trigger": true },
{ "query": "devrel kickoff please", "should_trigger": true },
{ "query": "Time for our quarterly developer relations review", "should_trigger": true },
{ "query": "I don't know if this is a docs problem or a community problem", "should_trigger": true },
{ "query": "Not sure whether we need better docs, a community, or just more blog posts", "should_trigger": true },
{ "query": "help me prioritise our developer relations work for next quarter", "should_trigger": true },
{ "query": "What should our developer advocacy team work on first?", "should_trigger": true },
{ "query": "We have fifty things we could do for developers and six hours a week", "should_trigger": true },
{ "query": "Starting fresh on developer experience at a new company, where do I begin", "should_trigger": true },
{ "query": "Resume where we left off on the developer relations project", "should_trigger": true },
{ "query": "pick up my devrel context from last time", "should_trigger": true },
{ "query": "I have a devrel-context.md in the repo, read it and tell me what's next", "should_trigger": true },
{ "query": "Our engineers love the product but nobody outside the company knows it exists", "should_trigger": true },
{ "query": "Set up a developer relations program from scratch", "should_trigger": true },
{ "query": "which skill should I run for this developer experience problem", "should_trigger": true },
{ "query": "Is there a skill for improving how developers discover our tool?", "should_trigger": true },
{ "query": "We're hiring our first developer advocate and I don't know what the program should even do", "should_trigger": true },
{ "query": "My CEO wants a developer relations strategy by Friday and I don't know where to start", "should_trigger": true },
{ "query": "Give me the short-list of what to do for our open-source project this month", "should_trigger": true },
{ "query": "we ship a great API but adoption is flat, what now", "should_trigger": true },
{ "query": "Everything about our developer program feels ad hoc", "should_trigger": true },
{ "query": "Can you help me plan developer relations work?", "should_trigger": true },
{ "query": "I run community and docs and events alone - what should I drop?", "should_trigger": true },
{ "query": "New quarter, new devrel plan, help", "should_trigger": true },
{ "query": "Where should I focus: the README, the Discord, or the conference talks?", "should_trigger": true },
{ "query": "Our open source project is growing and I'm drowning - help me triage what matters", "should_trigger": true },
{ "query": "developer relations onboarding for a new project", "should_trigger": true },
{ "query": "I inherited a devrel program with no documentation of what it's for", "should_trigger": true },
{ "query": "What are all the things you can help me with for developer relations?", "should_trigger": true },
{ "query": "We want to grow developer adoption but don't know the first step", "should_trigger": true },
{ "query": "help me figure out what to work on for our developer community", "should_trigger": true },
{ "query": "It's been a month since we last looked at the devrel plan", "should_trigger": true },
{ "query": "start of project checklist for developer advocacy", "should_trigger": true },
{ "query": "I want to set up recurring reminders for our developer relations work", "should_trigger": true },
{ "query": "Our developer program has no written goals and everyone argues about scope every sprint", "should_trigger": true },
{ "query": "Pick the right approach for making our SDK easier to adopt", "should_trigger": true },
{ "query": "We keep re-arguing what devrel is for. Can you help settle it?", "should_trigger": true },
{ "query": "give me an ordered plan for our developer ecosystem work", "should_trigger": true },
{ "query": "Which should I do first: rewrite the README, open a Discord, or write a migration guide?", "should_trigger": true },
{ "query": "I've got a new open-source repo, a small budget, and no plan", "should_trigger": true },
{ "query": "developer marketing project start", "should_trigger": true },
{ "query": "let's do the devrel session", "should_trigger": true },
{ "query": "Can you look at our repo and tell me what developer-facing work is missing?", "should_trigger": true },
{ "query": "I need a routing decision - docs structure audit or keyword research?", "should_trigger": true },
{ "query": "We're rebooting developer relations after the old team left", "should_trigger": true },
{ "query": "What developer relations work is worth doing with two engineers and no budget?", "should_trigger": true },
{ "query": "Help me decide what my developer experience roadmap should contain", "should_trigger": true },
{ "query": "Onboard me onto your developer relations skill collection", "should_trigger": true },
{ "query": "I read your devrel skills list and I'm lost - which applies to a pre-launch database tool?", "should_trigger": true },
{ "query": "our docs are fine but signups never reach production, which skill covers that", "should_trigger": true },
{ "query": "Take stock of our developer program and tell me the next three moves", "should_trigger": true },
{ "query": "Set me up so the next session doesn't start from zero", "should_trigger": true },
{ "query": "Recap the state of our developer relations project and re-route me", "should_trigger": true },
{ "query": "We just closed a funding round and want developers to love us - plan it", "should_trigger": true },
{ "query": "I'm the only person doing anything developer-facing here and I'm guessing", "should_trigger": true },
{ "query": "Is our problem discovery, activation or retention? I have no idea where to start.", "should_trigger": true },
{ "query": "A conference is in eight weeks and our docs are broken. What comes first?", "should_trigger": true },
{ "query": "Should I be spending my week on content or on the contributor funnel?", "should_trigger": true },
{ "query": "check in on the developer program", "should_trigger": true },
{ "query": "My team wants to do everything at once for developers. Help me sequence it.", "should_trigger": true },
{ "query": "new project, developer tooling company, need a devrel plan", "should_trigger": true },
{ "query": "What's the highest leverage thing I can do for developers this week?", "should_trigger": true },
{ "query": "Route me to whatever covers turning our GitHub repo into something people actually use", "should_trigger": true },
{ "query": "warm start - I have context saved from our last developer relations session", "should_trigger": true },
{ "query": "I'd like to schedule recurring developer relations routines", "should_trigger": true },
{ "query": "We need to decide what our developer relations team is even accountable for", "should_trigger": true },
{ "query": "Write release notes for v3.2.0 from these commits", "should_trigger": false },
{ "query": "Audit our README and rewrite the first screen", "should_trigger": false },
{ "query": "Draft a CFP abstract for KubeCon EU", "should_trigger": false },
{ "query": "Turn my accepted abstract into a 25-minute talk outline", "should_trigger": false },
{ "query": "Make our live demo survive bad conference wifi", "should_trigger": false },
{ "query": "Write the migration guide for our v2 to v3 breaking changes", "should_trigger": false },
{ "query": "Write a code of conduct for our Discord", "should_trigger": false },
{ "query": "Design the tier ladder and rewards for our GitHub Sponsors page", "should_trigger": false },
{ "query": "Pick a license for our new Go library", "should_trigger": false },
{ "query": "Set up a good-first-issue queue and write our CONTRIBUTING file", "should_trigger": false },
{ "query": "Design our issue triage labels and response targets", "should_trigger": false },
{ "query": "Write a technical blog post about our new storage engine", "should_trigger": false },
{ "query": "Script a six-minute screencast for our CLI", "should_trigger": false },
{ "query": "Prepare me to be a guest on a technical podcast next week", "should_trigger": false },
{ "query": "Build a quarter of content slots with owners and review dates", "should_trigger": false },
{ "query": "Classify every page in our docs against Diataxis", "should_trigger": false },
{ "query": "Write a quickstart that gets a reader to their first successful API call", "should_trigger": false },
{ "query": "Write a tutorial teaching vector search with our SDK", "should_trigger": false },
{ "query": "Build an error-code catalog from our support tickets", "should_trigger": false },
{ "query": "Define the policy every code sample in our docs must meet", "should_trigger": false },
{ "query": "Fix canonicals and hreflang across our versioned docs site", "should_trigger": false },
{ "query": "Find the error strings developers are actually searching for", "should_trigger": false },
{ "query": "Make our docs crawlable by coding agents and add an llms.txt", "should_trigger": false },
{ "query": "Cut our developer audience into named, sized segments", "should_trigger": false },
{ "query": "Which KPIs should our devrel team have targets on?", "should_trigger": false },
{ "query": "Design our event taxonomy and UTM tagging conventions", "should_trigger": false },
{ "query": "Split a $300k devrel budget across pillars with return thresholds", "should_trigger": false },
{ "query": "Should devrel report to marketing or to product?", "should_trigger": false },
{ "query": "Benchmark a competitor's devrel motion against ours", "should_trigger": false },
{ "query": "Should we build a certification program for our platform?", "should_trigger": false },
{ "query": "Map the developer journey and find the biggest leak", "should_trigger": false },
{ "query": "Pick the business model for our developer tool: open core or hosted?", "should_trigger": false },
{ "query": "Set the value metric and free-tier limits for our API pricing", "should_trigger": false },
{ "query": "Design the developer-to-buyer handoff in our sales motion", "should_trigger": false },
{ "query": "Decide which of our internal libraries we should open source", "should_trigger": false },
{ "query": "Should we open our product into a plugin platform?", "should_trigger": false },
{ "query": "How should we engage with the OpenTelemetry spec - consume it or contribute?", "should_trigger": false },
{ "query": "Write our project's governance model and maintainer promotion rules", "should_trigger": false },
{ "query": "Plan launch day for our open-source release", "should_trigger": false },
{ "query": "Where should we list our package after launch to keep adoption growing?", "should_trigger": false },
{ "query": "What should I post every week while building in public?", "should_trigger": false },
{ "query": "Rebuild my GitHub profile README and pick my six pinned repos", "should_trigger": false },
{ "query": "Which conferences should we sponsor and at what tier?", "should_trigger": false },
{ "query": "Start a monthly Rust meetup in Lyon", "should_trigger": false },
{ "query": "Should we launch a Discord or a forum for our users?", "should_trigger": false },
{ "query": "Measure whether our three-year-old community is healthy", "should_trigger": false },
{ "query": "Design an ambassador program with perks, obligations and fixed terms", "should_trigger": false },
{ "query": "Turn this customer's production deployment into a technical case study", "should_trigger": false },
{ "query": "Pitch this launch to reporters under embargo", "should_trigger": false },
{ "query": "Write the engineering EVP for our careers page", "should_trigger": false },
{ "query": "Score my portfolio before I apply for developer advocate roles", "should_trigger": false },
{ "query": "Write the job posting and scorecard for a developer advocate role", "should_trigger": false },
{ "query": "Build me a watch list of devrel podcasts and newsletters", "should_trigger": false },
{ "query": "Design our company's open-source sponsorship portfolio and allocation model", "should_trigger": false },
{ "query": "Write our DevRel program charter: driver, goals, pillar mix, refused list", "should_trigger": false },
{ "query": "Onboard me onto this codebase", "should_trigger": false },
{ "query": "Improve our product's in-app user onboarding flow", "should_trigger": false },
{ "query": "Optimize our signup onboarding for conversion rate", "should_trigger": false },
{ "query": "Set up lead routing rules in our CRM", "should_trigger": false },
{ "query": "Configure routing in our Next.js app router", "should_trigger": false },
{ "query": "Fix the router config in our TanStack Router setup", "should_trigger": false },
{ "query": "Write a press release for our Series B", "should_trigger": false },
{ "query": "Kick off a new sprint with the engineering team", "should_trigger": false },
{ "query": "Write a project kickoff meeting agenda for our platform migration", "should_trigger": false },
{ "query": "Rewrite the error messages in our product so they're more actionable", "should_trigger": false },
{ "query": "Debug this production outage in our ingestion pipeline", "should_trigger": false },
{ "query": "Have our lawyer review the CLA we drafted", "should_trigger": false },
{ "query": "Design the slides for my conference talk", "should_trigger": false },
{ "query": "Edit the video footage from our last conference talk", "should_trigger": false },
{ "query": "Triage this one specific GitHub issue for me", "should_trigger": false },
{ "query": "Write the lesson content for module three of our academy course", "should_trigger": false },
{ "query": "Review our Terraform modules for security issues", "should_trigger": false },
{ "query": "Set up our CI pipeline to publish docs on merge", "should_trigger": false },
{ "query": "Write an SEO content brief for our marketing blog about project management", "should_trigger": false },
{ "query": "Plan a webinar for our sales team's prospects", "should_trigger": false },
{ "query": "Summarize the last 50 commits in this repo", "should_trigger": false }
]
}
references/context-artifact.md›
# Context artifact
`devrel-context.md` lives at the project root and is committed with the project when the project lives in git. One file, versioned, readable by teammates. It is what makes the next session a warm start.
## Template
```markdown
# DevRel context
_Last updated: YYYY-MM-DD_
## Product and audience
- Product: what it is, and what a developer does with it.
- Adoption motion: individual self-serve / organization buys / both / non-commercial OSS.
- Primary segment, secondary segment, anti-segment (from `samber/developer-relations-skills@developer-segmentation` if it has run).
## Program
- Funded driver: adoption / sales enablement / enablement / product input / ecosystem / contributor community / employer brand.
- Pillar mix: advocacy, marketing, enablement, community - with rough weight each.
- Stage and team: who does this work and for how many hours a week.
## Surfaces owned
- Docs: URL, generator, who can merge.
- Repositories: which ones are public and who maintains them.
- Community: venue and rough size.
- Events: what is committed this year.
- Content: where it publishes and who reviews it.
## Measurement
- Metrics currently reported, and where each number comes from.
- Known blind spots.
## State
- In flight: work started and not finished.
- Decided: settled calls, not to be re-litigated.
- Open: live questions.
- Constraints: budget, hours, review bottlenecks, legal or security gates.
## Stakeholders
- Name or role - decision rights on what.
## Session log
- YYYY-MM-DD - session goal → skill routed to → what changed here.
```
## Worked example (excerpt)
```markdown
## Product and audience
- Product: an open-source Go library for typed job queues; a hosted control plane is planned but unbuilt.
- Adoption motion: individual self-serve today; the hosted plane will introduce an organization buyer.
- Primary segment: backend engineers at 10-200 person product companies already running Postgres.
Anti-segment: data engineers looking for a workflow orchestrator - written off deliberately.
## Program
- Funded driver: contributor community, with adoption second. No revenue attached yet.
- Pillar mix: community 50%, enablement 30%, advocacy 20%, marketing 0%.
- Stage and team: one maintainer, roughly six hours a week, no budget.
## State
- In flight: CONTRIBUTING rewrite started 2026-08-14, good-first-issue queue still empty.
- Decided: Apache-2.0, DCO not CLA, no Discord before 500 stars.
- Open: whether v1 ships before or after the hosted plane.
- Constraints: maintainer hours only; no engineering support for docs.
## Session log
- 2026-08-21 - "nobody contributes" → `samber/developer-relations-skills@oss-contributor-onboarding` → added constraints, decided DCO.
```
## Negative example - what not to write
```markdown
## Program
- Goals: grow the community, increase adoption, improve docs, more content, better metrics,
build a brand, get to 10k stars, launch a Discord, speak at more conferences.
- Constraints: we should be careful with time.
- Decided: TBD
```
- Every goal is claimed, so none is prioritized and every activity scores identically.
- The constraint is unfalsifiable, so no skill can plan against it.
- `TBD` in a decided field means the next session re-asks a question that was probably already answered out loud.
Write the number of hours, name the one driver, and leave a field out entirely rather than filling it with a placeholder.
references/routines.md›
# Routines
Propose 2 to 4 routines, never more. Each one costs the user attention every time it fires, so it has to earn its slot against the one routine that actually matters.
## Dry-run format
Show every proposed routine in this shape and get approval before creating anything:
```
Routine: pre-release docs pass
Trigger: on push of a tag matching v* (fallback: Thursdays 09:00, the usual release day)
Runs: samber/developer-relations-skills@changelog-writing
Output channel: a draft pull request on the release branch
Cost: one review pass per release
First fire: 2026-09-04
```
A routine with no output channel is noise the user silences within a week. If you cannot name where the result lands, drop the routine.
## Anchoring to the DevRel calendar
Prefer a real date the project already has over an arbitrary schedule:
- Release train dates → release notes, migration guides, docs freshness.
- CFP deadlines → proposal drafting, typically weeks before the deadline, not on it.
- Conference dates → talk outline, demo rehearsal, follow-up content window after the event.
- Quarter start → content calendar, budget review.
- Community rituals (meetup nights, office hours) → promotion before, artifacts after.
- Budget or board review dates → metrics read.
Two lead times are systematically underestimated: reviews by people who do not report to the owner, and anything requiring working code. Set the trigger earlier than feels necessary for both.
## Event triggers beat schedules
Where the harness can react to events, use them:
- A tag push.
- A merged pull request touching `docs/`.
- A new issue with a given label.
- A release published.
An event trigger fires exactly when the work exists. A schedule fires whether or not it does, which is how routines lose credibility.
Keep a schedule for anything with no natural event: the quarterly kickoff re-invocation, the monthly metrics read.
## Cleanup
Before adding routines, list the ones already installed and retire what no longer applies:
- Routines tied to a conference that already happened.
- Routines tied to a launch that shipped.
- Routines whose target skill was renamed or removed from the collection.
- Routines that have fired more than three times without producing an action.
Retire them explicitly and say so; a silently abandoned routine keeps consuming attention.
## Kickoff re-invocation
Always include one: a monthly or quarterly re-run of the kickoff itself. It resummarizes state from the artifact and re-routes, which is what keeps the artifact from going stale between projects. If the harness has no scheduled routines at all, fall back to a single recurring calendar reminder and stop there - do not simulate scheduling with reminders inside the artifact.
references/skill-routing.md›
# Skill routing reference
Read this before routing any task that could plausibly match two skills. Every disambiguation below comes from the siblings' own declared scopes, not from inference.
## Table of Contents
- [Boundary forks](#boundary-forks)
- [Do-not-route signals](#do-not-route-signals)
- [Host auto-selection](#host-auto-selection)
- [Ordered chains](#ordered-chains)
- [Coverage gaps](#coverage-gaps)
- [Sibling-collection recommendations](#sibling-collection-recommendations)
## Boundary forks
### Docs authoring - five skills, five jobs
Ask what the reader is trying to do, not what the page will be called.
| Reader's state | Route to | Never route to |
| ---------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------ |
| Has never run the thing; needs one verified success fast | `samber/developer-relations-skills@developer-quickstart-guide` | `samber/developer-relations-skills@developer-tutorial` |
| Wants to learn a concept by building something | `samber/developer-relations-skills@developer-tutorial` | `samber/developer-relations-skills@developer-quickstart-guide` |
| Already competent; needs one specific task done | `samber/developer-relations-skills@developer-how-to-guide` | `samber/developer-relations-skills@developer-tutorial` |
| Landed on the repository and is deciding whether to bother | `samber/developer-relations-skills@readme-optimization` | `samber/developer-relations-skills@developer-quickstart-guide` |
| Pasted an error string into a search box | `samber/developer-relations-skills@developer-troubleshooting-docs` | `samber/developer-relations-skills@developer-docs-structure-audit` |
| A coding agent, not a human, reading unattended | `samber/developer-relations-skills@coding-agent-docs-optimization` | `samber/developer-relations-skills@developer-docs-structure-audit` |
Conflating a tutorial with a how-to guide fails both readers: the learner gets an unexplained recipe, the working developer gets a lecture. Route a how-to guide to `samber/developer-relations-skills@developer-how-to-guide`, never to the nearest neighbour. A breaking-change upgrade is a how-to with its own ordering rules and stays with `samber/developer-relations-skills@version-migration-guide`.
`samber/developer-relations-skills@developer-docs-structure-audit` operates on the whole docs set, never on one page. When the user asks "where should this page live", that is a structure question. When they ask "how do I write this page", route by reader state above.
`samber/developer-relations-skills@docs-code-sample-standards` owns the policy every sample obeys and the audit of an existing corpus. A single snippet inside one page being written belongs to whichever authoring skill owns that page. The portfolio of sample repos itself - which exist, who owns them, when they retire - belongs to `samber/developer-platform-skills@sample-app-strategy`.
`samber/developer-relations-skills@docs-localization-strategy` decides whether a language gets translated docs, which pages, and how translations stay current. Translating one file on request needs no skill. hreflang, canonicals and indexing of translated pages stay with `samber/developer-relations-skills@docs-seo`.
`samber/developer-relations-skills@docs-versioning-strategy` decides which versions keep docs and in what state, whether to run a version switcher, latest-only docs, per-major archives or version badges, how doc fixes get backported, which banners old pages carry, and when a docs version retires. The supported-versions table it maps from belongs to `samber/developer-relations-skills@oss-release-policy`. Canonical, noindex, sitemap and redirect mechanics for the version tree, including old docs outranking current, stay with `samber/developer-relations-skills@docs-seo`. Old-version AI answers stay with `samber/developer-relations-skills@developer-docs-ai-visibility`. The upgrade guide itself stays with `samber/developer-relations-skills@version-migration-guide`.
`samber/developer-relations-skills@developer-keyword-research` decides which pages to write from what developers actually search - error strings, task queries, integration intents - and never writes them. On-page and docs-site SEO stays with `samber/developer-relations-skills@docs-seo`.
`samber/developer-relations-skills@developer-docs-ai-visibility` owns how AI assistants and AI search cite the docs: which pipeline (training recall, search retrieval, live fetch) produced a wrong or old-version answer, the version signals and corrections that fix it, and a repeated prompt panel measuring version-correct answers. Crawl policy, canonicals and version-tree posture stay with `samber/developer-relations-skills@docs-seo`; machine-readable surfaces and unattended agent integration stay with `samber/developer-relations-skills@coding-agent-docs-optimization`; referral channel setup stays with `samber/developer-relations-skills@devrel-analytics`.
### Release communication - changelog vs migration guide
- `samber/developer-relations-skills@changelog-writing` - one release, everything that shipped, one line of action per breaking entry.
- `samber/developer-relations-skills@version-migration-guide` - one breaking change set, blast-radius ordering, before/after code, deprecation timeline, verified by upgrading a real project.
A major version usually needs both, in that order. A patch release needs only the first. Neither owns the versioning policy itself. A project's release contract - scheme, breaking-change definition, supported versions, backports, cadence, deprecation windows - belongs to `samber/developer-relations-skills@oss-release-policy`, written once and applied by both. A hosted API's version scheme belongs to `samber/developer-platform-skills@api-versioning-policy`.
### Security reports - the routing entry vs the pipeline
- `samber/developer-relations-skills@oss-issue-triage` - keeps security reports out of the public tracker: the chooser entry and the rule that a misfiled report is an emergency.
- `samber/developer-relations-skills@oss-security-disclosure` - everything behind that entry: SECURITY.md, private reporting, triage and scoring, embargo, CVE and advisory, patched release, downstream notice.
A security fix release still gets its notes from `samber/developer-relations-skills@changelog-writing`, after the advisory is public. Which lines receive the fix comes from the supported-versions table `samber/developer-relations-skills@oss-release-policy` writes. Shipping the patched package to its registry belongs to `samber/developer-platform-skills@sdk-package-publishing`.
### Measurement - four skills, four layers
- `samber/developer-relations-skills@devrel-metrics` - which numbers deserve a target, the attribution rule, and what gets cut. The framework layer.
- `samber/developer-relations-skills@devrel-analytics` - how those numbers get collected: event taxonomy, identity spine, link tagging, surface register. The instrumentation layer.
- `samber/developer-relations-skills@developer-community-health` - the community venue only: activity, responsiveness, contributor funnel, sentiment.
- `samber/developer-relations-skills@developer-survey-design` - asking developers directly: a recurring survey, its sample, its privacy handling, and what its published percentages may claim.
- "Our numbers disagree between tools" routes to `samber/developer-relations-skills@devrel-analytics`.
- "Leadership isn't convinced" routes to `samber/developer-relations-skills@devrel-metrics`.
- "Is our Discord dying" routes to `samber/developer-relations-skills@developer-community-health`.
- "We want to run a State of X survey and publish the numbers" routes to `samber/developer-relations-skills@developer-survey-design`; community-health supplies the sentiment items if the survey carries them.
- "Feature requests pile up in Discord and product never sees them" routes to `samber/developer-relations-skills@developer-feedback-loop` - it carries requests to a product decision and back; community health only measures the venue.
- Feature requests filed as code-host issues split in two: labels, response targets and staleness stay with `samber/developer-relations-skills@oss-issue-triage`; the product decision and the public reply go to `samber/developer-relations-skills@developer-feedback-loop`. Publishing the roadmap those decisions feed belongs to `samber/developer-platform-skills@public-roadmap-strategy`.
- "We lose developers somewhere between trial and production" routes to `samber/developer-relations-skills@developer-journey-map` - it names the leaking stage; `samber/developer-relations-skills@devrel-metrics` sets targets once the leak is known.
- "How do we compare to a competitor" routes to `samber/developer-relations-skills@devrel-competitor-analysis` - it looks outward; the other four look inward.
### Open source visibility - launch, distribution, transparency
- `samber/developer-relations-skills@oss-launch` - the launch window itself: readiness gate, positioning, channel sequencing, run of show, trending mechanics.
- `samber/developer-relations-skills@oss-distribution-strategy` - everything after that window: registry presence, curated lists, downstream packaging, release cadence as a visibility beat.
- `samber/developer-relations-skills@build-in-public` - the ongoing personal or company transparency practice, independent of any launch.
"Adoption flattened after launch" is distribution, not a second launch. "What should I post every week" is build-in-public. `samber/developer-relations-skills@tech-press-relations` handles journalists and embargoes for any of the three; it never owns the announcement post itself.
### Maintainer load - the person vs the project
- `samber/developer-relations-skills@oss-maintainer-sustainability` - the maintainer's own capacity: time budget, published limits, maintenance-only mode, recruiting help, stepping down, handover or archive.
- `samber/developer-relations-skills@oss-governance` - the project's rules: decision rights, trust ladder, credential inventory, emeritus.
- `samber/developer-relations-skills@oss-issue-triage` - the queue's system: labels, response targets, staleness policy.
"I'm burned out and want to stop" routes to maintainer sustainability, which hands the ladder to governance and the queue design to triage. "We need a GOVERNANCE.md" never routes there. "I want to earn a living from it" routes to `samber/developer-relations-skills@oss-monetization`, unless the honest goal is fewer hours, which stays with maintainer sustainability.
### Sponsorship - who is paying whom
- `samber/developer-relations-skills@oss-monetization` - the maintainers of one project choose what to sell: paid add-on, support, content, hosting or a license move.
- `samber/developer-relations-skills@oss-sponsors-fundraising` - the maintainer wants sponsorship or grant money in.
- `samber/developer-relations-skills@oss-sponsors-brand-strategy` - the company decides which projects to fund.
- `samber/developer-relations-skills@developer-event-sponsorship` - the company buys conference, meetup or hackathon sponsorship.
Read the question's subject. "Which tier should we pick on this maintainer's page" is the company side, not the maintainer side. "Should I sell a Pro version" is monetization, not sponsorship; "set up GitHub Sponsors tiers" is sponsorship.
### Community - four skills on one timeline
1. `samber/developer-relations-skills@developer-community-launch` - before anything exists: should it exist, where, seeded how, and when to fold it back.
2. `samber/developer-relations-skills@developer-community-moderation` - the rules and the enforcement machinery, written before the first incident.
3. `samber/developer-relations-skills@developer-community-health` - measurement, once there is enough activity to have a baseline.
4. `samber/developer-relations-skills@developer-champions` - recognition and obligations for the top members, once a reliable top exists.
Recurring question sessions sit beside this timeline, not on it: `samber/developer-relations-skills@developer-office-hours-program` designs office hours or a standing AMA at any stage - format, time-zone slot, engineer rotation, scope card, write-up loop. "Our office hours get three people" routes there, not to community health; the requests those sessions surface route on to `samber/developer-relations-skills@developer-feedback-loop`.
A community that has not run 90 days has no health baseline; route measurement asks there to "not now" with that unblocking condition. `samber/developer-relations-skills@oss-contributor-onboarding` is the code-contribution equivalent of a community funnel and belongs to the open-source block, not here.
### Strategy - five skills that all sound like "what should we do"
- `samber/developer-relations-skills@devrel-strategy` - the DevRel program's own charter: driver, goals, pillars, staffing sequence, refused list.
- `samber/developer-relations-skills@devrel-team-structure` - where DevRel reports and how the team is shaped. Org design only.
- `samber/developer-relations-skills@devrel-budget-allocation` - the money split across pillars, with thresholds and a cut list.
- `samber/developer-relations-skills@developer-first-gtm` - how developer adoption becomes revenue. A company-level motion, not a DevRel charter.
- `samber/developer-relations-skills@devtools-business-model` - what is sold and how it makes money at all.
Chain them rather than choosing between them when the user is genuinely at zero: model → GTM → strategy → team → budget.
Three related, narrower skills: `samber/developer-relations-skills@devtools-pricing-strategy` sets the value metric and price points inside the business model; `samber/developer-relations-skills@open-source-company-strategy` decides which assets stay open; `samber/developer-relations-skills@oss-license-strategy` picks the license text for one project.
`samber/developer-relations-skills@oss-monetization` is the maintainer-scale counterpart of `devtools-business-model`: one project, its own maintainers, no outside funding, with hours and contributor trust as constraints. A funded company choosing its revenue model stays with `devtools-business-model`.
Two more sound like strategy and are not interchangeable with the five above:
- `samber/developer-relations-skills@developer-ecosystem-strategy` - whether and how far the product opens into a platform others build on. The revenue model stays with `samber/developer-relations-skills@devtools-business-model`; running the marketplace belongs to `samber/developer-platform-skills@connector-marketplace-strategy`.
- `samber/developer-relations-skills@open-standards-strategy` - how to engage one named standard or protocol: ignore, consume, certify, extend, contribute, co-found or drive. Governing your own project stays with `samber/developer-relations-skills@oss-governance`.
### Speaking and media - sequence, not competition
`samber/developer-relations-skills@conference-cfp-submission` (get accepted) → `samber/developer-relations-skills@tech-talk-outline` (structure the talk) → `samber/developer-relations-skills@developer-live-demo-design` (make the demo survive). None of them writes slides or coaches delivery.
- `samber/developer-relations-skills@tech-podcast-interview-prep` is for being someone else's guest.
- `samber/developer-relations-skills@technical-video-script` is for your own recorded video.
- `samber/developer-relations-skills@engineering-blog-post` is the written form.
- `samber/developer-relations-skills@developer-case-study` is the customer's story rather than yours.
- `samber/developer-relations-skills@devrel-content-calendar` plans the quarter these pieces land in and never writes them.
- `samber/developer-relations-skills@devrel-newsletter-program` designs a standing newsletter as a programme - whether to run one, cadence, template, owner, sunset - and never writes an issue. Release notes stay with `samber/developer-relations-skills@changelog-writing`; the quarter's slot plan stays with the calendar.
### Events - speak, sponsor, or run it yourself
- `samber/developer-relations-skills@conference-cfp-submission`, `samber/developer-relations-skills@tech-talk-outline`, `samber/developer-relations-skills@developer-live-demo-design` - you are on someone else's stage.
- `samber/developer-relations-skills@developer-event-sponsorship` - you are paying to appear at someone else's event.
- `samber/developer-relations-skills@developer-meetup-program` - you run a small recurring local group yourself: format, cadence, speaker pipeline, venue sponsor, health.
- `samber/developer-relations-skills@devrel-webinar-program` - you run a recurring online technical webinar series yourself: format mix, seasons, topic backlog, speakers, replay, and the lead-handoff contract with sales. A Q&A-only series goes to the office-hours skill instead; platform, streaming and moderation mechanics go to `samber/dev-event-organizer-skills@virtual-event-production`.
Ask who owns the event before routing. A conference or hackathon you organize is not `samber/developer-relations-skills@developer-meetup-program` - that is organizer work and belongs to `samber/dev-event-organizer-skills` (see below).
### Employer brand - the strategy, the surfaces, the other side of the table
- `samber/developer-relations-skills@tech-employer-branding` - why engineers should want to work here, and which channels carry that claim: the EVP, the verification-surface audit, the ranked channel bets, the hiring measurement baseline. Strategy altitude; it produces no artefact.
- `samber/developer-relations-skills@engineering-blog-post` - one post the plan commissions.
- `samber/developer-relations-skills@github-profile-optimization` - the code-host profile the plan audits as one verification surface.
- `samber/developer-relations-skills@devrel-career` - the candidate reading those same surfaces from the other side of the table.
Ask who is hiring whom.
- "How do we attract senior engineers" is the strategy skill.
- "Write the post" and "fix the profile" are the execution skills - and a plan that skips straight to them has no EVP behind it.
- Hiring for DevRel roles specifically - role definitions, job postings, interview loops, scorecards - is none of the four; route to `samber/developer-relations-skills@devrel-hiring`.
### Profile surfaces
`samber/developer-relations-skills@readme-optimization` owns one repository's README. `samber/developer-relations-skills@github-profile-optimization` owns the personal or organization profile page and which repositories get pinned. When both are in play, fix the pinned repositories' READMEs first - the profile sends traffic into them. The repository's GitHub surfaces beyond the page - Discussions, release notifications, topics, star policy - belong to `samber/developer-platform-skills@github-engagement-playbook`.
### Education - the program vs the credential
`samber/developer-relations-skills@developer-education-strategy` decides whether to invest in structured education and which rung - curated path, curriculum with labs, badge, certification. `samber/developer-relations-skills@developer-certification-program` designs the credential once one is on the table, mostly for freelancers and IT services firms selling consulting: the outside consumer gate, tier, exam format, proctoring and identity, renewal tied to product versions, fees, verification, the expert directory, revocation and retirement, plus the prep course hosted on a MOOC or edtech platform and the training and exam-delivery partners. A prep course for one credential stays here; a curriculum or academy beyond it is education strategy. Run education strategy first when no curriculum exists yet; go straight to the certification skill when the ask is about an exam, a badge or its renewal.
## Do-not-route signals
- Debugging a live production incident → not `samber/developer-relations-skills@developer-troubleshooting-docs`; that skill writes the page afterwards.
- Reviewing the product's own source code or error strings → outside the collection.
- Triaging one specific issue → not `samber/developer-relations-skills@oss-issue-triage`; that skill designs the system.
- Tracking a rival vendor's DevRel motion → not `samber/developer-relations-skills@devrel-radar`, which builds a personal watch list of sources; route to `samber/developer-relations-skills@devrel-competitor-analysis`.
- Reporting a vulnerability in someone else's project, or patching CVEs in the user's own dependencies → not `samber/developer-relations-skills@oss-security-disclosure`, which is maintainer-side only; outside the collection.
- Configuring the user's own Dependabot or Renovate, or pinning someone else's package → not `samber/developer-relations-skills@oss-release-policy`, which writes the maintainer's contract; outside the collection.
- Legal sign-off on a license, CLA, trademark or contract → every relevant skill is a decision framework and says so.
- Recruiting or interviewing DevRel staff → route to `samber/developer-relations-skills@devrel-hiring`, not `samber/developer-relations-skills@devrel-career` (candidate side only) or `samber/developer-relations-skills@tech-employer-branding` (engineering employer brand, not a role's interview loop).
- Writing courses or lesson content → `samber/developer-relations-skills@developer-education-strategy` stops at the operating model.
- Writing exam items, running exam delivery, or preparing as a candidate for someone else's exam → not `samber/developer-relations-skills@developer-certification-program`, which designs the issuer's program; outside the collection.
- Certifying a partner's app or connector rather than a person → not `samber/developer-relations-skills@developer-certification-program`; recommend `samber/developer-platform-skills@app-marketplace-review`.
- Building the slides, editing the video, running the camera → outside the collection.
- Product-user onboarding (in-app) → not `samber/developer-relations-skills@oss-contributor-onboarding`, which is about code contribution.
- Brand or marketing-page share in AI answers, or the docs site's own AI assistant → not `samber/developer-relations-skills@developer-docs-ai-visibility`, which covers third-party assistants citing the docs; outside the collection.
## Host auto-selection
Some harnesses select a skill by matching the request against every installed skill's `description`, before this kickoff runs - triggering a sibling directly, or the kickoff and a sibling together.
- A sibling triggered directly, without the kickoff, is not a bypass to correct: each sibling's `description` triggers standalone, and the kickoff exists for ambiguous or multi-skill requests only.
- When both fire on the same request, treat the kickoff's decision as confirming what the harness already started, never a second dispatch that re-runs or contradicts a sibling in progress.
Pattern from `penpot/penpot-ai-kit@penpot-router`: a router degrading to a confirmation role once a host has already auto-selected by description.
## Ordered chains
Offer a chain only when the task genuinely decomposes. Every chain below is in dependency order, not efficiency order: a later link consumes what the earlier one produces and cannot run before it, so ranking a chain adds nothing. Common ones:
- **First DevRel hire, nothing exists:** `samber/developer-relations-skills@developer-segmentation` → `samber/developer-relations-skills@devrel-strategy` → `samber/developer-relations-skills@devrel-metrics` → `samber/developer-relations-skills@devrel-content-calendar`.
- **Open-sourcing a project:** `samber/developer-relations-skills@oss-license-strategy` → `samber/developer-relations-skills@readme-optimization` → `samber/developer-relations-skills@oss-contributor-onboarding` → `samber/developer-relations-skills@oss-launch` → `samber/developer-relations-skills@oss-distribution-strategy`.
- **Docs overhaul:** `samber/developer-relations-skills@developer-docs-structure-audit` → `samber/developer-relations-skills@developer-quickstart-guide` → `samber/developer-relations-skills@developer-how-to-guide` → `samber/developer-relations-skills@docs-code-sample-standards` → `samber/developer-relations-skills@docs-seo`.
- **Major version release:** `samber/developer-relations-skills@version-migration-guide` → `samber/developer-relations-skills@changelog-writing` → `samber/developer-relations-skills@engineering-blog-post`.
- **Conference season:** `samber/developer-relations-skills@conference-cfp-submission` → `samber/developer-relations-skills@tech-talk-outline` → `samber/developer-relations-skills@developer-live-demo-design`.
- **Community from zero:** `samber/developer-relations-skills@developer-community-launch` → `samber/developer-relations-skills@developer-community-moderation` → `samber/developer-relations-skills@developer-community-health` → `samber/developer-relations-skills@developer-champions`.
- **Proving the program:** `samber/developer-relations-skills@devrel-metrics` → `samber/developer-relations-skills@devrel-analytics` → `samber/developer-relations-skills@devrel-budget-allocation`.
- **Maintainer sustainability money:** `samber/developer-relations-skills@oss-sponsors-fundraising` → `samber/developer-relations-skills@build-in-public`.
Each link hands the next one a named artifact. If you cannot say what gets handed over, there is no chain - route to one skill instead.
## Coverage gaps
State these plainly as gaps. Do not route to a neighbour.
- The exec-facing DevRel report narrative and budget defense.
- A trademark _usage and enforcement_ policy aimed at third parties. Who holds the mark, the domains and the registry accounts belongs to `samber/developer-relations-skills@oss-governance`; clearing a name before launch belongs to `samber/developer-relations-skills@oss-launch`; registering it before selling belongs to `samber/developer-relations-skills@oss-monetization`. Monetizing one open-source project is _not_ a gap - `samber/developer-relations-skills@oss-monetization` owns it - nor are maintainer burnout (`samber/developer-relations-skills@oss-maintainer-sustainability`) or succession and bus-factor planning (`samber/developer-relations-skills@oss-governance`: contributor absence factor, trust ladder, inactivity rule, emeritus).
- Organizing your own conference or hackathon, conference booth operations, post-event follow-up.
- Student and campus programs. A developer newsletter is _not_ a gap at programme level - `samber/developer-relations-skills@devrel-newsletter-program` owns it; writing an issue, list growth, inbox placement and selling sponsor slots remain gaps.
- Choosing a docs platform, and monitoring brand mentions across developer channels or brand share in AI answers. Docs cited at the right version in AI answers is _not_ a gap - `samber/developer-relations-skills@developer-docs-ai-visibility` owns it.
- Producing any final asset: slides, video files, rendered graphics, published pages.
- Legal advice of any kind.
## Sibling-collection recommendations
Same owner, separate collections. Recommend installing one; never depend on it.
| Signal in the task | Belongs to |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------- |
| Public API surface design, versioning policy, error shape, rate limits, idempotency | `samber/developer-platform-skills` |
| Endpoint-level reference completeness, undocumented operations, spec-to-docs drift | `samber/developer-platform-skills@api-reference-quality` |
| A hosted API's version scheme, breaking-change definition, deprecation notice windows, sunset signalling | `samber/developer-platform-skills@api-versioning-policy` |
| Webhooks, sandbox and test mode, integration observability, API status communication | `samber/developer-platform-skills` |
| SDK portfolio decisions, developer portal design, OAuth for third-party apps | `samber/developer-platform-skills` |
| Building your own connector marketplace, app review, listing standards, marketplace economics | `samber/developer-platform-skills` |
| Which sample repos, reference apps and templates exist, who owns them, when they retire | `samber/developer-platform-skills@sample-app-strategy` |
| Publishing SDK packages or CLI binaries (npm, PyPI, Maven, NuGet, Go, crates.io, pub.dev, RubyGems, Packagist, Hex, SwiftPM, CocoaPods, Homebrew, winget, Scoop), CI auto-publishing, trusted publishing, rolling back a bad version | `samber/developer-platform-skills@sdk-package-publishing` |
| The public CLI wrapping the API: commands, `--json` and exit codes, CLI login, agent-safe use | `samber/developer-platform-skills@cli-interface-design` |
| Shipping an Agent Skill (SKILL.md) inside an SDK or CLI repo, versioned with each release | `samber/developer-platform-skills@agent-skill-offering` |
| Building, adopting or publishing the product's own Terraform/OpenTofu provider | `samber/developer-platform-skills@terraform-provider-offering` |
| Whether to ship an official VS Code or JetBrains extension, Open VSX and marketplace publishing, extension telemetry and deprecation | `samber/developer-platform-skills@ide-extension-offering` |
| Whether and how to publish the roadmap, commitment wording, voting boards | `samber/developer-platform-skills@public-roadmap-strategy` |
| Flat GitHub stars after launch, Discussions, release notifications, topics, star-buying asks | `samber/developer-platform-skills@github-engagement-playbook` |
| A vendor's product tag on Stack Overflow, staff answering, self-promotion flags, unanswered backlog | `samber/developer-platform-skills@stackoverflow-playbook` |
| Your product's own Zapier integration: triggers, Platform CLI code, app-directory review and beta, Zap templates, partner tier, versions | `samber/developer-platform-skills@zapier-integration-playbook` |
| Organizing your own conference, meetup logistics at production scale, hackathon operations | `samber/dev-event-organizer-skills` |
| Selling sponsorship as the organizer, prospectus, pricing, fulfillment | `samber/dev-event-organizer-skills` |
| Running a CFP as the organizer, talk selection, speaker sourcing, hospitality and coaching | `samber/dev-event-organizer-skills` |
| Venue, ticketing, schedule design, run of show, attendee experience | `samber/dev-event-organizer-skills` |
| Registration forecast, headcount for catering or hotel block, when registration hits its cap | `samber/dev-event-organizer-skills@event-registration-forecast` |
| Virtual event platform, remote-speaker setup, live chat and Q&A moderation staffing | `samber/dev-event-organizer-skills@virtual-event-production` |
The line for events runs through who is paying: this collection covers the speaker and the sponsor; the event collection covers the organizer. The line for platforms runs through who builds the surface: this collection covers documenting and evangelizing it; the platform collection covers designing it.
Say it as a recommendation: "This is organizer-side work - `samber/dev-event-organizer-skills` covers it; this collection stops at the sponsor and speaker side." Then stop. Do not improvise the sibling's advice.
SKILL.md›
---
name: developer-relations-kickoff
description: Before starting any developer-relations work - and again at the start of each new session on an existing DevRel project - routes the current task to the right skill of the samber/developer-relations-skills collection, or says plainly that none fits, then bootstraps or resumes the project's shared devrel-context.md artifact. Covers documentation, open source, community, events, technical content, program strategy, devtools business strategy, employer brand and measurement; the output is a routing short-list plus an ordered skill chain. Run it at every project start even when the collection's skills are already in daily use elsewhere, at each periodic DevRel check-in, and whenever routing is unclear - a devrel kickoff, a new developer-relations project, "which devrel skill do I need", devrel, docs or open-source skill routing, or a recurring developer-program review - even if the user only describes a devrel problem and never asks which skill to use.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.14"
---
# Developer Relations Kickoff
You are the router for the 64-skill developer-relations-skills collection. Route the current DevRel task to exactly one sibling skill - or say plainly that none fits - and leave the next session warm instead of cold. Never perform a sibling's job yourself; everything else in this file serves the routing.
Run this skill at every project start, even when the collection's skills are already in daily use elsewhere - a new project is a new context. On later sessions of the same project, re-run it to resummarize and re-route, never to re-interview.
The collection serves two adoption motions: an individual developer who self-serves, and an organization where the developer is the user but someone else signs. Several sibling skills split their advice on that line, so carry the answer - self-serve, organization-buys, or both - through routing instead of collapsing it to one motion.
## 1. Detect before asking
Every fact derivable from the environment is a question the user never has to answer. Run detection first; the interview cap only survives if it does.
**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. Decide cold vs warm start from one signal only: does `devrel-context.md` exist in the project? Present → warm. Absent → cold. Never ask the user which mode it is.
2. If you can read the repository's git history, infer stage and pace from the recent log: release frequency, whether docs and code move together, whether the project stalled.
3. Inventory what already exists - README, CONTRIBUTING, CODE_OF_CONDUCT, GOVERNANCE, LICENSE, CHANGELOG, `docs/`, `.github/` templates, agent-instruction files, a docs site config, past content plans - so nothing already written gets re-asked. Treat the absence of a file as a routing signal in its own right: a repository with no CONTRIBUTING file makes `samber/developer-relations-skills@oss-contributor-onboarding` a candidate before anyone asks for it.
4. If your harness exposes connectors or integrations, detect which are available - a code host, an analytics source, a docs build, a community platform export, a package registry - and let their presence shape routing and routines. Describe the capability; never assume a specific product.
5. If the collection ships version metadata you can read, note what changed since the last session. If it doesn't - the common case - degrade silently. Never block, warn, or ask about versions.
## 2. Interview - capped
On a cold start, ask at most 5-7 questions, one per message, multiple-choice whenever possible. Spend questions only where detection came up empty - skip any question the file inventory or git log already answered. **Use an interactive question mechanism (e.g. `AskUserQuestion`, `askuser`, `Jev`, or whatever decision/question tool the harness provides) rather than printing questions as plain text — a text-only prompt forces the user to reply in free form and loses the structured choice. Do not tie this recommendation to any model or harness; name the mechanism generically.**
1. "Which surface is today's work on?" - (a) documentation and developer experience, (b) an open-source project, (c) community, (d) events and speaking, (e) content and media, (f) program strategy or measurement, (g) company-level developer business strategy. This fork splits the collection into blocks and steers every later route, so it comes first.
2. "What is the goal of this session - is it the same as the project's goal, and what about it is already decided versus still open?" Ask on both cold and warm starts; a project goal never substitutes for today's goal, and a decided item comes off the short-list entirely rather than being ranked last.
3. "Who adopts, and who pays?" - (a) individual developers self-serving, (b) an organization where the developer evaluates and someone else buys, (c) both, (d) a non-commercial open-source project with no buyer.
4. "Which business driver funds this work?" - (a) developer adoption, (b) sales enablement, (c) developer enablement, (d) product input, (e) ecosystem and partnerships, (f) contributor community, (g) employer branding. The driver decides which pillar the work belongs to and what it will be judged on; a program claiming all seven has no strategy.
5. "What stage is the program at?" - (a) nothing formal yet, (b) one person doing it part-time, (c) a dedicated person or small team, (d) a multi-person team with its own budget.
6. "Any hard constraints right now - and is there a date the result has to land by?" - (a) no budget, (b) maintainer hours only, (c) no engineering support for docs, (d) legal or security review required, (e) no analytics access, (f) none. Give the date when there is one: a release, a conference, a funding review.
7. "Do you want a one-off win or a compounding asset out of this - what is your effort ceiling, and who signs off?" - (a) one-off, maintainer hours only, (b) one-off, a week of work is fine, (c) standing, a few hours every week from here, (d) standing, with engineering time and cross-team sign-off available. Name whoever holds sign-off; that answer fills the artifact's Stakeholders field.
Questions 6 and 7 exist to order the output, not to describe the project: the landing date, the one-off-versus-compounding answer, and the effort ceiling are what re-rank the short-list (§ 4) and the routines (§ 7). Ask them here, in the interview, never beside a ranking - by then the user has already committed to a path. Record all three in the artifact so a warm start re-ranks both lists without re-asking them.
On a warm start, ask only the session-goal question. Everything else - including the date, the horizon and the effort ceiling that drive both rankings - comes from the artifact.
## 3. Route the task
Match the stated session goal against each skill's declared scope below. Route to exactly one skill for the immediate task. Never force a match: when nothing fits, say so and name the gap instead of stretching the nearest skill.
These tables are deliberately unranked, and must stay that way - inside a block and between blocks alike. Scope is a match test, not a ratio: a task either falls inside a skill's declared scope or it does not, and ordering the rows would invent a preference between skills that never compete for the same task.
`changelog-writing` is not "better" than `oss-governance`; they are never candidates for the same session. Ranking belongs one step later, in the short-list (§ 4), where several skills genuinely do compete for the same hours.
**Program strategy and measurement:**
| Skill | Route here when the task is… |
| ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `samber/developer-relations-skills@devrel-strategy` | Design the program from the top - situational analysis, funded driver, allowed goals, pillar mix, build-vs-buy, staffing sequence, refused list |
| `samber/developer-relations-skills@devrel-team-structure` | Org design - reporting line, team shape, coverage map, interlocks, re-org triggers |
| `samber/developer-relations-skills@devrel-budget-allocation` | Split the budget across pillars into line items with a return threshold and a cut list |
| `samber/developer-relations-skills@devrel-metrics` | Which KPIs deserve a target - tiered framework, attribution rule, baselines, vanity cuts |
| `samber/developer-relations-skills@devrel-analytics` | The tracking plan that instruments the surfaces - event taxonomy, identity spine, UTM discipline |
| `samber/developer-relations-skills@developer-survey-design` | A recurring developer or "State of" survey - question cuts, recruitment and calibration sample, privacy, defensible published percentages |
| `samber/developer-relations-skills@developer-journey-map` | Map the journey stage by stage - discover, try, adopt, contribute, advocate as a working spine, not a published framework - and locate the single leak worth fixing |
| `samber/developer-relations-skills@developer-segmentation` | Cut the developer audience into named, sized, ranked segments plus an anti-segment |
| `samber/developer-relations-skills@developer-education-strategy` | Whether and how to invest in structured education - academy, curriculum, labs, and which credential rung |
| `samber/developer-relations-skills@developer-certification-program` | Issuer side of a developer certification or badge program, mostly for freelancers and IT services firms who need clients to recognise them as experts - whether to issue one, tier, exam format, proctoring, renewal, fees, verification and expert directory, the prep course on a MOOC or edtech platform, training and exam-delivery partners, retirement |
| `samber/developer-relations-skills@devrel-competitor-analysis` | Benchmark a competitor's devrel motion from public signals into a close/ignore/counter plan |
| `samber/developer-relations-skills@tech-employer-branding` | Attract engineers to work here - engineering EVP, verification-surface audit, seniority-matched channel bets, hiring measurement baseline |
**Developer business strategy (company level):**
| Skill | Route here when the task is… |
| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `samber/developer-relations-skills@devtools-business-model` | How the tool makes money - nine model archetypes and the GTM each forces |
| `samber/developer-relations-skills@devtools-pricing-strategy` | Value metric, free-tier limits, tier ladder, price points, safe price changes |
| `samber/developer-relations-skills@developer-first-gtm` | The adoption-to-revenue motion - self-serve entry, developer-to-buyer handoff, land and expand |
| `samber/developer-relations-skills@open-source-company-strategy` | What the company open-sources and what stays proprietary, asset by asset, with the motive |
| `samber/developer-relations-skills@developer-ecosystem-strategy` | Whether and how far to open the product into a platform others build on |
| `samber/developer-relations-skills@open-standards-strategy` | How to engage a named standard or protocol - ignore, consume, certify, extend, contribute upstream, co-found a spec, drive your own - plus venue, patent mode and kill rule |
**Documentation and developer experience:**
| Skill | Route here when the task is… |
| ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- |
| `samber/developer-relations-skills@readme-optimization` | One repository's README - first impression, bail-fast funnel, badge pruning |
| `samber/developer-relations-skills@developer-quickstart-guide` | Zero to one verified success - minimal path, copy-paste commands, expected output |
| `samber/developer-relations-skills@developer-tutorial` | A teaching tutorial - one concept per step, checkpoints, a demonstrable skill at the end |
| `samber/developer-relations-skills@developer-how-to-guide` | A how-to guide - one real task for a competent reader, variants, guarded risky steps, verification |
| `samber/developer-relations-skills@developer-docs-structure-audit` | The docs set's information architecture - Diátaxis classification, misplacement, coverage gaps |
| `samber/developer-relations-skills@docs-code-sample-standards` | Sample policy and a corpus audit - runnability, testing, language parity, copy-paste safety |
| `samber/developer-relations-skills@developer-troubleshooting-docs` | Error-reference and troubleshooting pages built from tickets, issues and telemetry |
| `samber/developer-relations-skills@changelog-writing` | Release notes for one release, from commits and pull requests |
| `samber/developer-relations-skills@version-migration-guide` | The breaking-change migration guide - blast radius, detection signals, before/after, timeline |
| `samber/developer-relations-skills@coding-agent-docs-optimization` | Make docs machine-readable so a coding agent can integrate unattended |
| `samber/developer-relations-skills@docs-localization-strategy` | Whether and how to translate the docs - locale evidence, page set, drift pins, locale ownership |
| `samber/developer-relations-skills@docs-versioning-strategy` | How the docs track several versions - docs state per version, switcher or latest-only, backports, banners, retirement |
**Search demand for technical content:**
| Skill | Route here when the task is… |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| `samber/developer-relations-skills@developer-keyword-research` | What developers actually search - error strings, task queries, integration intents, demand sizing |
| `samber/developer-relations-skills@docs-seo` | On-page and technical SEO of a docs site - indexing, canonicals, templates, internal links |
| `samber/developer-relations-skills@developer-docs-ai-visibility` | Docs cited at the current version in AI assistant and AI search answers - pipeline diagnosis, prompt panel |
**Open source:**
| Skill | Route here when the task is… |
| --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| `samber/developer-relations-skills@oss-launch` | The launch window - readiness gate, positioning, channel sequencing, run of show |
| `samber/developer-relations-skills@oss-distribution-strategy` | Ongoing distribution after launch - registries, curated lists, packaging, release cadence |
| `samber/developer-relations-skills@build-in-public` | The recurring transparency practice - disclosure ladder, cadence, platform mix, boundaries |
| `samber/developer-relations-skills@oss-contributor-onboarding` | The stranger-to-first-merge path - CONTRIBUTING, good first issues, cold-runnable setup |
| `samber/developer-relations-skills@oss-issue-triage` | The triage system - queue measurement, labels, response targets, intake forms, staleness policy |
| `samber/developer-relations-skills@oss-security-disclosure` | A vulnerability report or disclosure deadline, SECURITY.md, private reporting, CVE and advisory, embargo, patched release, EU CRA reporting check |
| `samber/developer-relations-skills@oss-release-policy` | The release contract - SemVer vs CalVer vs 0.x, when to ship 1.0, breaking-change definition, supported versions and LTS, backports, cadence, deprecation, switching schemes |
| `samber/developer-relations-skills@oss-maintainer-sustainability` | The maintainer's own load - burnout, time budget, published limits, recruiting a co-maintainer, stepping down, handover or archive |
| `samber/developer-relations-skills@oss-governance` | Decision rights, maintainer roles, voting, conflict escalation, succession and bus-factor planning, trademark and asset control, foundation donation |
| `samber/developer-relations-skills@oss-license-strategy` | License choice plus CLA/DCO, dual licensing, source-available options, relicensing risk |
| `samber/developer-relations-skills@github-profile-optimization` | A personal or organization profile on a code host - profile README, pins, contribution signals |
| `samber/developer-relations-skills@oss-monetization` | One project's maintainers earning a living from it - paid add-on, support, content, hosting or license moves, gated on hours, ownership and trust |
| `samber/developer-relations-skills@oss-sponsors-fundraising` | Maintainer side - build a sponsorship program, tiers, rewards, the invoice path |
| `samber/developer-relations-skills@oss-sponsors-brand-strategy` | Company side - which projects to fund, how much, and how to prove it worked |
**Events and speaking:**
| Skill | Route here when the task is… |
| --------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| `samber/developer-relations-skills@conference-cfp-submission` | Turn a talk idea into a submission for one named event |
| `samber/developer-relations-skills@tech-talk-outline` | Turn an accepted abstract into a rehearsable outline and slide skeleton |
| `samber/developer-relations-skills@developer-live-demo-design` | Make a demo survive the stage - fidelity tier, checkpoints, fallbacks, runbook |
| `samber/developer-relations-skills@developer-meetup-program` | Run a recurring meetup or user group - format, cadence, speakers, venue sponsor, health |
| `samber/developer-relations-skills@devrel-webinar-program` | Run a recurring online webinar series - formats, seasons, replay, sales handoff contract |
| `samber/developer-relations-skills@developer-event-sponsorship` | Buy sponsorship - which events, which tier, which activation, what ROI proof |
**Community:**
| Skill | Route here when the task is… |
| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- |
| `samber/developer-relations-skills@developer-community-launch` | Whether, where and when to open a community, plus seeding and the first 90 days |
| `samber/developer-relations-skills@developer-community-moderation` | Code of conduct, enforcement ladder, reporting channels, incident runbook, moderator roster |
| `samber/developer-relations-skills@developer-champions` | A champions or ambassador program - intake, criteria, obligations, perks, terms, scorecard |
| `samber/developer-relations-skills@developer-community-health` | Measure the community - activity, responsiveness, contributor funnel, sentiment, thresholds |
| `samber/developer-relations-skills@developer-feedback-loop` | Route developer feedback to product and back - record of truth, decision review, status replies, saying no |
| `samber/developer-relations-skills@developer-office-hours-program` | Run recurring office hours or an AMA - format, time-zone slot, engineer rotation, scope card, write-up loop |
**Content and media:**
| Skill | Route here when the task is… |
| --------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| `samber/developer-relations-skills@engineering-blog-post` | Write or edit a technical post for a skeptical developer reader |
| `samber/developer-relations-skills@developer-case-study` | Turn a customer deployment into a technical case study engineers believe |
| `samber/developer-relations-skills@technical-video-script` | A shooting-ready screencast or motion design explainer script - beat sheet, chapters, cut list |
| `samber/developer-relations-skills@tech-podcast-interview-prep` | Prepare to be the guest on someone else's podcast, interview or livestream |
| `samber/developer-relations-skills@devrel-content-calendar` | Plan a quarter of content around fixed anchors, capacity and mix |
| `samber/developer-relations-skills@devrel-newsletter-program` | A developer newsletter as a programme - start, keep or stop, cadence, template, owner and backup, sunset |
| `samber/developer-relations-skills@tech-press-relations` | Press and light analyst relations - angle, reporter map, pitch, embargo, press page |
**Meta and personal practice:**
| Skill | Route here when the task is… |
| --------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| `samber/developer-relations-skills@devrel-radar` | Build the personal watch list - podcasts, newsletters, communities, conferences, people |
| `samber/developer-relations-skills@devrel-career` | Candidate side - portfolio scoring, skill-gap roadmap, interview prep, IC vs management |
| `samber/developer-relations-skills@devrel-hiring` | Employer side - job posting and scorecard, interview loop, portfolio scoring, ramp plan |
| `samber/developer-relations-skills@developer-relations-kickoff` | This skill: project start, periodic check-in, "which skill do I need", re-routing |
Disambiguate before routing wherever clusters collide on keywords:
- **Docs authoring** - five skills that all look like "write a getting-started page"
- **Release communication** - changelog vs migration guide
- **Measurement** - metrics vs analytics vs community health vs survey
- **OSS visibility** - launch vs distribution vs build-in-public
- **Sponsorship** - two skills that differ only by which side pays
- **Community** - four skills on one timeline
- **Strategy** - five skills that all answer "what should we do"
- **Speaking** - a sequence, not a competition
- **Employer brand** - the strategy for attracting engineers vs. one post, one profile page, or the candidate's own side of the table
Disambiguate strictly from each skill's declared scope - never from a guess about what a skill "probably" covers; a wrong disambiguation misroutes worse than none. Read [references/skill-routing.md](./references/skill-routing.md) before routing any task that could plausibly match two skills - it carries the per-skill route/do-not-route signals, every boundary fork above, the ordered chains, and the named coverage gaps.
Name the gap explicitly when the task needs something no skill covers. Collection v1 has no skill for:
- the exec-facing DevRel report
- a third-party trademark _usage and enforcement_ policy - who holds the trademark, domains and registry accounts belongs to `oss-governance`; registering the name before selling anything is a step in `oss-monetization`
- organizing your own conference or hackathon, conference booth operations, or post-event follow-up
- student and campus programs
- writing exam items or running exam delivery (the credential program itself is `developer-certification-program`)
- choosing a docs platform, or brand-mention monitoring, including brand share in AI answers (docs cited at the right version is covered by `developer-docs-ai-visibility`)
- writing the slides, editing the video, or legal sign-off on anything
Say "the collection has no skill for this" - never promise a skill exists or invent one.
Some tasks that land here aren't a true gap - they belong to the same owner's sibling collections:
- Public API surface design, webhooks, the public CLI wrapping the API, an Agent Skill shipped inside an SDK or CLI repo and versioned with its releases, SDK portfolios, package and CLI binary publishing to any registry or channel, sample-app portfolios, public roadmaps, API preview, beta and design-partner programs, developer-portal design, OAuth for third-party apps, connector-marketplace operations, a repository's engagement on GitHub after launch (Discussions, release notifications, topics, star policy), a vendor's product tag on Stack Overflow (staff answering, disclosure, backlog triage), the vendor's official GitHub Action and CI integrations (orbs, GitLab components), the vendor's own Zapier integration (triggers, Platform CLI code, review and beta, Zap templates, versioning), and the vendor's own Terraform/OpenTofu provider (build, signed Registry releases, deprecation) belong to `samber/developer-platform-skills`.
- Endpoint-level API reference completeness belongs to `samber/developer-platform-skills@api-reference-quality`; a hosted API's versioning and deprecation policy belongs to `samber/developer-platform-skills@api-versioning-policy`. A package's or project's release policy stays here, in `samber/developer-relations-skills@oss-release-policy`.
- Organizing your own event - venue, ticketing, sponsor sales, run of show, speaker sourcing as the organizer - belongs to `samber/dev-event-organizer-skills`.
Recommend installing the sibling collection instead of stretching a devrel skill onto the task, and never treat a sibling as a dependency this collection needs to function. See [references/skill-routing.md](./references/skill-routing.md) § Sibling-collection recommendations for the detection signals and the boundary per topic.
## 4. Output shape
Deliver the routing result in this shape, every time:
1. **State summary** (warm start only) - exactly 5 lines from the artifact: product and audience motion, funded driver and pillar mix, program stage and team shape, in-flight work, active constraint.
2. **Route** - the one skill for the immediate task, a sibling-collection recommendation naming the specific area (see § 3), or "no skill fits" plus the named gap when nothing covers it.
3. **Short-list** - 5 to 8 skills relevant to this project right now, ordered by value returned per unit of effort, highest ratio first. Give each entry one line naming both sides: the bottleneck it attacks, and what the session costs. Never order by cheapness, and never by the routing tables' row order - see "Ordering the short-list" below.
4. **Chain** - when the task genuinely decomposes into an ordered sequence (e.g. `developer-segmentation` → `devrel-strategy` → `devrel-metrics` → `devrel-budget-allocation`), list it in execution order with one line per link on what it hands to the next. Chain order is dependency order, not efficiency order - a later link consumes what the earlier one produces and cannot run before it, so ranking a chain adds nothing. Omit the chain when there isn't one - never fabricate a sequence.
5. **Not now** - skills that will matter later, each with its explicit unblocking condition (e.g. "`developer-community-health` - once the community has a baseline; `developer-community-launch` gates that at its day-90 review, that skill's own working convention").
6. **Gap** - anything today's task needs that no skill covers, stated as a gap.
### Ordering the short-list
The user's question at that moment is never "which of these 64 exists" but "which one do I run first, and is it worth the session". Only a ratio answers that. Default class order, highest value per unit of effort first:
1. **Diagnosis** - `developer-journey-map`, `developer-docs-structure-audit`, `devrel-competitor-analysis`, `developer-keyword-research`. Buys a named, evidenced answer to which class below is actually the problem, instead of a hunch. Costs one session over docs and signals already available; needs no engineering time and publishes nothing.
2. **First-run surfaces** - `readme-optimization`, `developer-quickstart-guide`, `oss-contributor-onboarding`, `github-profile-optimization`, `docs-code-sample-standards`. Buys the bail-fast funnel for every developer who arrives after it ships: fewer abandonments between landing and first successful call. Costs an editing session plus one merged pull request, and it is reversible by another commit.
3. **Release and support cadence** - `changelog-writing`, `version-migration-guide`, `developer-troubleshooting-docs`, `oss-issue-triage`, `oss-security-disclosure`, `oss-release-policy`, `docs-versioning-strategy`, `oss-maintainer-sustainability`. Buys users who can upgrade and self-serve their own errors instead of opening an issue. Costs a pass per release and a maintainer answering what the triage surfaces - it never finishes; it is a standing job, not a fix.
4. **Content and visibility** - `engineering-blog-post`, `developer-tutorial`, `developer-how-to-guide`, `technical-video-script`, `developer-case-study`, `docs-seo`, `developer-docs-ai-visibility`, `docs-localization-strategy`, `devrel-content-calendar`, `devrel-newsletter-program`, `build-in-public`, `oss-launch`, `oss-distribution-strategy`, `tech-press-relations`, `tech-podcast-interview-prep`. Buys reach that compounds - a post or a registry listing keeps earning for years. Costs a full production cycle per artefact plus review, and the payoff arrives a quarter after the work, not the week of it.
5. **Community and events** - `developer-community-launch`, `developer-community-moderation`, `developer-champions`, `developer-community-health`, `developer-meetup-program`, `developer-office-hours-program`, `devrel-webinar-program`, `developer-feedback-loop`, `developer-event-sponsorship`, `conference-cfp-submission`, `tech-talk-outline`, `developer-live-demo-design`, `oss-sponsors-fundraising`, `oss-sponsors-brand-strategy`. Buys the relationships nothing else in the collection produces. Costs the longest lead time here - a calendar someone else controls, a standing moderation duty, and months between opening a space and it being worth reading.
6. **Program and company foundations** - `devrel-strategy`, `developer-segmentation`, `devrel-metrics`, `devrel-analytics`, `developer-survey-design`, `devrel-budget-allocation`, `devrel-team-structure`, `developer-education-strategy`, `developer-certification-program`, `devtools-business-model`, `devtools-pricing-strategy`, `developer-first-gtm`, `open-source-company-strategy`, `developer-ecosystem-strategy`, `open-standards-strategy`, `oss-governance`, `oss-license-strategy`, `oss-monetization`, `tech-employer-branding`. Buys the rule every later session is decided against: what the program is judged on, who may merge, what the company gives away. Costs sign-off outside DevRel - engineering, legal, exec - and most of it is reversible only by another negotiation.
`devrel-career` and `devrel-radar` sit outside this ladder, not at the bottom of it. They answer a personal-practice or stay-current question, not a program question; when that _is_ the goal they are rung 1 by definition, and otherwise they don't belong on the short-list at all.
The axes disagree, which is exactly where the choice is hard:
- efficiency: `diagnosis > first-run surfaces > release cadence > content > community and events > foundations`
- value: `foundations > first-run surfaces > community and events > content > release cadence > diagnosis`
- effort: `foundations > community and events > content > release cadence > first-run surfaces > diagnosis`
- compliance cost: `foundations > community and events > content > release cadence > first-run surfaces == diagnosis (none)` - a license or governance decision binds every future contributor and is undone only by relicensing; a community space makes you moderator of other people's speech and holder of their reports; sponsorship money crosses a disclosure line; published posts and press need sign-off and cannot be unpublished; a release note is a public statement about breaking changes. Diagnosis and first-run surfaces tie at zero: both read and edit your own repository and publish no claim about anyone else, though first-run surfaces costs a merged pull request that diagnosis does not.
Foundations lead on value and sit last on efficiency, because sign-off is measured in weeks and the output is invisible the week it lands.
That is what the efficiency order starves: class 6's foundational skills. `devrel-strategy` and `oss-license-strategy` are the clearest cases - highest coordination cost, nothing shippable that week - so a ratio-first order polishes READMEs forever while every later session re-argues what the program is for and what the company may give away.
Promote class 6 to rung 1 outright when:
- Nobody can name the funded driver (Q4 came back empty or claimed all seven).
- No license or governance file exists on a repository already taking outside contributions.
- The same scope argument reappears session after session.
- The answer to Q7 is (d) standing with sign-off available.
Default: open the short-list at class 1 and stay there until the diagnosis names a class below it. Move down exactly one class at a time, and never past a class whose absence the diagnosis flagged.
Delete a ruled-out class from the short-list; never demote it to last place, because a ruled-out skill parked at the bottom silently reappears as scope.
- Has a stated unblocking condition - move it to the "Not now" list carrying that condition.
- Has none - drop it from the output entirely.
The ordering is a default, not a law - it shifts with the adoption motion and with who executes it. Re-rank against what the interview and the detection pass just told you, and say out loud which answer moved which class:
- A non-commercial open-source project with no buyer (Q3d) deletes `devtools-pricing-strategy`, `devtools-business-model` and `developer-first-gtm` from the short-list, and promotes `oss-governance` and `oss-sponsors-fundraising` inside classes 6 and 5.
- Individual self-serve adoption (Q3a) promotes classes 2 and 4.
- Organization-buys (Q3b) promotes `developer-case-study` and `developer-first-gtm` above their default place, since the signer never runs the quickstart.
- The funded driver (Q4) deletes whole classes:
- Sales enablement deletes class 3's triage entries unless the project is open source.
- Contributor community deletes `developer-first-gtm` and `devtools-pricing-strategy` outright.
- Employer branding promotes `tech-employer-branding` to rung 1, since it owns that driver's whole plan and ranks every content bet made under it.
- Stage "nothing formal yet" (Q5a) deletes `devrel-team-structure`, `devrel-budget-allocation` and `developer-community-health` - there is no team, no budget and no baseline to measure.
- No engineering support for docs (Q6c) deletes class 2's code-dependent entries and leaves `readme-optimization`, which needs no engineering time.
- No analytics access (Q6e) deletes `devrel-analytics` and `developer-community-health` from this session and moves them to "not now", unblocked by instrumentation.
- Legal or security review required (Q6d) lengthens classes 4, 5 and 6 without changing what they buy - say so rather than silently demoting them.
- A fixed date (Q6) promotes whatever acts inside that window:
- A conference date promotes `conference-cfp-submission` and `developer-live-demo-design` to rung 1 for the season.
- A release date promotes class 3.
- "One-off, maintainer hours only" (Q7a) cuts the short-list to two entries from classes 1 and 2.
- "Standing, with sign-off available" (Q7d) promotes classes 5 and 6 above their default place.
- An asset already owned changes the ratio, not the value: an instrumented analytics stack, a docs site already deployed, or a conference slot already accepted makes the dependent skill near-zero effort - promote it.
- A decided item (Q2) leaves the short-list outright; do not rank what is off the table.
- Detection moves classes too:
- A repository with no CONTRIBUTING file promotes `oss-contributor-onboarding` inside class 2.
- A git log showing months of stall points at diagnosis before any build.
- An existing docs site with an information architecture already audited deletes its class-1 entry.
## 5. Context artifact
Create or update `devrel-context.md` at the project root - one versioned file, committed with the project when the project lives in git, and the single source of truth that makes the next start warm. Its sections:
- Product and audience.
- Program: funded driver, pillar mix, stage and team.
- Surfaces owned.
- Measurement.
- State: in flight, decided vs open, constraints including the date the result must land by, the one-off-versus-compounding horizon and the effort ceiling.
- Stakeholders with decision rights.
- A session log.
Those last three constraint fields are what let a warm start re-rank the short-list and the routines without re-asking questions 6 and 7. See [references/context-artifact.md](./references/context-artifact.md) for the template, a worked example, and a negative example.
- On warm start: read it, do not rebuild it. Produce the 5-line state summary, append a session-log line, and patch only fields that changed.
- Optionally patch the project's agent-instruction file with the project's invariants (audience motion, funded driver, surfaces owned, hard constraints) so every future session inherits them without loading this skill.
- Do not scaffold a working tree the project hasn't earned. Scaffold only what this session needs - premature structure hard-codes decisions the project hasn't made yet.
- Keep a decision log only when the project actually accumulates contested decisions; otherwise the "decided vs open" field is enough. An empty ceremony log goes stale and erodes trust in the artifact.
Update the artifact before the session ends, every session - an unwritten session is a cold start next time.
## 6. Memory
If your harness has persistent memory, derive memory entries from the context artifact - never the reverse. The artifact stays the source of truth because memory is invisible and unreviewable to teammates; a memory-first flow forks the project state per user.
- Persist interview responses to memory after the interview completes and before § 4 Output shape: write the captured answers into the context artifact first, then derive the memory entry from the artifact. Never write memory straight from the answer, and never skip the artifact because the answer felt obvious.
- Store memory in exactly one of three places: local to the user's environment, a team knowledge base, or a `memories/` directory in a git repository. Index it with an index file listing each entry with a one-line hook.
- On warm start, diff memory against the artifact. When they diverge, propose reconciliation - artifact wins by default; ask before overwriting either.
- Never put into memory:
- Community-member or contributor personal data.
- Conduct reports and moderation cases.
- Unannounced launches and embargoed news.
- Sponsorship and event rates under NDA.
- Unpublished pricing.
- Customer names not yet cleared for a case study.
- Security-sensitive detail from a build-in-public boundary.
- State this exclusion when you first write memory.
- When memory lives in a git repository, never commit it silently. Show the diff and get approval first, every time.
## 7. Routines
If your harness supports scheduled routines, propose 2 to 4 - always shown as a dry-run before anything is created, each with an explicit output channel. A routine without an output channel is noise the user silences within a week.
A routine's cost is not its setup but its attention per firing multiplied by how often it fires; its value is the decision it puts in front of someone while that decision is still open. Rank the candidates on that ratio - value per unit of standing effort, highest first - and propose from the top down:
1. **Release-tag documentation pass** → `samber/developer-relations-skills@changelog-writing`, plus `samber/developer-relations-skills@version-migration-guide` when the release is a major. Fires only when a tag lands, over commits and pull requests already written, and it is the only routine whose output can reach users before the release does rather than after they hit the breakage.
2. **Monthly or quarterly re-invocation of this kickoff.** Near-zero per firing, and it keeps the artifact and the routing tables current - which is what stops every other routine firing at work that no longer exists. Match its cadence to the project's pace from the git log.
3. **CFP deadline sweep** ahead of the season's target events → `samber/developer-relations-skills@conference-cfp-submission`. A handful of firings a season, each a short read of a deadline list, against a deadline that is absolute: miss it and that stage is gone for a year. Buys nothing outside CFP season, which is why it is not rung 1.
4. **Periodic issue and pull-request queue review** → `samber/developer-relations-skills@oss-issue-triage`. Buys a queue that stays answerable instead of one that compounds into an abandoned project. Carries the highest standing cost in the set: a session per pass plus a maintainer answering everything it surfaces. Install it only where someone owns that follow-through.
5. **Quarterly content planning** at quarter start → `samber/developer-relations-skills@devrel-content-calendar`. Four planning sessions a year, buying a quarter of content that ships against real anchors instead of whatever occurred to someone that week.
6. **Periodic measurement read** → `samber/developer-relations-skills@devrel-metrics` (program) or `samber/developer-relations-skills@developer-community-health` (community only). Buys a trend line someone can act on - but only once a baseline exists; fired before that, it reads noise aloud on a schedule.
- efficiency: `release-tag pass > kickoff re-invocation > CFP sweep > queue review > content planning > measurement read`
- value: `queue review > release-tag pass > content planning > measurement read > CFP sweep > kickoff re-invocation`
- effort: `queue review > content planning > measurement read > release-tag pass > CFP sweep == kickoff re-invocation`
- compliance cost: `release-tag pass > content planning > measurement read == queue review == CFP sweep == kickoff re-invocation (none)` - release notes and migration guides are public statements about breaking changes and cannot be unpublished; a content calendar schedules those publications without committing to them. The four tied at zero all read internal or already-public state and emit it to the team; the CFP sweep and kickoff re-invocation also tie on effort, since each is one near-zero read per firing.
The kickoff re-invocation is the cheapest candidate and still sits second, not first - proof that cheap and efficient differ. The queue review leads on value and sits fourth on efficiency, since it costs a session every pass plus a maintainer answering each issue raised.
Default: rungs 1-2, which is two routines. Add rung 3 when CFP season is open, rung 4 once someone owns the triage follow-through. Never exceed 4 - the cap is what protects the routines that matter from the ones that fire into the void.
The ranking is a default, not a law; it shifts with the surface and with who executes it. Re-rank it against the interview and say which answer moved which routine:
- An open-source surface (Q1b) promotes the queue review above the CFP sweep.
- An events surface (Q1d) with a conference date promotes the CFP sweep to rung 1 for the season.
- No analytics access (Q6e) deletes the measurement read rather than demoting it.
- "Nothing formal yet" (Q5a) deletes it too, since there is no baseline to trend against.
- Maintainer hours only (Q6b), or "one-off, hours only" (Q7a), means install one routine - the kickoff re-invocation - not four.
- Legal or security review required (Q6d) lengthens the release-tag pass without changing what it buys.
- A team already running a weekly triage rotation makes rung 4 a duplicate, so demote it rather than sweep the same issues twice.
- An analytics stack already instrumented, or a docs pipeline that already builds on tag, makes its dependent routine near-zero effort - promote it.
Anchor triggers to the DevRel calendar - release train dates, CFP deadlines, conference dates, budget review, community rituals - rather than arbitrary dates, and prefer an event trigger over a schedule when one exists: a tag push beats "the first of the month" for release notes. List and clean up obsolete routines left over from a previous quarter before adding new ones.
If the harness has no scheduled routines, fall back to one recurring calendar reminder ("DevRel check-in - re-run the developer relations kickoff") and stop there. See [references/routines.md](./references/routines.md) for the dry-run format, calendar anchoring, event-trigger preference, and cleanup checklist.
## 8. Invocation examples
- "Start a new devrel project - we just open-sourced our SDK and nobody uses it." → cold start: detect, interview, route, write the artifact.
- "Which devrel skill do I need? Our docs are fine but signups never reach production." → routing ask: match against the tables, disambiguate, name the gap if none fits.
- "Run my devrel check-in." → warm start: 5-line state summary, session-goal question, re-route.
- "Where do I start? I'm the first devrel hire and I have no idea what to do first." → cold start: expect an ordered chain, not a single route.
## 9. Failure modes
- **Forcing a match.** Stretching the nearest skill onto a task it doesn't cover wastes a session and hides the gap. Say "none fits" and name the gap.
- **Routing every docs question to the same skill.** Quickstart, tutorial, how-to and reference are four different jobs, and reference completeness belongs to `samber/developer-platform-skills@api-reference-quality`. Check § Docs-authoring fork in the routing reference first.
- **Force-fitting platform or event-production tasks.** API design, webhooks, SDK strategy and marketplace operations belong to `samber/developer-platform-skills`; organizing your own conference belongs to `samber/dev-event-organizer-skills`. Recommend the sibling collection instead.
- **Re-interviewing on a warm start.** The artifact exists precisely so questions aren't repeated. Ask only the session goal.
- **Routing from a guessed scope.** Route only from the declared scopes in the routing reference; a plausible guess misroutes confidently.
- **Skipping the funded-driver question.** Without it, the strategy, metrics and budget routes all collapse into generic advice the user has to re-scope by hand.
- **Uncapped interview.** Past 7 questions the kickoff becomes a form the user abandons.
- **A flat short-list.** Eight equal-looking options get picked by taste, or by whichever sits first. Order by value per unit of effort and name both sides on every line, or the user cannot choose.
- **Leading with the cheapest option.** Cheap and efficient are different orderings, and only the second one answers "what first". A near-zero routine that buys near-zero is a rounding error, not a quick win.
- **Ranking the routing tables or the chain.** Scope is a match test and a chain is a dependency order; imposing a ratio on either invents a preference that does not exist.
- **Demoting a ruled-out skill instead of deleting it.** A class the interview took off the table, parked at the bottom of the short-list, reappears as scope two sessions later. Delete it, or move it to "not now" with its unblocking condition.
- **Letting the ratio starve the foundations.** Class 6 loses every efficiency round and is exactly what a program being set up needs first. Check its promotion conditions before opening at class 1.
- **Routines with no output channel.** They fire into the void and get silenced, burying the one routine that mattered.
- **Memory committed silently.** Teammates can't review what they can't see land. Diff and approval, always.
- **Stale routing table.** Update the tables, routing reference, boundary forks, chains and gap list whenever the collection changes - a skill added, renamed, removed, or re-scoped. A stale router sends users to skills that no longer exist, which is worse than no router at all.
## 10. Pass bar
Before ending the session, check every item. If any fails, fix it and re-check - do not close the session on a failing bar.
1. Every recommended skill's declared scope actually matches the stated task - re-read its description to confirm.
2. Zero routes to a name outside the tables above.
3. Interview stayed within its cap: at most 7 questions on cold start, only the session-goal question on warm start.
4. `devrel-context.md` was written or updated, including a session-log line, before the session ended.
5. Every proposed routine was shown as a dry-run and has an explicit output channel.
6. The short-list and the routine set are both ordered by value per unit of effort, each entry naming the bottleneck it attacks and what it costs - and the re-rank was stated out loud whenever an interview answer moved something off its default place.
7. Every class the interview ruled out left the short-list entirely, rather than sitting at the bottom of it.
8. The routing tables and any proposed chain were left unranked - match test and dependency order respectively.