developer-relations-skills 플러그인

• bluesky-dev-playbook

  Runs a devtool vendor's, developer advocate's or open-source maintainer's presence on Bluesky - go-or-skip verdict, people versus brand accounts, domain handles and the blue check, starter packs, developer custom feeds, discovery without a central algorithm, block lists, cross-posting from X or Mastodon, what a bot account may do. Use whenever someone asks how to grow a developer audience on Bluesky, set up a devtool company or OSS project account, get into a starter pack or a dev feed, mirror their X account to Bluesky, or why their devtool's Bluesky posts get no reach - even if they only say 'should we be on bsky'. Not for coding bots, feed generators or other AT Protocol apps. Do NOT use for the weekly narrative - use samber/developer-relations-skills@build-in-public.

• build-in-public

  Designs a sustainable build-in-public practice for an open-source project or developer tool: how far up the disclosure ladder to go (shipping log, decisions, failures, metrics, revenue), a cadence the maintainer can hold, the platform mix, and the boundaries that keep security, customer and roadmap detail off the public record. Use whenever someone mentions building in public, a devlog, weekly updates, an open-startup or transparency dashboard, sharing metrics or revenue openly, fear of copycats, oversharing, wanting to stop publishing numbers, or a stalled practice they want to restart, even if they never say "build in public". Covers solo maintainers, bootstrapped and funded devtools teams. Not for a one-time launch; use samber/developer-relations-skills@oss-launch.

• changelog-writing

  Turns raw commits, pull requests and tickets into release notes developers actually read - a scannable record of what shipped, what it means in practice, and what breaks. Use whenever the user mentions a changelog, CHANGELOG.md, release notes, a GitHub release body for a tag, a hosted "what's new" page, app-store release notes, Keep a Changelog, or Common Changelog, or asks what to write for a release they just cut - even when the commit history is messy and follows no commit convention. Not for version bumping, tagging or publishing pipelines. Do NOT use for a full breaking-change upgrade guide - use samber/developer-relations-skills@version-migration-guide; for a narrative release post use samber/developer-relations-skills@engineering-blog-post.

• coding-agent-docs-optimization

  Makes SDK, API or protocol documentation something a coding agent can integrate from unattended - crawler access, machine-readable entry points (llms.txt, markdown endpoints, OpenAPI and JSON Schema files), self-contained copy-paste-safe pages, and a measured first-attempt agent success rate. Use whenever the user mentions agent-readable or AI-ready docs, agent experience or AX, llms.txt or llms-full.txt, docs for coding agents, agents inventing API calls that do not exist, or asks whether an agent could wire up their SDK from the docs alone - even if they never say "agent". Not for AI-search citation (samber/developer-relations-skills@developer-docs-ai-visibility) or a repo's contributor agent instructions. For human docs architecture use samber/developer-relations-skills@developer-docs-structure-audit.

• conference-cfp-submission

  Turns a talk idea into a submission-ready conference proposal for one specific event, or helps choose which conferences to target and plan a submission calendar across several - track fit, title options, an attendee-facing abstract, verb-first takeaways, the reviewer-only fields, a credibility package, and a self-review against the committee's own criteria. Use whenever the user mentions a CFP, a call for papers, a conference proposal, a talk abstract, a session description, submitting to KubeCon, PyCon or FOSDEM, which conference to submit to, planning a CFP season, or says their proposals keep getting rejected - even if they only ask to shorten an abstract. Covers community-run and vendor-run events. Do NOT use for structuring the accepted talk (samber/developer-relations-skills@tech-talk-outline) or its demo (samber/developer-relations-skills@developer-live-demo-design).

• dailydev-playbook

  Runs a devtool vendor's or maintainer's presence on daily.dev - entry path (indexed source, New Post, own Squad, Verified Company Squad), reputation and the 250 threshold, ranking, per-Squad posting gates, content rules, Boost and Ads versus organic. Use whenever the user mentions daily.dev, a daily.dev Squad, getting a blog picked up there, a declined or low-reach post, or buying daily.dev ads - even if they only say 'our posts there get no views'. Not for feed reading, its API or Career Mode. Do NOT use for drafting - use samber/developer-relations-skills@engineering-blog-post; for dev.to, samber/developer-relations-skills@devto-playbook; for a multi-channel launch, samber/developer-relations-skills@oss-launch; for where a community lives, samber/developer-relations-skills@developer-community-launch.

