developer-relations-kickoff — Claude Code skill: route DevRel tasks

---
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.20"
---

# 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@producthunt-playbook`       | Product Hunt itself - whether to launch there, self-hunting, account eligibility, featuring vs points, maker comment, vote and AI-comment rules, relaunch gaps, product forum |
| `samber/developer-relations-skills@hackernews-playbook`        | Hacker News itself - Show HN eligibility, title and first comment, thread conduct, staff disclosure, Who is hiring, flags and reposts |
| `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@devto-playbook`              | Run the vendor's or maintainer's dev.to presence - organization, canonical cross-posting, tag rules, AI disclosure, earn-first cadence |
| `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@devrel-newsletter-issue`     | Write, edit or review one newsletter issue - item write-ups, own releases, sponsor slot, email-safe code, pre-send check, corrections |
| `samber/developer-relations-skills@devrel-newsletter-deliverability` | Keep the newsletter in the inbox - SPF/DKIM/DMARC, sending subdomain, bulk-sender rules, one-click unsubscribe, warm-up, bounces, spam-folder diagnosis |
| `samber/developer-relations-skills@devrel-newsletter-growth`    | Grow and keep the newsletter's list - signup surfaces, consent at signup, curator pitches, swaps, churn reading, per-source metrics |
| `samber/developer-relations-skills@devrel-newsletter-sourcing`  | Find and gate one issue's items - intake channels, window, primary sources, thin-issue call |
| `samber/developer-relations-skills@devrel-newsletter-sponsorship` | Sell sponsor slots in your own newsletter - sellability gate, acceptance policy, slots and caps, click-based rate card, ad label, booking terms, sponsor report |
| `samber/developer-relations-skills@tech-press-relations`        | Press, newsletter curators 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`)
- per-community playbooks for Reddit, Lobsters, X or LinkedIn (Hacker News is covered by `hackernews-playbook`)
- 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 Git...