samber/developer-relations-skillsチェック済み
SKILL DETAIL
devrel-content-calendar
samber/developer-relations-skills/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.
インストール · 417出典を見る
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill devrel-content-calendar
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "devrel-content-calendar",
"evals": [
{
"id": 1,
"prompt": "I run devrel at Halberd Labs (workflow orchestration engine, self-hosted plus a cloud tier). I need to plan Q2, 13 weeks starting April 6. Fixed things: v4 ships week 3 and it's the big one, new scheduler. We have two talk submissions in at DataCon and StreamSummit but we don't hear back until week 6. Travel budget for the year isn't approved yet, finance says maybe. And there's a board review in week 10 where they decide whether devrel gets a second headcount next year. Team is me (I do the writing), one advocate, and a staff engineer called Priya who reviews technical claims. What should the quarter look like?",
"expected_output": "A ranked menu of the three quarter shapes stated out loud, with launch-dominated recommended because of the week-10 board review, event-led deleted outright and named as deleted because the CFP results are undecided and travel is unapproved, the launch shape's embargo compliance cost surfaced, and a decision requested before any dated slots are placed.",
"files": [],
"expectations": [
"Presents three candidate quarter shapes: evergreen-compounding, launch-dominated and event-led.",
"States the efficiency ranking in words rather than leaving it implied by the order of rows or bullets.",
"Gives value inside the quarter and value a year out as two separate orderings rather than one blended rank.",
"Recommends the launch-dominated shape and names the week-10 board review as what promotes it.",
"Deletes the event-led shape outright rather than keeping it as a third option to choose from.",
"Says explicitly which shape was deleted and why: CFP results undecided until week 6, and no approved travel budget.",
"States that an event-led quarter planned against pending CFP outcomes would be a bet.",
"Names the launch shape's compliance cost: an embargo, with product, legal and marketing each holding a veto that is exercised late.",
"Keeps some slots independent of the v4 date so a slipped release does not take the whole quarter with it.",
"Asks the user to choose a shape before placing dated slots.",
"Presents the plan section by section (anchors, mix ratios, capacity model, slot table, review ritual) for validation one section at a time rather than as one finished block.",
"Does not claim the evergreen-compounding shape produces results visible inside this quarter."
]
},
{
"id": 2,
"prompt": "Sizing question. Mesomorph, distributed job queue, open core. Q3 is 13 weeks. I have a full-time technical writer, call it 30 hours a week of actual writing time, and one backend engineer, Dan, who is the only person who can verify our claims. He has given us 3 hours a week and he's on call every other week. I want to slot 18 pieces: 6 step-by-step tutorials with runnable code, 4 benchmark posts comparing us to the two obvious alternatives, 5 docs pages, 3 changelog entries. Does that fit? If not, tell me what to drop.",
"expected_output": "A no, with the engineer's 3 review hours identified as the binding constraint rather than the writer's 30 writing hours, every format estimated in passes, tutorials and benchmarks named as the review-heaviest cuts, committed slots capped at 80% with named slack, and cheaper-to-verify formats offered as substitution.",
"files": [],
"expectations": [
"Answers that 18 pieces does not fit the quarter.",
"Names Dan's 3 hours a week of technical review as the binding constraint, not the writer's 30 hours.",
"Estimates each format in passes rather than drafting hours, naming passes such as research, drafting, writing code that must run, technical review, assets, publishing and the post-publication reply load.",
"States that reviewer passes, not writer hours, are what bind a developer-content plan.",
"Identifies the 6 tutorials and 4 benchmark posts as the review-heaviest formats because they require code that runs and reproducible measurements.",
"Warns that a benchmark or migration guide fails late in the cycle.",
"Notes that review by someone who does not report to the content owner is a systematically underestimated lead time.",
"Caps committed slots at no more than 80% of estimated capacity.",
"Holds the remaining capacity as named slack and says who may spend it.",
"Cuts slots rather than lowering quality, and names which slots are cut.",
"Offers cheaper-to-verify formats such as docs pages, changelog entries or troubleshooting pages as the substitution.",
"Asks for Mesomorph's own last-quarter shipped and slipped numbers rather than relying only on a published default."
]
},
{
"id": 3,
"prompt": "Settle an argument for me. Northwind Data, two people on devrel. Our advocate Tomas wants to commit to 9 blog posts a month next quarter, he says he can write one a day when he's in the zone. Our writer Hana says 3 substantial posts a month is the honest number. My VP found some industry figure saying developer advocates do 1 to 2 posts a month and now wants to cut Hana down to 2. Who's right and what number do I put in the plan?",
"expected_output": "Tomas's 9 is challenged against the published one-to-two figure, the same figure is explicitly refused as a cap on Hana's 3, the figure is sourced to one company's pre-pipeline output with its caveats, and Northwind's own last-quarter numbers are requested as the number that actually settles it.",
"files": [],
"expectations": [
"Challenges the 9-posts-a-month commitment.",
"Cites one to two blog posts per advocate per month as the published figure.",
"Attributes that figure to a single company's stated output before it built a content-scaling pipeline, not to an industry average.",
"Refuses to use the figure to cut Hana's estimate of 3 substantial posts a month.",
"States explicitly that the figure is a challenge tool and not a ceiling.",
"Names the caveats on the figure: one company, security tooling, an SEO-led programme.",
"Points out that an advocate who also runs events and answers the community does not write four substantial posts a month.",
"Requires an explanation for any estimate far above the figure: a dedicated writer, an agency, or smaller formats.",
"Asks for Northwind's own last-quarter published numbers and says they beat any default figure.",
"Proposes smaller formats rather than substantial posts if the higher volume is kept.",
"Does not split the difference between 9 and 3 into an averaged compromise number."
]
},
{
"id": 4,
"prompt": "Q3 planning, Cindershift, we make an observability agent. Three things are locked: v5 GA in week 5, our advocate Raoul has an accepted talk at ObserveCon in week 9, and we run community office hours the last Thursday of every month. We also just signed a content agency, briefed them last week so they start around week 2, and I've given them two pieces: the v5 launch post which needs to be live week 5, and a benchmark post with no date attached. Lay out the quarter around all of that.",
"expected_output": "The agency's v5 launch post is pulled back in-house because external writing runs 8-9 weeks, the undated benchmark goes to the agency instead, every anchor gets both a preparation and a follow-up slot, and the ObserveCon derivatives are scheduled as their own capacity-consuming slots behind one canonical URL.",
"files": [],
"expectations": [
"States that the agency cannot deliver the v5 launch post for week 5, because outside writing runs roughly 8 to 9 weeks from conception to publication.",
"Moves the timed launch post in-house and gives the agency the undated benchmark piece instead.",
"Warns that outsourcing does not relieve capacity this quarter, and that standing up an external pipeline costs roughly six months of a director's own time.",
"Counts internal passes for outline and review against the agency piece rather than treating it as free capacity.",
"Gives each of the three anchors both a preparation slot and a follow-up slot.",
"Schedules the ObserveCon derivatives as their own dated slots: recording, write-up, clips, and a docs update.",
"Treats those derivatives as consumed capacity rather than free extra output.",
"Keeps one canonical URL per topic, with the derivatives linking back to it.",
"States that anchors are consumed capacity rather than opportunities.",
"Marks the weeks around week 9 as absorbed by Raoul's talk preparation.",
"Keeps the anchor-bound share bounded so a slipped v5 date does not take the quarter with it.",
"Records each anchor's class (release, conference, community event) and its owner."
]
},
{
"id": 5,
"prompt": "Review my Q4 plan before I send it round. Structure is: month 1 is all top-of-funnel awareness posts to get people in the door, month 2 is tutorials so they actually try it, month 3 is migration and scaling content for the ones who converted. Funnel order, clean. Everything goes on the blog, that's where all our traffic is and the docs site gets almost nothing. Context: Loomstack, we sell a data pipeline runtime. Individual devs usually find us first through search, but the people who sign the contract are platform team leads at companies of 200 to 2000 people. Anything you'd change?",
"expected_output": "The month-by-month funnel sequencing is rejected because readers enter at any depth, journey stages are reframed as a quarter-wide coverage check, the blog-only plan is broken across at least three surfaces with approver material routed to an evaluation page, and the two audiences get separately labelled slots.",
"files": [],
"expectations": [
"Rejects the month-by-month funnel sequencing of journey stages.",
"States that readers enter a topic at whatever depth suits them rather than walking the stages in order.",
"Attributes the playground mindset to Ashley Faus.",
"Treats journey-stage labels as a coverage check across the whole quarter rather than as a path the reader walks.",
"Requires the plan to cover at least three distinct surfaces and at least two journey stages.",
"Flags the blog-only plan as leaving adoption blocked in docs nobody planned.",
"Routes approver-facing evaluation material to an evaluation page rather than to a blog post.",
"Gives individual adopters and platform-team approvers their own separately labelled slots.",
"States that one blended piece answers neither audience.",
"Names what the platform-team slots must answer: licence, security posture, release cadence, migration cost, support path.",
"Names what the individual-adoption slots sell: time-to-first-success and runnable demos.",
"Writes the mix as percentages of slots rather than of hours."
]
},
{
"id": 6,
"prompt": "Two things. First, the ratio: I keep reading that the standard split is 80% evergreen and 20% trending, is that the right target for a devtools blog? Second, here's the idea pile for next quarter at Ferrite (we make a CI runner), tell me what makes the cut: '7 tips for faster builds', 'Why we love open source', 'How we cut p99 queue latency by rewriting the scheduler in Rust', and support had 34 tickets last quarter about the same 'agent handshake timeout' error. A consultant we spoke to said we should structure the year around Hero, Hub and Help content, worth doing?",
"expected_output": "The 80/20 ratio is refused as a benchmark and replaced with the compounding mechanism, Hero/Hub/Help is rejected as a video-channel model, the two evidence-free ideas are cut against the novelty filter, and the 34-ticket error is classified as a defect and routed to a troubleshooting page.",
"files": [],
"expectations": [
"Refuses to present 80% evergreen / 20% trending as a benchmark or an industry standard.",
"Identifies that ratio as circulating from creator-economy material that carries none of the review cost technical content carries.",
"Gives the mechanism instead: evergreen pieces keep earning search traffic and support deflection after the release that prompted them, which is what makes the next quarter cheaper.",
"Rejects Hero / Hub / Help, and says it is built for a brand's video channel rather than for docs and release notes.",
"Rejects '7 tips for faster builds' and 'Why we love open source' as slots carrying neither evidence nor a hypothesis.",
"States the novelty filter a bet slot must pass: counter-intuitive, counter-narrative, surprising, or an elegant articulation of something readers already feel.",
"Requires a written hypothesis on every bet slot and attached evidence on every demand-sourced slot.",
"Classifies the 34-ticket handshake timeout as a docs or product defect rather than merely a missing page, and says which of the two.",
"Contrasts that with a question asked three times, which is a missing page.",
"Routes the handshake timeout to a troubleshooting page keyed on the error string rather than to a blog post.",
"Proposes testing the scheduler-rewrite idea in a cheaper format first, before it earns an expensive production slot.",
"Does not attribute the cheapest-format-first idea to a named individual."
]
},
{
"id": 7,
"prompt": "Our Q4 calendar goes out to the wider team on Monday so I can't redo it from scratch, but something is off. Here it is, Rivetline (feature flag service), 13 weeks: W1 'Rivetline 4.0 is here', W2 '5 things you didn't know about feature flags', W3 'Our journey to 99.99%', W4 'Why flags beat branches', W5 'Meet the team', W6 'Rivetline joins the CNCF sandbox', W7 'v6 release, everything new' (v6 GA is week 7, our only hard date), W8 'Flag hygiene tips', W9 'Customer spotlight: Acme', W10 'Announcing our new pricing', W11 'The future of progressive delivery', W12 'Year in review', W13 'What's coming in 2027'. The owner column says 'content team' on every row. Every week is filled, no gaps. What's wrong and what's the minimum I change?",
"expected_output": "An audit rather than a rebuild: the existing rows scored against the pass thresholds, failures listed in damage order starting with the unnamed owner and reviewer, and the smallest set of changes that clears them.",
"files": [],
"expectations": [
"Scores the existing calendar against the pass thresholds instead of rebuilding it from scratch.",
"Reports the failures in damage order.",
"Proposes the smallest set of changes that clears the failures.",
"Flags 'content team' as neither an owner nor a named reviewer, and requires a named person in both roles on every row.",
"Flags the single-surface plan: thirteen blog slots, with no docs, changelog or video surface.",
"Flags that 100% of capacity is committed, and requires roughly 20% held open as named slack.",
"Flags the missing preparation slot and missing follow-up slot for the week-7 v6 GA.",
"Flags the timely-only mix, which resets the quarter to zero.",
"Flags the announcement and product-promotion share against a cap the user has to agree.",
"Flags that no slot carries a surface, pillar, journey stage or evergreen/timely label.",
"Flags slots carrying neither evidence nor a stated hypothesis, naming at least one such as '5 things you didn't know about feature flags' or 'Meet the team'.",
"Notes that v6 is the only anchor and carries most of the quarter's capacity, so a slip takes the quarter with it.",
"Does not deliver a rewritten 13-week calendar as the deliverable."
]
},
{
"id": 8,
"prompt": "Last quarter our best post by a mile was a same-day writeup of that big CVE, 26,000 sessions. Our normal deep technical posts do about 900. My CEO now wants four 'news reaction' slots in next quarter's calendar to repeat it. Two questions: how do I build those into the plan, and what do I report to him at the end of each month so he can see the calendar is working? Also while you're here, draft me the first news post so I have something to show him. Company is Stavepoint, we do runtime security for containers.",
"expected_output": "The four news slots are refused and converted into named unassigned slack, the session gap is cited as the argument for slack rather than for scheduling news, the monthly report is built from plan-level metrics rather than per-piece traffic, and the drafting request is handed off as out of scope.",
"files": [],
"expectations": [
"Refuses to create four scheduled news-reaction slots.",
"States that a reactive piece of that size lands once or twice a year and cannot be scheduled in advance.",
"Converts the CEO's request into unassigned slack instead, roughly 20% of capacity held open.",
"Names who is allowed to spend the slack.",
"Cites the measured gap, around 1,000 sessions for a deep technical piece against up to 30,000 for a reactive news piece, as the case for holding slack rather than for planning news slots.",
"Reports publish rate, published divided by slotted, as the planning-accuracy metric.",
"Reports mix drift: actual versus intended ratios, checked at the monthly review.",
"Reports anchor coverage: the share of anchors that got both a preparation and a follow-up slot.",
"Reports slot lead time, the days between 'ready for review' and published, as what exposes the bottleneck.",
"Does not offer per-piece session or traffic counts as the calendar's own measure of success.",
"Declines to draft the news post, and says producing an individual piece belongs to a per-format skill rather than to the quarter plan.",
"Defines the monthly review's three questions (what shipped versus slotted, has the mix drifted, which pieces earned a follow-up) together with its kill and defer rules."
]
}
],
"trigger_queries": [
{ "query": "Plan our Q3 devrel content calendar", "should_trigger": true },
{ "query": "we need an editorial calendar for our developer blog next quarter", "should_trigger": true },
{ "query": "what should we publish next quarter", "should_trigger": true },
{ "query": "our content plan keeps slipping, nothing ships in the last month of the quarter", "should_trigger": true },
{ "query": "honestly we just publish randomly whenever someone has a spare afternoon", "should_trigger": true },
{ "query": "how many blog posts can a two-person team actually ship in a quarter", "should_trigger": true },
{ "query": "how do I balance evergreen content against launch-tied content", "should_trigger": true },
{ "query": "build me a dated slot plan for our developer content for Q1", "should_trigger": true },
{ "query": "here's our current content calendar, tell me what's wrong with it", "should_trigger": true },
{ "query": "we have a release in week 4 and two conferences, how do I schedule writing around them", "should_trigger": true },
{ "query": "everything is stuck in review and nothing actually gets published", "should_trigger": true },
{ "query": "our calendar has drifted into nothing but product announcements", "should_trigger": true },
{ "query": "I need to decide what my devrel team writes for the next three months", "should_trigger": true },
{ "query": "one writer, one reviewer at four hours a week, twelve weeks. what can we actually ship?", "should_trigger": true },
{ "query": "how much content should we plan around our 2.0 launch", "should_trigger": true },
{ "query": "give me a quarterly publishing plan covering our SDK docs and our blog", "should_trigger": true },
{ "query": "who should own each piece of content next quarter", "should_trigger": true },
{ "query": "we keep writing blog posts but adoption isn't moving at all", "should_trigger": true },
{ "query": "how do I stop the blog becoming a dumping ground for things that belong in the docs", "should_trigger": true },
{ "query": "plan the content for our open source project for the next quarter", "should_trigger": true },
{ "query": "should we do a launch-heavy quarter or keep building evergreen guides", "should_trigger": true },
{ "query": "our advocate is speaking at three conferences, how do I plan the writing around that", "should_trigger": true },
{ "query": "content roadmap for a devtools company, next 13 weeks", "should_trigger": true },
{ "query": "we never schedule anything after a launch and the momentum just dies", "should_trigger": true },
{ "query": "help me size how much technical content we can produce with only one engineer reviewing", "should_trigger": true },
{ "query": "I want a publishing cadence my team can actually hold", "should_trigger": true },
{ "query": "what mix of docs, blog and video should we aim for next quarter", "should_trigger": true },
{ "query": "we have 40 content ideas and no idea which ones to schedule", "should_trigger": true },
{ "query": "how do I plan writing when half of it depends on an engineer who is always busy", "should_trigger": true },
{ "query": "quarterly plan for our developer content with owners and deadlines on every item", "should_trigger": true },
{ "query": "we publish about 40% of what we plan, what am I doing wrong", "should_trigger": true },
{ "query": "map out what the devrel team ships between now and the end of the year", "should_trigger": true },
{ "query": "is it worth holding open slots for reactive content", "should_trigger": true },
{ "query": "how far ahead do I need to book a freelance writer for a release post", "should_trigger": true },
{ "query": "we outsourced two posts and both of them missed the launch date", "should_trigger": true },
{ "query": "I need a content schedule that survives the release date slipping", "should_trigger": true },
{ "query": "plan a quarter of technical content aimed at platform engineers evaluating us", "should_trigger": true },
{ "query": "we're a three person devrel team, what does a realistic quarter actually look like", "should_trigger": true },
{ "query": "editorial planning for our API blog and changelog", "should_trigger": true },
{ "query": "our engineering posts all come out in one burst then nothing for two months", "should_trigger": true },
{ "query": "how should I split what we write between individual developers and the teams that buy", "should_trigger": true },
{ "query": "set up a monthly review ritual for our content plan", "should_trigger": true },
{ "query": "which pieces should we refresh versus write new next quarter", "should_trigger": true },
{ "query": "write the v3 migration guide for our breaking changes", "should_trigger": false },
{ "query": "draft the release notes for tag v2.4.0", "should_trigger": false },
{ "query": "write a technical blog post about our scheduler rewrite", "should_trigger": false },
{ "query": "help me write a CFP proposal for KubeCon", "should_trigger": false },
{ "query": "turn my accepted talk abstract into a rehearsable outline", "should_trigger": false },
{ "query": "write a script for a five-minute product screencast", "should_trigger": false },
{ "query": "which conferences should we sponsor next year and at what tier", "should_trigger": false },
{ "query": "how should I split our devrel budget across events, content and community", "should_trigger": false },
{ "query": "design our developer relations program from the top, what business driver funds it", "should_trigger": false },
{ "query": "which devrel metrics should we report to the board", "should_trigger": false },
{ "query": "set up analytics tracking across our docs site and our repositories", "should_trigger": false },
{ "query": "audit our documentation structure against Diataxis", "should_trigger": false },
{ "query": "write a quickstart that carries someone from zero to first success", "should_trigger": false },
{ "query": "build a keyword list for the error strings developers search for", "should_trigger": false },
{ "query": "run technical SEO on our versioned documentation site", "should_trigger": false },
{ "query": "map the developer journey for our enterprise segment stage by stage", "should_trigger": false },
{ "query": "plan a monthly content calendar for our ecommerce brand's Instagram", "should_trigger": false },
{ "query": "build a social media posting schedule for our B2C skincare launch", "should_trigger": false },
{ "query": "I need an editorial calendar for our internal HR newsletter", "should_trigger": false },
{ "query": "create a 12-month SEO content plan for a local plumbing business", "should_trigger": false },
{ "query": "plan the agenda for our internal engineering all-hands", "should_trigger": false },
{ "query": "design a recurring developer meetup and its speaker pipeline", "should_trigger": false },
{ "query": "write a case study about how Acme deployed us in production", "should_trigger": false },
{ "query": "plan our open source project's launch day on Hacker News", "should_trigger": false },
{ "query": "set up an issue and pull request triage system for our repo", "should_trigger": false },
{ "query": "design an ambassador program with perks for our top community members", "should_trigger": false },
{ "query": "write our community code of conduct and the moderation ladder behind it", "should_trigger": false },
{ "query": "should we launch a Discord or a forum, and how do we seed it", "should_trigger": false },
{ "query": "which health metrics tell me whether our community is actually alive", "should_trigger": false },
{ "query": "rewrite our repo README so a stranger can tell what it is and run it", "should_trigger": false },
{ "query": "plan the sprint backlog for the platform team next quarter", "should_trigger": false },
{ "query": "what should I share weekly if we build in public", "should_trigger": false },
{ "query": "prepare me for a podcast interview next Thursday", "should_trigger": false },
{ "query": "pitch our funding round to reporters on the infrastructure beat", "should_trigger": false },
{ "query": "design a learning path and certification program for our platform", "should_trigger": false },
{ "query": "benchmark a competitor's developer relations motion from public signals", "should_trigger": false },
{ "query": "write a tutorial teaching webhooks step by step", "should_trigger": false },
{ "query": "set the standards every code sample in our docs has to meet", "should_trigger": false },
{ "query": "help me plan my own move into a developer advocacy role", "should_trigger": false },
{ "query": "write the job posting and interview loop for a developer advocate hire", "should_trigger": false },
{ "query": "cut our developer audience into a few named, sized segments", "should_trigger": false },
{ "query": "plan a content calendar for our sales team's LinkedIn outreach", "should_trigger": false },
{ "query": "schedule our marketing email nurture sequence for the next quarter", "should_trigger": false }
]
}
references/mix-and-capacity-model.md›
# Mix and capacity model
Reference for steps 2-5 of the workflow: what the mix axes are, how the funding driver sets the ratios, what each format costs, and where topics come from.
## Contents
- Mix axes
- Ratios by funding driver
- Format cost bands
- Demand signals and bets
- Routing a topic to the right surface
## Mix axes
| Axis | Values | Unbalanced result |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------- |
| Surface | docs page, quickstart, tutorial, reference update, blog post, changelog/release notes, video/screencast, conference talk, community post or AMA, newsletter, sample repo | Blog-only plan: adoption blocked in docs nobody planned |
| Pillar | advocacy, marketing, enablement, community | Everything lands in marketing; enablement debt grows unnoticed |
| Journey stage | discover, try, adopt, contribute, advocate | Discover-only plan: traffic without activation |
| Shelf life | evergreen (survives the next release), timely (release/event/news-bound) | Timely-only plan resets to zero each quarter |
| Audience | individual adopter, buying organisation, ecosystem segment, new vs. existing user | One blended voice answers neither audience |
Write the ratios as percentages of slots, not of hours - hours hide the fact that one talk costs six blog posts.
## Ratios by funding driver
The mix follows the reason the program is funded. Use this as a starting point, then adjust with the user; never present it as a fixed standard.
| Driver | Weight toward | Typical anchor of the quarter |
| --------------------------------------------------------- | ----------------------------------------------------------------------------- | ----------------------------------- |
| Developer adoption (developers are the buyers) | enablement + try/adopt stage, self-serve paths | product releases |
| Sales enablement (developers evaluate, someone else buys) | evaluation material for approvers: security, licence, cadence, migration cost | proof points and comparison content |
| Enablement of existing users | docs, troubleshooting, migration guides, tutorials | version releases and deprecations |
| Product feedback | community-facing formats that generate conversation | previews, RFCs, office hours |
| Ecosystem and partners | integration guides, sample repos, partner co-content | partner launches |
| Contributor community | contributor onboarding, governance posts, roadmap transparency | release cycles and community events |
| Employer branding | engineering deep dives, architecture and incident write-ups | conferences |
Sanity checks apply to every driver:
- Majority of slots evergreen, unless the quarter is deliberately launch-dominated.
- A capped share for announcements.
- At least one slot serving each audience the user named.
The evergreen-majority rule is this skill's working baseline rather than a measured optimum - present it that way, and drop it the moment the team has its own decay data.
## Format cost bands
Estimate in passes, not drafting hours. A pass is one of:
- Research.
- Drafting.
- Writing code that must run.
- Technical review by someone who can dispute the claims.
- Assets (diagrams, screenshots, recordings).
- Publishing.
- The post-publication reply load.
| Format | Distinguishing cost | Usual bottleneck |
| ----------------------------------------------------- | ----------------------------------------------------------------- | -------------------------------------------------------------------- |
| Changelog entry / release note | Small, but tied to the release date | Release engineering |
| Short community post or AMA | Low production, high reply load | Author availability after publishing |
| Docs page or troubleshooting page | Correctness review, canonical placement | Docs review queue |
| Quickstart | Cold-run verification on a clean machine | Test environment |
| Engineering blog post | Claim-to-evidence checking | Technical reviewer |
| Tutorial | Working code plus checkpoint verification at every step | Reviewer plus environment |
| Benchmark or migration guide | Reproducible measurements, honest limitations | Engineering time, and it fails late |
| Video/screencast | Recording, editing, re-record cost after any product change | Editing capacity |
| Conference talk | Deadline is external, preparation compresses into the final weeks | Speaker's calendar |
| Anything written outside the team (agency, freelance) | Outline and review still cost internal passes | Round-trip latency, eight to nine weeks in the one published account |
Two lead times are systematically underestimated:
- Review by people who do not report to the content owner.
- Anything requiring code that must actually run.
A per-person reality check before committing the plan: the only published devrel figure puts an advocate at one to two blog posts a month before any production pipeline exists. An estimate far above that needs an explanation - a dedicated writer, an agency, or smaller formats.
## Demand signals and bets
Demand-sourced slots (evidence required):
- Repeated support tickets and their resolution notes.
- Questions asked more than twice in the community channel or public Q&A.
- Issues filed against the same confusion; docs-site searches returning nothing.
- Error telemetry - the only signal showing failures nobody reported.
The volume sets the label:
- A question asked three times is a missing page.
- A question asked thirty times is a docs or product defect; say which in the slot.
Bet slots (hypothesis required) must pass a novelty filter. An idea passing none of the criteria below produces an accurate, unread piece:
- Counter-intuitive.
- Counter-narrative.
- Surprising.
- An elegant articulation of something readers already feel.
Deliberate repetition across surfaces is coverage, not waste - developers discover content through different channels and almost nobody sees all of them. Keep one canonical URL per topic so search authority is not split.
## Routing a topic to the right surface
| Signal | Surface |
| -------------------------------------------- | -------------------------------- |
| A step in the product is broken or unclear | Docs fix |
| A specific error string | Troubleshooting page |
| "How do I do X end to end" | Tutorial |
| "How do I get started at all" | Quickstart |
| "Why is it built this way" / trade-off story | Engineering blog post |
| Version-specific change | Release notes or migration guide |
| Decision-stage comparison for an approver | Evaluation page, not a blog post |
Choosing the surface at planning time is what stops the blog from becoming the dumping ground for content that belongs in the docs.
references/published-findings.md›
# Published findings and self-set baselines
Every number and named idea this skill quotes, with its source and its limits. Read this before defending a figure to a user, and before adding a new one.
## Contents
- Throughput and lead times (case study)
- The 80/20 planning convention
- Ratios that are folklore
- This skill's own baselines
- Named ideas: kept, rejected, unattributed
- Sources
## Throughput and lead times (case study)
Source: Matt Jarvis, Director of Developer Relations at Snyk, "Scaling developer content production at Snyk", developerrelations.com case study (page undated).
| Figure | Stated as | Use it for |
| ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
| "one or maybe two blog posts per month" per developer advocate | The team's output _before_ it built a scaling pipeline | Challenging an optimistic estimate. An advocate who also runs events and answers the community does not write four substantial posts a month |
| 8-9 weeks, conception to publication, when a third party writes | Their measured pipeline latency | Booking agency or freelance work against an anchor date |
| ~6 months of the director's own time to industrialise the pipeline | Setup cost before volume | Warning a user that outsourcing does not relieve this quarter |
| ~1,000 sessions for a deeper technical piece, ~half for an introductory one, in the month after publication | Their forecasting model | Ranking formats by return when the goal is search-driven reach |
| Up to 30,000 sessions for a reactive news piece, "once or twice a year" | Observed, from their Log4Shell coverage | Justifying unassigned slack. The best piece of the quarter is often unplannable |
Caveats: one company, security tooling, SEO-led programme. The traffic numbers depend entirely on that company's domain authority and say nothing about what a new project should expect.
## The 80/20 planning convention
Two widely distributed planning skills land on the same split:
- `anthropics/knowledge-work-plugins@capacity-plan`: IC/specialist target utilisation 75-80%, and "Target 80% utilization. 100% means no room for surprises."
- `anthropics/knowledge-work-plugins@campaign-plan`: "build in flexibility: leave 20% of calendar slots open for reactive or opportunistic content."
That convergence makes 80/20 a defensible default and nothing more. Both count in writer hours or campaign slots rather than reviewer passes - the constraint that actually binds a developer-content plan.
The same campaign skill publishes production timings (blog post 3-5 business days, landing page 5-7, video 2-4 weeks). Treat them as a floor for developer content: they assume no SME review and no code that has to run.
## Ratios that are folklore
An 80% evergreen / 20% trending split circulates widely in creator-economy material, adjusted to roughly 60/40-70/30 for fast-moving technical niches. The material that carries it describes it as "the widely-reported baseline among solo creators": short-form video accounts, with none of the review cost technical content carries.
Cite the mechanism instead: evergreen pieces keep earning search and support deflection after the release that prompted them, which is what makes the next quarter cheaper. Never quote the ratio as a benchmark.
## This skill's own baselines
State these as proposals, not findings, and replace them with the team's real numbers whenever those exist:
| Baseline | Why this value | What would replace it |
| ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| Publish rate ≥ 80% | Matches the 80/20 capacity convention: if you committed 80% of capacity, you should be shipping what you committed | Last quarter's actual published ÷ slotted |
| Evergreen majority outside a launch-dominated quarter | Follows from the compounding argument above, not from a measured optimum | The team's own decay curve: how long a piece keeps earning |
| At least three surfaces, at least two journey stages | A coverage floor, chosen so a single-surface plan fails the check loudly | The surfaces the audience actually uses, from analytics |
| Announcement cap agreed per quarter | The defensible number is team-specific; forcing the user to name one is the point | Whatever the user commits to in step 3 |
| Evergreen-compounding ranked first among the three quarter shapes | Capacity judgement, not a measurement: it is the cheapest shape to run and the only one that compounds, and it ranks first partly to counter the deadline pressure that starves it | The team's own record of what actually shipped per shape, and what each shape returned |
## Named ideas: kept, rejected, unattributed
**Kept - the playground mindset.** Ashley Faus (Atlassian; author of _Human-Centered Marketing_) on her own site: "The buyer's journey is broken. It was never linear, but we need to shift to the playground mindset." Readers enter a topic at whatever depth suits them rather than walking a funnel. This is why journey-stage labels in the slot table are a coverage check, not a claim about reader order.
**Kept - demand-driven sourcing.** "Using support questions to feed your content calendar" (Matthew Revell, developerrelations.com, 2018-10-04) documents the pipeline:
- Find where developers already ask.
- Assign the monitoring.
- Categorise by product area.
- Convert repeats into content in several formats.
- Measure and repeat.
It carries Martyn Davies on the fear of covering the same ground twice - "repetition isn't a risk - it's a necessity" - because developers discover content through different channels and almost nobody sees all of them. Repeat the topic across surfaces and keep one canonical URL.
**Rejected - Hero / Hub / Help.** Google's 3H video model is frequently name-dropped in content-planning material, but it is built for a brand's video channel rather than for docs and release notes. Leave it out.
**Unattributed - the cost ladder.** Test an idea in the cheapest format first and promote only the winners up the production-cost ladder. Circulates attributed to Alex Hormozi, unverified. Use the mechanism for bet slots - a community post or a talk pitch is a cheap test before a topic earns an expensive tutorial slot - and skip the attribution.
## Sources
- Matt Jarvis / Snyk, "Scaling developer content production at Snyk", developerrelations.com case study.
- Matthew Revell, "Using support questions to feed your content calendar", developerrelations.com, 2018-10-04.
- Ashley Faus, ashleyfaus.com.
- `anthropics/knowledge-work-plugins`, skills `campaign-plan` and `capacity-plan`.
references/quarterly-plan-example.md›
# Worked example: one quarter, planned well and planned badly
Illustrative plan for a fictional team: three people (one writer, one advocate, one engineer who reviews at 4 hours/week) on a self-hostable job-queue product with a hosted tier. Funding driver: developer adoption, with existing-user enablement second. Audiences: individual adopters and platform teams introducing it at work.
## Contents
- Section 1: anchors
- Section 2: mix ratios
- Section 3: capacity model
- Section 4: slot table
- Section 5: review ritual and metrics
- Negative example
## Section 1: anchors
| Date | Anchor | Class | Owner | Consumes |
| ---- | -------------------------------- | ---------- | -------- | ------------------------------------------------- |
| W2 | v3.0 release (breaking changes) | release | engineer | release notes, migration guide, upgrade docs |
| W4 | CFP deadline, ScaleConf | CFP | advocate | proposal + abstract |
| W6 | Managed-tier pricing change | launch | writer | announcement + FAQ + docs |
| W9 | ScaleConf talk (if accepted) | conference | advocate | slides, demo, companion post, recording follow-up |
| W11 | Upstream runtime LTS release | ecosystem | engineer | compatibility note |
| W12 | Community office hours (monthly) | community | advocate | promotion + Q&A write-up |
Freeze: W6 (pricing announcement week) - no unrelated publishing. W13: holiday coverage gap, plan nothing.
## Section 2: mix ratios
Twelve committed slots plus three slack slots.
| Axis | Target | Rationale |
| ---------- | ---------------------------------------------------------- | ------------------------------------------------------------------ |
| Surface | docs 35%, blog 30%, changelog 15%, video 10%, talk 10% | Adoption driver puts docs first; video capped by editing capacity |
| Pillar | enablement 45%, marketing 25%, advocacy 20%, community 10% | Enablement debt from the v3 migration |
| Stage | discover 20%, try 25%, adopt 40%, contribute 15% | Existing users must survive v3 before new ones arrive |
| Shelf life | evergreen 60%, timely 40% | Release-heavy quarter; timely share accepted above the usual floor |
| Audience | individual 50%, platform team 40%, both 10% | Hosted tier makes the approver audience real |
Announcement cap: 2 slots.
## Section 3: capacity model
- Writer: 12 h/week of production time → roughly 1 substantial piece per 2 weeks plus small pieces.
- Advocate: 6 h/week outside events; W8-W9 fully consumed by the talk.
- Engineer reviewer: 4 h/week - the binding constraint. Two review-heavy pieces per month, maximum.
- Slack: 3 unassigned slots (W5, W8, W11) for incident write-ups, upstream breakage, or a slipped anchor.
Consequence recorded at planning time: the benchmark post proposed for W7 was cut, because it needs the same reviewer as the migration guide in the same fortnight.
## Section 4: slot table
| Week | Working title | Surface | Pillar | Stage | Shelf life | Anchor | Owner | Reviewer | Evidence / hypothesis |
| ---- | ------------------------------------------------- | ---------- | ---------- | ---------- | ---------- | ------------ | -------- | ------------ | ----------------------------- |
| W1 | v3 upgrade path: what breaks and why | docs | enablement | adopt | evergreen | v3.0 | writer | engineer | 14 tickets on failed upgrades |
| W2 | v3.0 release notes | changelog | enablement | adopt | timely | v3.0 | engineer | writer | release |
| W3 | Migrating a 200-worker fleet without downtime | blog | enablement | adopt | evergreen | v3.0 | writer | engineer | top forum thread, 40 replies |
| W4 | ScaleConf proposal (not published) | talk | advocacy | discover | timely | CFP | advocate | writer | CFP deadline |
| W5 | _slack_ | - | - | - | - | - | - | - | reactive buffer |
| W6 | Pricing change: what it means for self-hosters | blog + FAQ | marketing | adopt | timely | pricing | writer | founder | announcement |
| W7 | "Queue stuck at retry limit" troubleshooting page | docs | enablement | adopt | evergreen | - | writer | support lead | 31 tickets, same error string |
| W8 | _slack_ (talk preparation absorbs advocate) | - | - | - | - | ScaleConf | - | - | - |
| W9 | Talk companion post + slides link | blog | advocacy | discover | timely | ScaleConf | advocate | writer | talk lands same week |
| W10 | Recording + 3 clips + Q&A write-up | video | advocacy | discover | timely | ScaleConf | advocate | writer | follow-up window |
| W11 | _slack_ / runtime LTS compatibility note | changelog | enablement | adopt | timely | ecosystem | engineer | writer | upstream date |
| W12 | Refresh: quickstart cold-run for v3 | docs | enablement | try | evergreen | - | writer | engineer | quickstart drifted at v3 |
| W12 | Office-hours Q&A digest | community | community | contribute | evergreen | office hours | advocate | - | recurring ritual |
Repurposing tree for the ScaleConf anchor:
1. Talk.
2. Recording.
3. Clips.
4. Companion post.
5. A troubleshooting page from the audience questions.
6. A slide-derived diagram reused in the migration docs.
Validation result: evergreen 6/12 slots (60%, matches the accepted launch-heavy target), announcements 2/12 (at cap), committed capacity 12 of 15 slots (80%), every slot owned and reviewed, every anchor with preparation and follow-up. Passes.
## Section 5: review ritual and metrics
Monthly, 30 minutes, three questions: what shipped versus slotted, has the mix drifted, which pieces earned a follow-up. Kill rule: a piece whose anchor has passed or that has been re-drafted twice without converging gets cut, out loud. Defer rule: at most one deferral per piece, then it is cut.
Tracked: publish rate (target ≥ 80%), mix drift per axis, anchor coverage, and lead time from "ready for review" to published.
## Negative example
The same quarter, planned the way it usually goes wrong:
| Week | Title | Owner |
| ---- | ------------------------ | ----- |
| W1 | v3 is here! | team |
| W2 | 5 tips for faster queues | team |
| W3 | Why we love open source | team |
| W4 | v3 deep dive | team |
| ... | one blog post per week | team |
What is wrong with it, in order of damage:
1. **No owner or reviewer** - "team" means nobody; every piece stalls at review with no name attached.
2. **One surface** - a v3 with breaking changes and zero docs or migration slots pushes the whole upgrade burden into support.
3. **No anchors beyond the release** - the CFP deadline is missed and the conference talk arrives unprepared.
4. **No evidence** - "5 tips" and "why we love open source" answer no observed question and pass no novelty filter.
5. **No slack** - the first incident or upstream breakage eats a planned slot, and everything after it slides.
6. **No follow-up slots** - the talk, the launch and the release each produce material nobody scheduled.
7. **100% of capacity committed** - publish rate lands far below target, and the team concludes it is bad at writing rather than bad at estimating.
SKILL.md›
---
name: devrel-content-calendar
description: 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.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# DevRel Content Calendar
You are a developer-relations content planner. You turn a pile of ideas, fixed dates, and limited reviewer time into a dated quarterly plan the team can actually ship.
Content plans do not fail for lack of ideas. They fail on capacity - review passes nobody counted - and on slots nobody owns. Make both constraints explicit before the calendar exists, then keep the calendar inside them.
## Interview
Ask these one at a time, multiple-choice when possible, and stop once you can fill the plan. Never draft a calendar from assumptions - a wrong audience or an invisible reviewer bottleneck invalidates every slot.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. What is the product or project, and which quarter are we planning?
2. Why is developer relations funded here - adoption, sales enablement, enablement of existing users, product feedback, ecosystem/partners, contributor community, or employer branding?
3. Who is the target reader: individual developers adopting for themselves, teams introducing the tool at work, or both?
4. Which surfaces do you own and can publish to (docs, blog, changelog, video, sample repos, community channels, newsletter, conference stages)?
5. Which dates are already fixed - releases, launches, CFP deadlines, conferences, meetups, ecosystem events?
6. Is there a date the quarter's outcome has to be visible by - a board review, a funding decision, a launch, a renewal - or is the quarter judged at its end?
7. Do you want a one-off win this quarter, or an asset base that makes next quarter cheaper? If the answer is both, say which one gets sacrificed when they collide in week 8 - because they will.
8. What is the effort ceiling: writer weeks, reviewer passes available per week, and whether anyone can travel?
9. What shipped last quarter, what performed, and what slipped? Actual numbers beat any default in this skill.
10. What is off-limits: unannounced features, embargoed customers, security-sensitive topics, comparisons with named competitors?
11. What does success look like in one sentence, and how is it measured today?
Question 7 carries more weight here than in any other planning skill: it is the whole difference between the two value orderings below, and answering it late means re-planning the quarter rather than re-ranking it.
- A near, visible date promotes the launch-dominated quarter.
- A compounding answer promotes evergreen, the only answer that survives a slipped launch.
- An effort ceiling with no travel deletes the event-led quarter outright.
If you can read the user's existing files and a documented audience profile or program strategy already exists, read it first and ask only about the gaps.
## Choosing the quarter's shape
Before any dates get placed, present the candidate shapes in the ranked order below, say the ranking out loud, recommend the top one, and wait for a decision. Effort here is capacity: writer weeks, reviewer passes, coordination with people outside the team, and travel. Rows are in efficiency order.
| Shape | Capacity cost | What it buys this quarter | What it buys a year out | Fails when |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------ |
| Evergreen-compounding (default) | a week per piece, one reviewer, nothing outside the team | little that is visible; the results arrive after the quarter closes | the only shape that compounds - next quarter starts with the explainers already written | the team is judged on this quarter alone |
| Launch-dominated | a quarter of committed capacity locked to one date, plus product and marketing coordination and their review chain | the highest peak attention available; the one week the audience is already looking | close to nothing - the pieces age with the release they described | the date slips, and it takes the quarter with it |
| Event-led | a quarter of capacity, plus travel weeks nobody counts, plus a standing job keeping a speaker pipeline alive | reach, recruiting and relationships that no written piece reaches | the recordings and write-ups, if someone schedules them as their own slots | the CFP outcomes you do not control come back rejected |
- efficiency: evergreen-compounding > launch-dominated > event-led
- value inside the quarter: launch-dominated > event-led > evergreen-compounding
- value a year out: evergreen-compounding > event-led > launch-dominated
- effort: event-led > launch-dominated > evergreen-compounding
- compliance cost: launch-dominated > event-led > evergreen-compounding
The two value lines are the point of this menu, not a hedge: the shape that wins the quarter and the shape that wins the year are different shapes, and a single blended rank would hide that.
Compliance cost by shape:
- Launch: runs on embargo - nothing publishes before the date, and product, legal and marketing all hold a veto that is exercised late.
- Event: carries the conference's own announcement rules and any sponsor obligations.
- Evergreen: carries none - it publishes when it is ready and can be corrected in place.
Evergreen-compounding leads the efficiency order because the calendar's own gravity works against it. Promotional and event work arrives with deadlines, sponsors and someone asking about it; evergreen work arrives with none of the three, so it is what gets pushed when week 8 goes wrong. Ranking it first is a correction, not a preference - give its slots hard dates and a named reviewer exactly as if a launch depended on them.
That order starves the launch quarter in turn, and the condition that promotes it is real: a launch that ships with no content around it wastes the single week the audience is actually paying attention, and no amount of evergreen recovers it.
- Promote launch-dominated when the release is the quarter's reason for existing, or when the visible-date question answered a board review or a funding decision.
- Promote event-led only when the talks are already accepted - an event-led quarter planned against pending CFP outcomes is a bet, and it should be named as one.
Delete a shape the constraints rule out rather than offering it as a third option, and say which you deleted, or it reappears in week 6 as work nobody planned:
- No launch in the quarter deletes the launch-dominated shape.
- No travel budget, or no accepted talk, deletes the event-led shape.
The order is a default, not a law: it shifts with context and with who executes it. Re-rank it against what this team already has:
- A library of evergreen pieces already written makes a launch quarter far cheaper, and moves it up.
- An advocate who is already a regular speaker on a circuit that has accepted them cuts most of the event-led shape's risk.
- A team with no technical reviewer available cannot run any shape at the cost stated here - fix that constraint before ranking anything.
Present the resulting plan section by section (anchors, mix, capacity, slots, review ritual) and get each validated before moving to the next. A calendar approved in one block gets renegotiated slot by slot later anyway.
## Workflow
1. **Collect anchors.** List every fixed date in the quarter with its class (release, launch, CFP deadline, conference, community event, ecosystem event) and its owner. Anchors are consumed capacity, not opportunities.
2. **Build the candidate pool.** Gather demand-sourced topics (repeated support tickets, community questions, issues, docs searches returning nothing) and bets (a hypothesis worth testing). Attach evidence to each demand item and a hypothesis to each bet. See [./references/mix-and-capacity-model.md](./references/mix-and-capacity-model.md).
3. **Set the mix.** Turn the funding driver and audience into explicit percentages across surface, pillar, journey stage and shelf life, and write the ratios down before placing anything. Treat journey-stage labels as a coverage check - does the plan serve every stage - never as a path the reader walks in order: readers enter at any depth (Ashley Faus's "playground mindset"; source and its limits in [./references/published-findings.md](./references/published-findings.md)).
4. **Size capacity in passes.** Estimate each format in passes - research, draft, working code, technical review, assets, publish, reply load - never in drafting hours, and name the reviewer per format. Reviewer passes, not writer hours, are what binds a developer-content plan.
5. **Sanity-check the estimate.** Compare the total against the published throughput figures below and against the team's own last quarter, then subtract named slack for reactive work.
6. **Place the calendar.** Anchor-bound pieces first with their preparation and follow-up slots, then evergreen slots, then refresh slots for decaying existing pieces, then the named slack. Every slot carries: title/working angle, surface, pillar, journey stage, shelf-life label, owner, reviewer, anchor (if any), evidence, publish week.
7. **Add the repurposing tree.** For each substantial piece, schedule every derivative it feeds as its own slot:
- Talk.
- Recording.
- Write-up.
- Clips.
- Docs update.
Repeat the topic across surfaces, but keep one canonical URL per topic.
8. **Validate.** Run the pass thresholds below. Iterate until every one passes - a plan that fails them is a wish list.
9. **Define the review ritual.** Fix a monthly plan review that asks:
- What shipped versus slotted.
- Has the actual mix drifted from the ratios.
- Which pieces earned a follow-up.
Include the kill and defer rules.
10. **Record the decisions.** If your environment has persistent memory, store the quarter's ratios, capacity model, anchors and kill rules, so the next planning run starts from them instead of re-interviewing.
## Benchmarks and baselines
Published benchmarks from devrel practice:
- **One to two blog posts per advocate per month** - Snyk's stated output before it industrialised content production. A challenge tool, never a ceiling: use it to question an estimate of eight posts a month, not to cap an estimate of three. See [./references/published-findings.md](./references/published-findings.md) for the source and its limits.
- **Eight to nine weeks** from conception to publication when an outside agency writes the piece, plus roughly six months of a director's own time to set that pipeline up - the same Snyk source's measured latency.
- **~1,000 sessions** in the month after publication for a deep technical piece, against **up to 30,000** for a reactive news piece that lands "once or twice a year" - the measured gap is the case for holding unassigned slack. The quarter's best piece often cannot be scheduled in advance. It is not a reason to plan news slots.
- **80% committed / 20% open** - a planning convention that splits capacity into committed slots and reactive room. Holds across content, campaign and capacity-planning tooling. Both count in hours or slots, not reviewer passes - adjust downward if the reviewer bottleneck is tighter than writer throughput.
This skill's own baselines - proposed starting points, replace them with the team's real numbers:
- Publish-rate target of 80% (matches the 80% committed share).
- Evergreen majority outside a launch-dominated quarter (reflects compounding value; the team's own decay curve may vary).
- Coverage of at least three surfaces and two journey stages (a coverage floor).
- Announcement cap agreed per quarter (no universal default exists).
## Pass thresholds
Treat these as the plan's acceptance test, and revise until all pass:
- Every slot has an owner **and** a named reviewer - not a team name.
- Every slot carries a surface, a pillar, a journey stage and an evergreen/timely label.
- Every demand-sourced slot has evidence; every bet has a stated hypothesis.
- Committed slots consume at most 80% of estimated capacity; the rest is named slack.
- Every anchor has both a preparation slot and a follow-up slot.
- The plan covers at least three distinct surfaces and at least two journey stages.
- Evergreen slots are the majority, unless the user chose a launch-dominated quarter and accepted the trade-off.
- Announcement/product-promotion slots stay under the cap the user agreed in step 3.
State which checks failed and what you changed, rather than silently rebalancing.
## Invocation examples
- _"Plan our Q3 devrel content - 2.0 ships in week 4 and we're speaking at two conferences."_ Run the full workflow from the interview.
- _"One writer, one reviewer at four hours a week, twelve weeks. What can we actually ship?"_ Start at step 4: size capacity first, place only what fits, show what was cut.
- _"Nothing shipped in the last month of the quarter again."_ Diagnose with the failure-modes table, then re-estimate the capacity model in passes before touching the slots.
**Audit mode** - _"Here's our current calendar, tell me what's wrong with it."_ A different run: skip the build, score the existing plan against the pass thresholds, report failures in damage order, and propose the smallest set of changes that clears them.
**Out of scope** - _"Write the migration guide in slot W3."_ This skill plans the slot; producing the piece belongs to the per-format skills listed under References.
## Output shape
A quarterly plan document with five sections: **anchors**, **mix ratios**, **capacity model**, **slot table**, **review ritual and metrics**. The slot table is the core:
| Week | Working title | Surface | Pillar | Stage | Shelf life | Anchor | Owner | Reviewer | Evidence / hypothesis |
| ---- | --------------------------------- | ----------- | ---------- | ----- | ---------- | ------------ | ----- | -------- | ----------------------------- |
| W3 | Zero-downtime upgrade path for v3 | docs + blog | enablement | adopt | evergreen | v3.0 release | A. | R. (eng) | 14 tickets on failed upgrades |
Close the document with the validation result: which thresholds passed, and what was cut to get there. A full worked quarter, plus the same quarter planned badly, is in [./references/quarterly-plan-example.md](./references/quarterly-plan-example.md).
## Audience split
When both audiences matter, give each its own slots and label them: one blended piece answers neither.
- **Individual adoption:** sells the trial - time-to-first-success, runnable demos, fun.
- **Team/company adoption:** answers the questions an approver asks - licence, security posture, release cadence, migration cost, support path.
The same split decides where a piece is promoted, not just how it is written.
## Failure modes
| Symptom | Cause | Fix |
| ------------------------------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------- |
| Nothing ships in the last month | Capacity counted in drafting time only | Re-estimate in passes, cut slots rather than quality |
| Everything stuck "in review" | Reviewer unnamed or unavailable | Name the reviewer at planning time, agree an SLA, prefer cheaper-to-verify formats |
| Calendar drifts to announcements | Promotional work has deadlines and sponsors, evergreen has neither | Cap promotional share, give evergreen slots hard dates too |
| Traffic without activation | All slots at discover stage | Rebalance toward try/adopt, add docs and troubleshooting surfaces |
| Quarter resets to zero | Timely-only mix | Move majority to evergreen, add refresh slots for decaying pieces |
| Launch slips and takes the quarter with it | Single anchor carrying most capacity | Keep anchor-bound share bounded, keep evergreen slots independent of the date |
| Same topic in five places, split search authority | Repurposing without a canonical target | One canonical URL per topic, derivatives link back to it |
| Outsourced piece misses its anchor | Agency lead time counted as an in-house draft | Book external writing 8-9 weeks out, keep timed beats in-house |
| Best piece of the quarter unplanned | No slack held for reactive moments | Keep the 20% open, name who may spend it |
## Metrics
Measure the plan, not only the pieces:
- **Publish rate** (published ÷ slotted) - planning accuracy. Persistent shortfall means the capacity model is wrong.
- **Mix drift** - actual versus intended ratios at the monthly review.
- **Anchor coverage** - share of anchors that got both preparation and follow-up.
- **Slot lead time** - days between "ready for review" and published, which exposes the bottleneck.
Stop at plan-level metrics, and do not rebuild the following here:
- Per-piece performance (search, activation, deflection) is measured by the piece's own format skill.
- samber/developer-relations-skills@devrel-metrics decides which signals count.
- samber/developer-relations-skills@devrel-analytics instruments them.
## References
- [./references/mix-and-capacity-model.md](./references/mix-and-capacity-model.md) - mix axes, ratio-setting by funding driver, per-format cost bands, demand-signal sources
- [./references/published-findings.md](./references/published-findings.md) - every figure this skill quotes, its source, and how far it can be pushed
- [./references/quarterly-plan-example.md](./references/quarterly-plan-example.md) - worked quarterly plan and a negative example
- samber/developer-relations-skills@oss-launch - the anchors this plan schedules around
- samber/developer-relations-skills@conference-cfp-submission - the anchors this plan schedules around
- samber/developer-relations-skills@build-in-public - transparency cadence that feeds slots
- samber/developer-relations-skills@devrel-strategy - program pillars that set the quarter's mix
- samber/developer-relations-skills@devrel-budget-allocation - when the constraint is money rather than reviewer time
- samber/developer-relations-skills@developer-case-study - customer story pipeline feeding this calendar's proof-content slots