• developer-booth-playbook

  Writes an exhibiting company's own playbook for an in-person booth at a developer conference: who works it and how many per shift, roles, how staff open and qualify a conversation, how each lead is captured and graded, swag and giveaway policy, and the exhibitor rules to obey. Use whenever a team is sending people to work a booth at KubeCon, re:Invent, PyCon, DevOpsDays or any developer event and asks about booth staffing, shifts, badge scanning, booth lead qualification, booth swag, a booth raffle or booth etiquette - even if they only say 'we got a booth, now what'. Do NOT use for choosing the event or tier (samber/developer-relations-skills@developer-event-sponsorship) or the demo itself (samber/developer-relations-skills@developer-live-demo-design).

• developer-case-study

  Turns a customer's real production deployment into a technical case study engineers believe - measured numbers tied to how they were measured, before-and-after architecture, published limitations, and cleared naming and quote approval. Use whenever the user mentions a customer case study, a technical case study, a developer adoption or success story, a reference customer, or wants to turn a user interview, migration or production rollout into published proof - even if they only say "a post about how Acme uses us". Do NOT use for a post about your own system - use samber/developer-relations-skills@engineering-blog-post; for your own project's ongoing progress use samber/developer-relations-skills@build-in-public.

• developer-certification-program

  Plans the issuer side of a developer certification or badge program, mostly for freelancers and IT services firms who sell consulting and must be recognised as experts by clients: whether to issue one, tier, exam format, proctoring, renewal, fees, verification, expert directory, a prep course on a MOOC or edtech platform, and training and exam-delivery partners. Use whenever a platform team mentions a developer or consultant certification, certification exam design, proctoring, recertification, exam vouchers or authorized training partners. Not for exam candidates, hiring tests or app certification (samber/developer-platform-skills@app-marketplace-review). Not for whether to build an academy - use samber/developer-relations-skills@developer-education-strategy.

• developer-champions

  Designs an unpaid, perks-only developer champions or ambassador program end to end - readiness check, intake model, published selection criteria, behaviour-based obligations, an access-first perk ladder, fixed terms with renewal and alumni status, and a cohort scorecard. Use whenever the user mentions an ambassador or champions program, MVP-style recognition, community heroes, "how do we recognise our top community members", what perks ambassadors should get, an ambassador program that went quiet, or removing an inactive champion - even if they never say "champion". Not for paid creator, affiliate or revenue-share partnerships. For measuring the community itself use samber/developer-relations-skills@developer-community-health.

• developer-community-health

  Designs and runs a developer community health measurement framework: activity, responsiveness, contributor-funnel and sentiment metrics, honest instrumentation, baseline-derived thresholds, and a report that ends in decisions. Use whenever someone asks how to measure their developer community, which community health metrics to track, whether their Discord, Slack or forum is dying, why the community feels quiet, or wants a community health dashboard, contributor funnel, community KPI set or engagement report - even if they only say "is our community doing OK". Do NOT use for launching a community (samber/developer-relations-skills@developer-community-launch) or company-wide devrel KPIs (samber/developer-relations-skills@devrel-metrics).

• developer-community-launch

  Decides whether, where and when to launch a developer community, then plans its seeding and first 90 days - venue selection, founding-member seeding, go/no-go criteria, the cheaper no-community alternatives, and shutdown criteria. Use whenever someone asks whether to start a Discord, Slack or forum for their users, which community platform to pick, how to launch or seed a developer community from zero, or how to reach critical mass - even if they only say "we should have a Discord". Do NOT use for a community that already exists; measurement is samber/developer-relations-skills@developer-community-health and moderation is samber/developer-relations-skills@developer-community-moderation.

• developer-community-moderation

  Writes a developer community's code of conduct and the moderation playbook behind it - scope, enforcement ladder, reporting channels, incident-response runbook, moderator roster, platform controls. Use whenever the user mentions a code of conduct, CODE_OF_CONDUCT.md, community moderation, moderator recruitment, an escalation ladder, banning or suspending a member, harassment, trolls, brigading, spam or AI-slop floods, or a conduct report they need to handle - including vaguer phrasings like "our Discord is getting out of hand", "we need community rules", or "someone reported a maintainer". Covers company-run and volunteer open-source communities. Do NOT use to pick the platform - use samber/developer-relations-skills@developer-community-launch.

• developer-docs-ai-visibility

  Gets developer documentation cited, at the current version, in AI assistant and AI search answers - ChatGPT, Claude, Perplexity, Gemini, Copilot, Google AI Overviews and AI Mode - and measures version-correct answers over repeated runs. Use whenever someone says assistants answer with deprecated or old-version docs, asks how to get docs cited by ChatGPT or Claude, asks for GEO, AEO or LLM visibility for developer docs, or whether llms.txt earns citations - even if they never say visibility. Not for brand or marketing-page AI visibility, nor the docs site's own AI assistant. Do NOT use for search indexing and canonicals - use samber/developer-relations-skills@docs-seo; nor agents integrating unattended - use samber/developer-relations-skills@coding-agent-docs-optimization.

• developer-docs-structure-audit

  Audits an existing developer documentation set's structure - a page-by-page inventory classified against the Diátaxis modes (tutorial, how-to, reference, explanation), mixed-mode and misplaced pages, coverage gaps per product surface, navigation drift against the file tree, a CNCF TechDocs rubric score, and a prioritized remediation queue. Use whenever the user mentions a docs structure or content audit, docs information architecture, Diátaxis, "our documentation is a mess", a docs gap analysis, what docs are missing, where a page should live, or reorganizing a documentation site - even if they only say "our docs are hard to navigate". Not for writing pages. Do NOT use for docs search ranking - use samber/developer-relations-skills@docs-seo.

• developer-ecosystem-strategy

  Decides whether, when and how far a developer product should open into a platform other companies build on - extension points, partner-built integrations, third-party apps, a complement ecosystem - and what that permanently obliges you to. Use whenever someone asks if the product should become a platform, whether to open extension points or an app model to third parties, how to start an integration ecosystem, why nobody builds on the API, whether partners should build the connectors, or how much value complementors must keep - even if they only say "we want an integrations story". Not marketplace operations or API design. Do NOT use for the revenue model - use samber/developer-relations-skills@devtools-business-model.

• developer-education-strategy

  Decides whether and how to invest in structured developer education, such as learning paths, a developer academy, hands-on labs, or a badge or certification rung on top - instead of more ad-hoc content, then designs its operating model, staffing, refresh cadence, measurement and kill rules. Use whenever someone mentions a developer academy, a developer curriculum, training for developers, learning paths, partner or SI enablement training, or scaling developer onboarding beyond docs - even if they only say "we need more training content". Covers B2B, partner and bottom-up motions. Never writes courses - use samber/developer-relations-skills@developer-tutorial. Do NOT use for designing the credential itself - use samber/developer-relations-skills@developer-certification-program.

• developer-event-followup

  Plans what a company does after an in-person developer event it exhibited at, spoke at, sponsored or ran a workshop at: sorting badge scans, booth notes, raffle entries, rosters and hackathon submissions, deciding who may be emailed and for what, writing the messages, routing contacts to product, community or sales, and measuring the cohort. Use whenever someone asks what to do with conference leads or badge scans, how to follow up after a hackathon or workshop, whether they can email the people they met, or why event leads never convert - even if they only say 'we got 400 scans at KubeCon, now what'. Do NOT use for working the booth (samber/developer-relations-skills@developer-booth-playbook) or webinar registrants (samber/developer-relations-skills@devrel-webinar-program).

• developer-event-sponsorship

  Builds a developer-event sponsorship plan - which conferences, meetups and hackathons to sponsor, at which tier, with which on-site activation, and how to prove the money worked. Use whenever a DevRel lead, developer marketer or founder mentions sponsoring a conference, booth cost, a sponsorship tier or package negotiation, splitting an event budget across events, hackathon sponsorship, or event ROI - even if they only ask "is this booth worth it". Do NOT use for organizing your own event (samber/developer-relations-skills@developer-meetup-program), getting a talk accepted (samber/developer-relations-skills@conference-cfp-submission), or sponsoring open-source projects.

• developer-feedback-loop

  Designs the loop carrying developer feedback from Discord, Slack, forums, support, GitHub issues, sales calls and events to product and back - one record of truth, dedup rules, records product acts on, product-owned decisions, public status replies including the no, and loop metrics. Use whenever feature requests pile up in the community and product never sees them, or someone asks how DevRel should hand feedback to product, close the loop with developers, triage feature requests across channels, say no publicly, or show what feedback shipped - even if they only say "product ignores what our users ask for". Not surveys, NPS or office hours. Do NOT use for the issue queue - use samber/developer-relations-skills@oss-issue-triage; not community health - use samber/developer-relations-skills@developer-community-health.

• developer-first-gtm

  Designs the go-to-market motion for a developer-facing product - bottom-up self-serve adoption, developer-influenced sales, top-down with developer proof, or ecosystem-mediated distribution - plus the self-serve entry, the developer-to-buyer handoff rule and the land-and-expand path. Use whenever a founder, devrel or growth owner asks how developer adoption turns into revenue, whether to go bottom-up or hire sales, when to contact a free user, why signups are high and paid accounts flat, or how landed teams expand across an enterprise - even if they only say "our funnel is broken". Not price points - use samber/developer-relations-skills@devtools-pricing-strategy.

• developer-how-to-guide

  Writes or audits a goal-oriented developer how-to guide: a docs page walking a current user through one real task the product supports, with checkable prerequisites, guarded risky steps and a closing verification. Use whenever the user wants docs showing how to configure, integrate, rotate, deploy or secure something with an API, SDK, CLI or platform, or mentions a how-to guide, task page or docs recipe. Not for doing the task yourself, internal runbooks, READMEs or blog posts. Do NOT use for a tutorial (samber/developer-relations-skills@developer-tutorial), a quickstart (samber/developer-relations-skills@developer-quickstart-guide), ticket-mined error or FAQ pages (samber/developer-relations-skills@developer-troubleshooting-docs) or an upgrade guide (samber/developer-relations-skills@version-migration-guide).

• developer-journey-map

  Maps the developer journey for one audience segment - discovery, trial, adoption, contribution, advocacy - as a stage-by-stage table where each stage carries an exit event, a named owner, cited friction evidence and one signal, and names the single leak worth fixing next. Use whenever someone asks what their developer journey looks like, wants a developer adoption funnel or journey map, asks why developers try the product but never reach production, where adoption drops off, who owns each step of developer experience, or how developers become contributors - even if they only say "we lose people somewhere". Not the metrics framework - use samber/developer-relations-skills@devrel-metrics.

• developer-keyword-research

  Builds a prioritized keyword list for technical search queries (error strings, "how to X in Y" tasks, integration intents, comparisons, migrations) mined from docs search logs, support tickets, issue trackers and first-party query data rather than keyword-tool volume. Use whenever the user asks what developers actually search for, wants keywords for a developer tool, API, SDK or docs site, an error-message keyword list, demand sizing for a technical topic, or which docs pages to create from search demand - even if they never say "keyword". Does not write the pages. Do NOT use for on-page or docs-site SEO - use samber/developer-relations-skills@docs-seo.

• developer-live-demo-design

  Engineers a technical demo so it survives the stage - risk triage, the fidelity tier it should run at, independently enterable checkpoints, a one-command environment reset, offline mode, a recorded fallback and rehearsed recovery lines, shipped as a demo runbook with a pre-flight checklist. Use whenever the user mentions a live demo, live coding, demo reliability or a fallback plan, "my demo broke on stage", whether to demo live or pre-record, a demo environment reset, a clean demo laptop, a demo profile or a panic button, or is preparing a talk, workshop, webinar or launch stream containing a demo - even if they only say "I'm nervous about the demo" or "what if I share the wrong screen". Not the talk's structure - use samber/developer-relations-skills@tech-talk-outline.

• developer-meetup-program

  Designs and runs a recurring developer meetup or user group - purpose and host model, format menu, cadence, a standing speaker pipeline, in-kind venue and food sponsors with their conduct limits, no-show planning, the attendee-to-co-organizer ladder, and a health scorecard. Use whenever someone mentions starting a developer meetup or user group, dying meetup attendance, finding meetup speakers, getting a venue or pizza sponsor, how often to meet, RSVPs who never show, or handing the meetup over - even if they only say "we want to do local events". Covers independent, vendor-backed and company-staffed groups. Not for speaking at a conference - use samber/developer-relations-skills@conference-cfp-submission.

• developer-office-hours-program

  Designs a recurring developer office-hours or AMA program: format, a slot fitting the users' time zones, a sustainable engineer rotation, a published scope card, empty-room and recording policies, and write-ups that turn repeat questions into docs fixes. Use whenever someone wants to start or fix developer office hours, an ask-the-engineers session, a recurring community AMA, a Q&A call nobody attends, engineers who stop showing up, or office hours across time zones - even if they only say "we want a regular session where users ask the team questions". Do NOT use for whether to open a Discord, Slack or forum - use samber/developer-relations-skills@developer-community-launch; not for routing feedback into product - use samber/developer-relations-skills@developer-feedback-loop.

• developer-quickstart-guide

  Writes or audits a developer quickstart that carries a reader from zero to one verified success - minimal path, copy-paste commands, expected output at every step, fail branches, and a cold-run time budget. Use whenever the user mentions a quickstart, a getting-started page, a hello-world doc, "time to first success" or "time to first value", onboarding docs for an API, SDK, CLI or self-hosted tool, or complains nobody finishes their getting-started page - even if they only say "our setup is too hard". Do NOT use for a teaching tutorial (samber/developer-relations-skills@developer-tutorial) or a README rewrite (samber/developer-relations-skills@readme-optimization).

• 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.

• developer-segmentation

  Cuts a developer audience into a few named, sized and ranked segments - the two dimensions worth cutting on, a size range with a confidence tier, the user/champion/approver/buyer split inside each, a weighted score, one primary and one secondary segment, and a written anti-segment. Use whenever someone asks who their developers actually are, which developer audience to serve first, how big a language ecosystem or persona is, whether to target hobbyists or enterprise platform teams, who signs when the developer is not the buyer, or why content reaches everyone and converts nobody - even if they only say "who is this for". Not the journey map - use samber/developer-relations-skills@developer-journey-map.

• developer-survey-design

  Designs a recurring survey of external developers - an annual "State of" community survey or a product survey - from the decisions it informs to the published report: question cuts, recruitment and a calibration sample, pilot, GDPR, cleaning, analysis and a methodology section that makes headline numbers defensible. Use whenever someone plans a developer or community survey, inherits a questionnaire drafted by marketing, wants to publish percentages from their own survey, or asks about sampling bias, response rates, incentives, survey length or year-over-year comparison - even if they only say "we want to run a State of X". Not internal employee surveys or one event's feedback form. Do NOT use for community NPS or pulse items - use samber/developer-relations-skills@developer-community-health.

• developer-troubleshooting-docs

  Turns support tickets, issue history and error telemetry into troubleshooting and error-reference pages a developer finds by pasting the error string - symptom, conditions, cause, fix and verification entries, an error-code catalog generated from one source of truth, and fixes wired back into the product's own error output. Use whenever the user mentions troubleshooting docs, documenting error codes, error message pages, a known-issues page, building an FAQ from support tickets, or "we answer the same question every week" - even if they only say "users keep hitting this error". Not for debugging a live incident. Do NOT use for docs search ranking - use samber/developer-relations-skills@docs-seo.

• developer-tutorial

  Writes or audits a teaching tutorial for a developer product - one new concept per step, checkpoints the learner can verify and resume from, guidance that fades, troubleshooting hooks, and a demonstrable skill at the end. Use whenever the user mentions a tutorial, a build-along or hands-on guide, a "learn X by building Y" article, a workshop or lab handout, a developer course lesson, or says nobody finishes their tutorial - even if they just say "write a guide that teaches this". Do NOT use for a zero-to-first-success quickstart (samber/developer-relations-skills@developer-quickstart-guide) or a video script (samber/developer-relations-skills@technical-video-script).

• developer-workshop-program

  Designs a hands-on technical workshop program delivered to one customer or prospect account at a time: the grant rule agreed with sales, a lab catalog mapped to discovery, the lab environment standard, instructor certification, the next-step agreement and account-level metrics. Use whenever someone runs or plans customer workshops, immersion days or hands-on labs for a customer's engineers, hears an AE ask "can we do a workshop for them next week", sees workshops end with no POC, or needs SEs or partners trained to deliver them - even if they only say "our workshops don't convert". Do NOT use for a session inside a conference - use samber/dev-event-organizer-skills@workshop-program-design - or a paid training catalog - use samber/developer-relations-skills@developer-education-strategy.

• devrel-analytics

  Builds the tracking plan that instruments developer-relations surfaces - docs, blog, repositories, package registries, community venues, and off-web appearances - with an event taxonomy, an identity spine, link-tagging discipline, source-confidence labelling, and funnel views. Use when the user says "devrel tracking plan", "docs analytics", "utm discipline", "event taxonomy for our docs", "our GitHub numbers don't match analytics", "how do we instrument the developer funnel", "join docs traffic to signups", or wants to know why devrel numbers disagree between tools. Instrumentation layer only - which KPIs deserve a target belongs to samber/developer-relations-skills@devrel-metrics.

• devrel-budget-allocation

  Splits a developer relations budget across pillars - events, content, community, tooling, education, OSS sponsorship - into line items that each carry a cash cost, an hours cost, a pre-set return threshold, a review date and a reallocation rule, plus a ranked cut list. Use whenever someone asks how to plan or split a devrel budget, how much to spend on events versus content versus community, whether a line item is worth its money, or what to cut first when the budget shrinks - even if they only say "we spend too much on conferences". Not the metrics framework (samber/developer-relations-skills@devrel-metrics), one event's ROI (samber/developer-relations-skills@developer-event-sponsorship), or the exec defense case (samber/developer-relations-skills@devrel-exec-reporting).

• devrel-career

  Plans, lands and advances a developer relations career from the candidate side - developer advocate, developer evangelist, DevRel engineer, community manager, developer educator, DX engineer. Covers portfolio audits against real hiring signals, a zero-to-hireable artefact curriculum, the six-rung IC ladder, the interview formats DevRel loops use (talk round, content and coding take-homes, DevRel-opinion round), gatekeeper and pit-trap patterns in postings, and offer evaluation weighing reporting line before pay. Use whenever someone asks how to break into DevRel, prep a developer advocate interview, build a DevRel portfolio, choose a track, plan the next rung, or weigh a DevRel offer - even if they only say "should I take this advocate job". Not a job-search tool.

• devrel-competitor-analysis

  Benchmarks a competitor's developer relations motion from publicly observable signals - documentation and quickstart quality, open-source repository health, community size and responsiveness, Q&A tag activity, content cadence by format, event presence, hiring signals - and returns a gap plan with a close, ignore or counter verdict per row. Use whenever the user asks for a devrel competitive benchmark, a developer experience comparison, "how do we compare to <competitor> for developers", "what is <competitor> doing in devrel", a community size or content cadence comparison, or a docs comparison against rivals - even if they only say "why do they get more developers". Not for measuring your own program alone - use samber/developer-relations-skills@devrel-metrics.

• devrel-content-calendar

  Plans a quarter of developer-relations content as a dated slot plan with named owners and reviewers - fixed anchors (releases, launches, CFP deadlines, conferences), a surface, pillar, journey and shelf-life mix, and sizing against real writing and review capacity. Use whenever the user asks for a devrel content calendar, an editorial calendar or content plan for a developer audience, what to publish next quarter, how to balance evergreen against launch-tied content, how many pieces a small team can ship, or says their content plan keeps slipping - even if they only say "we publish randomly". Plans the quarter only; individual pieces go to the per-format skills such as samber/developer-relations-skills@engineering-blog-post.

• devrel-exec-reporting

  Writes the executive-facing developer relations report: a one-page value story for a CEO, CFO, CMO, CTO or board, leading indicators carrying long-lag outcomes, every claim labelled by evidence strength, and the budget-defense case when the program faces a review or a cut. Use whenever someone needs a devrel QBR, monthly exec update, board slide or budget-review memo, must explain what the devrel team delivers to leadership, or must defend the devrel budget - even if they only say 'my VP wants a devrel update by Friday'. Never redefines metrics. Do NOT use for choosing KPIs or the attribution rule - use samber/developer-relations-skills@devrel-metrics. Do NOT use for splitting the budget or building the cut list - use samber/developer-relations-skills@devrel-budget-allocation.

+53