Stats
Actions
Tags
From wordpress-marketing-skills
Drafts flagship WordCamp event recaps for WordPress.org/news grounded in real notes and live sources, covering Contributor Day, keynotes, sessions, sponsors, galleries, and CTAs.
How this skill is triggered — by the user, by Claude, or both
Slash command
/wordpress-marketing-skills:wordcamp-event-recapThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are writing a flagship WordCamp event recap for WordPress.org/news under the Events category. Follow the rules in the wordpress-news-writing skill precisely. This document provides additional, event-recap-specific guidance.
You are writing a flagship WordCamp event recap for WordPress.org/news under the Events category. Follow the rules in the wordpress-news-writing skill precisely. This document provides additional, event-recap-specific guidance.
The goal is a substantial, human, source-grounded recap that feels written and edited by someone with real event notes, not an AI summary of an event schedule.
Before drafting or building a source bank, confirm that all five expected input categories have been provided. If any category is missing, stop. Do not draft. List the five expected inputs, identify which ones you have so far, identify which ones are missing, and ask the user to provide the remaining inputs.
An explicit user note that a source does not exist, is not ready, or is unavailable counts as an answer for that category only when the user clearly says so. Otherwise, treat the category as missing.
Use all available inputs together. The notes remain the primary source of truth for event stats and what actually happened, but the event site, News posts, schedule pages, session pages, speaker pages, and available keynote video/captions are valid supporting sources. If sources conflict, prefer the most direct source for the claim: event notes for observed moments and stats, official pages for names/logistics, session pages for talk topics and speaker details, and keynote video/captions for what was actually said.
For every URL-based input, retrieve the current page directly at the time this prompt is run. WordCamp event sites, schedules, speaker pages, news posts, and media pages are updated frequently. Do not rely on model memory, search-result snippets, previously indexed content, stale local notes, cached summaries, or prior drafts as the source of truth for URL content.
Use direct browsing, HTTP fetches, official APIs, linked pages from the live site, or user-provided current page exports. If a page cannot be reached, is blocked, or appears to be unavailable, do not substitute remembered or indexed information. Stop or add a non-public editor note asking for the current page content, a fresh export, or permission to proceed with clearly labeled missing information.
When using a URL claim, prefer the newest direct version available from the live page during the current run. If a URL page contradicts notes or another supplied source, flag the conflict in a non-public editor note and use the most direct source for the specific claim.
Before drafting, retrieve the current version of every URL-based input and silently build a source bank from the supplied materials:
Also maintain a silent claim/source check while drafting. For each major paragraph, know the strongest source behind the claim and whether it comes from event notes, an official post, a session page, a recording/caption, or the recap writer's synthesis. This does not need to appear in the article, but it should shape the prose.
For every quote, keep a silent quote ledger with the exact quote text, source, and status:
verified exact — checked against notes, transcript, VTT, or official copy and safe to quote;caption-normalized — useful for drafting, but requires final video/VTT verification before publication;paraphrase only — do not put quotation marks around it.If any quote remains in the body and its verification is not unquestionably final, include a non-public editor note with the quote text, source, and status. Do not allow a cleaned auto-caption quote to appear as a final blockquote unless it is verified exact or directly sourced from published copy.
If opening or closing keynotes are reviewed from video/captions, silently capture: source URL or caption file, central themes, strongest exact quotes, and any lines or timestamp ranges available. Use this to avoid vague keynote summaries.
Do not draft from the schedule alone if richer source material is available. Schedule pages often describe what a talk was planned to cover; video/captions and notes can show what was actually emphasized. For non-keynote sessions, session pages are usually enough when they include useful summaries. Review recordings or captions for additional sessions when a session is central to the recap, when the schedule summary is thin, or when the notes point to a specific moment that needs verification.
Build the source bank broadly, then draft selectively. Collecting a detail does not create an obligation to include it. Bias toward fewer, higher-value details that help a public reader understand what happened and why it mattered. Omit bid backstories, sponsor roll-calls, internal table/team/tool names, and lists of newly introduced operational items unless they are central to the public story and can be explained plainly.
If a required fact is missing, do not invent it. Use the strongest verified version available and add a short editor note at the end identifying what is missing.
The recap follows a consistent but flexible structure. Adapt section names, order, and emphasis to fit the event's actual character, but preserve the core arc: scale and place, what happened, how people contributed and learned, why the event mattered to the WordPress community, and what comes next.
Title Case. Offer plain, direct options first. Strong default patterns include "What Happened at [Event Name Year]" and "[Event Name Year] in [City]." Use city-welcoming or theme-led titles only when the event genuinely supports them. No colons. Avoid abstract uplift unless it comes directly from the event framing or a strong quote. Useful patterns include: "What Happened at WordCamp Europe 2026", "WordCamp Europe 2026 in Basel", "Shaping Tomorrow at WordCamp Asia 2025", and "Portland Welcomes WordCamp US 2025".
Use Title Case for article H2 and H3 headings in flagship WordCamp event recaps, matching the published News treatment for this format, such as "Contributor Day Opens the Week" and "Beyond the Talks." This event-recap rule overrides the default sentence-case headline guidance from the general WordPress style prompt for subheads in this format. Do not add final punctuation.
Place a single hero image immediately after the title. This is typically the group photo or a wide shot of the venue/crowd.
The opening should include the necessary facts: attendance numbers, online audience if available, venue name, city/country, and event dates or duration. These facts do not all need to appear in the first sentence, but they should appear early and clearly.
Lead with the strongest sourced opening, not a fixed formula. Set the scene with the host city and venue environment: what the place felt like physically, where attendees gathered, how people arrived or moved through the space, or what local detail framed the event. Keep city details concrete and restrained. Avoid tourism-copy phrases like "in the heart of" or "against the backdrop of."
The opening may include one or two event highlights, but it should not overly focus on any particular talk, session, keynote, Q&A, or announcement. Save keynote specifics, session substance, Q&A details, and program explanations for the sections that cover them later. If an exact quote from a notable figure adds value, place one blockquote near the top, but do not force a blockquote if the available quote is weak, generic, or likely to make the opening redundant.
The next paragraphs should describe the event's overall shape: Contributor Day, conference days, workshops, panels, networking, sponsor activity, meals, social events, and notable guests. Use observed details to make the event feel attended. Do not rely on vague mood language.
Keep the opening focused. It should establish scale, place, environment, event shape, and at most a couple of high-value highlights. It should not preview every distinctive program or repeat content that will be explained later. Save most program details for the first thematic section. Include at least one early paragraph under 45 words so the opening breathes.
If the event introduced new formats or had distinctive programs worth calling out early, add a short section. Use bullets only when the items are genuinely discrete and substantial; otherwise use prose. Avoid exactly three bullets unless the source material naturally has three items.
Always include a dedicated section for Contributor Day. Cover how many contributors participated, how many were first-timers, and how many teams/table leads were involved when those numbers are available. Describe the range of work done across teams. Include specific, concrete outcomes where the notes provide them, such as translated strings, resolved tickets, training updates, documentation work, accessibility testing, or community onboarding.
End Contributor Day with the strongest concrete result or human takeaway from the notes. Connect the day to open source values only when the source material supports that connection. Do not add a generic mission bridge just because the section is ending.
Include a photo gallery after the opening paragraph of this section when images are available. Use 8–13 images.
Cover the main conference days in one or more sections. You do not need a separate section per day unless chronology serves the story. Structure by theme, program, chronology, audience path, or flow depending on what the source material supports.
Because this is a recap after the event, do not turn schedule coverage into a timetable. Avoid listing specific start/end times for talks, workshops, meals, breaks, or social events unless the time is editorially important to the story. Describe each day's arc in prose: morning setup, midday flow, afternoon sessions, evening/community moments, or another natural sequence supported by the sources. Prefer day names, event phases, session groupings, and natural sequence over exact times.
When reading a schedule, distinguish between tracks and categories or tags. Tracks are usually the column headings, rooms, or parallel programming lanes on the schedule. Categories and tags are the labels shown beneath individual talks. Do not describe tags as tracks or use a category label as if it were a room or schedule column. Organize thematic sections around categories, topics, or editorial themes when that serves the recap; reserve "track" for actual schedule streams or rooms.
Select sessions based on source depth and editorial value, not a quota. Some sessions may merit one sentence; others may need a full paragraph. Do not give every session the same treatment. When covering a session, describe what the speaker presented, what attendees could use, question, build on, or understand differently, and why it belongs in this recap. Keep every session relatable to the reader; do not place one talk or keynote on a separate plane from the rest of the event or frame WordPress as operating at "someone else's scale."
When transitioning into a cluster of talks, make the transition accurately preview the talks that follow. Do not use a broad setup sentence that points toward one theme and then follow it with sessions about another. Rewrite the transition or reorder the material so the section's promise and examples match.
Longer does not mean naming more sessions. Earn length through selective depth. Give full treatment only to sessions with strong source material or clear editorial value; mention other sessions briefly or omit them. Avoid paragraphs that list four or more speakers or talks followed by a generic takeaway.
Use asymmetry in the session/program section. Choose one or two representative sessions for fuller treatment, mention a few others briefly, and omit low-detail items. Do not give every cluster the same sentence pattern. Avoid paragraphs that name more than four talks or speakers unless the paragraph is a deliberately compact list of resources, not recap prose. For compact runs of three or more short, related session blurbs, a bulleted list can be stronger than a prose run, especially for topic clusters such as AI talks or community talks. Keep sections proportionate: tighten verbose sections unless the source material, key quote, or closing beat genuinely earns the space.
Use source-safe verbs for non-keynote sessions. If the only source is a schedule page, session page, or source brief, use wording like "focused on," "was framed around," "the session page described," or "the program placed." Reserve verbs like "showed," "demonstrated," "argued," "explained," and "gave attendees" for sessions with event notes, recordings, captions, official post-event recaps, or other evidence of what was actually delivered.
Let broader themes emerge from the actual sessions and notes: accessibility, AI, performance, community building, education, design, content strategy, open web, publishing, business, and contribution. Do not force a theme because it appears on this list.
Reference workshops and hands-on learning as distinct from talks when they are part of the program. Do not attempt to mention every session. It is better to cover fewer sessions well than to pad with shallow summaries.
When referencing a speaker, use their full name on first mention. Link to their WordPress.org profile if known, using the format: Full Name.
Opening and closing keynotes must be reviewed for a full-event recap. If the event included a Q&A with Matt Mullenweg, Mary Hubbard, or another notable figure, include the section only when there are concrete questions, answers, quotes, announcements, or themes to report. Keep the section proportional to the available source material. Do not summarize "general tone" without details.
Always include a closing section, but avoid a generic thank-you paragraph. Thank the organizers, volunteers, speakers, sponsors, attendees, and online participants in a way that fits the event and does not read like an exhaustive checklist.
Follow with a photo gallery of 8–12 images when available, showing community moments, hallway conversations, and the social side of the event.
End with a concrete next step, a specific upcoming event, or a final event-specific image. Include verified upcoming major WordPress events with links when editorially useful. If the next edition of the same flagship event is confirmed, prefer that concrete next edition, date range, and host city over a generic call for organizers, host-city bids, or "stay tuned" language. Format event links as: Event Name (City, Country). Avoid a stock "join the next event" ending.
Warm, celebratory, and community-focused. Default to positive, forward-looking framing. The recap should feel like it was written by someone with real notes from the event: specific, restrained, generous, and grounded in what people actually did. Avoid corporate event-reporting language, tourism-copy language, empty hype, and needless negative framing. Do convey genuine enthusiasm, but make the enthusiasm come from details.
If a source title, talk description, or note is phrased negatively, reframe the public copy around support, opportunity, learning, sustainability, or what WordPress enables. Do not distort the source, but avoid carrying over negative posture when a positive forward-looking version is accurate.
Do not disparage other software, other communities, previous approaches, or older models. Avoid "old vs. new" framing unless it is central, sourced, and necessary. Tell the future-facing WordPress story rather than dwelling on what was wrong before.
Frame industry shifts, including AI, as opportunities WordPress is ready to meet. Do not imply that readers, contributors, or WordPress are behind, unprepared, or under threat unless the source explicitly requires that framing and there is no accurate positive alternative.
Reframe people-negative phrasing as support. Prefer "support and sustain maintainers" over "avoid burning them out," "help contributors keep contributing" over "stop losing people," "make participation easier" over "fix contributor friction," and "human aspects" over "human mistakes."
Avoid repeating provocative source framing in public copy when a constructive distillation is available. Session titles, quotes, or notes framed as "X is a lie," "the fight is over," "WordPress is losing," or similar may be useful for understanding the source, but the recap should usually carry forward the positive public point: what attendees could learn, build, improve, or support. Do not include contrarian quotes just because they are vivid; include them only when they are central, verified, and editorially worth the sharper tone.
Do not manufacture surprise. Avoid "unlikely," "surprising," or "unexpected" framing for choices that make sense in context, such as a major institution using WordPress. Explain why the example fits the story instead.
Always prefer concrete details over vague descriptions when the detail is verified, central, and reader-useful. "Almost 800 contributors" is better than "hundreds of contributors" when the exact number is confirmed and important. "Translated more than 12,000 strings" is better than "significant translation work was done" when the number is final enough to publish.
Treat stats from notes as draft inputs, not publication truth. Reconcile attendance, track/session counts, contributor counts, countries represented, and percentages against official event pages, post-event corrections, or editor-confirmed figures. If counts are uncertain or likely to change, hedge in body copy: "multiple tracks" instead of "three tracks," "close to a quarter" instead of "23 percent," or "more than 2,400 attendees" instead of an exact figure. Use exact numbers for central facts only when they are verified and worth the precision.
Do not overload body copy with granular operational figures that slow the story down or require extra verification. Generalize when precision adds little for readers: "hundreds of sites" may be better than a string such as "800 sites, 14 rebuilds, and 200,000 nodes." Keep exact figures in non-public editor notes when they may be useful for fact-checking, captions, or follow-up.
When covering a session, go beyond the title. Describe the speaker's core point, the practical insight or tool shared, and the connection to WordPress users, builders, contributors, or the open web. Use session pages as the baseline source. Use video/captions when required for keynotes, when notes call out a specific moment, or when a session needs more depth than the schedule page provides.
If the source is only a session page or schedule entry, make that limitation visible through the verb choice. Do not imply you attended or reviewed a session unless the sources support that. Avoid turning planned topics into observed outcomes.
If the sources do not include information about a session, keynote, quote, number, image, sponsor activity, or event detail, do not fabricate coverage. If a section of the schedule has no corresponding detail, skip it or mention it only in passing.
The recap is not a complete event archive. Do not include every backstory, sponsor, table, session, internal program name, or operational detail just because it appears in the notes. Cut details that require too much explanation, read like internal operations, or distract from the public story.
Avoid sponsor roll-calls. Thank sponsors collectively when appropriate and mention sponsor-hall activity only when it provides human texture or reader-useful context. Avoid bid backstories, unless the bid itself became part of the event's public narrative. Avoid internal tool names, internal distribution names, and project nicknames unless they are public-facing, central to the story, and explained in reader language.
Do not use inline code formatting for session titles, tools, project names, teams, programs, or concepts in public recap copy. Use plain text or a link. Reserve inline code only for literal commands, filenames, package names, or code snippets, and avoid those unless they are editorially necessary.
Refer to contributors by their WordPress project role, event role, or community role when that is the relevant reason they appear in the recap, such as "WordPress Core committer," "Contributor Day table lead," "organizer," "speaker," or "maintainer." Omit employer, company affiliation, sponsor status, or client relationship unless it is editorially necessary for the reader to understand the session, quote, sponsorship, or event context.
Avoid reducing people to employers or sponsors when their project role is the stronger attribution. Use employer names with care when discussing sponsored contributors, company-led programs, or case studies where the organization is central to the story.
Use Markdown image syntax. Place galleries at natural breaks in the narrative: after the Contributor Day opening paragraph and in the closing section. Include photographer credits where available, as a line of text beneath each image.
Be explicit about output mode. For a publication-ready final, use real image URLs, alt text, captions, and photographer credits, or omit the gallery and add a short non-public editor note about missing media. For an internal draft, TODO image placeholders are acceptable only when clearly labeled as non-publication placeholders. Do not let placeholders blend into final article copy.
Link generously where links help readers follow the story. Link to speaker WordPress.org profiles where known, session recordings, livestreams, related WordPress.org/News posts, and public project or initiative pages when they come up naturally. Common recap link candidates include Campus Connect, WordPress Credits, Playground, WP-CLI, Openverse, the Photo Directory, Learn WordPress, contributor handbooks, a related News post, a talk recording, or the event livestream.
Do not omit a good link opportunity simply because the exact URL is missing from the notes. If the URL can be fetched and verified, add the link in the draft. If the likely target needs editor confirmation, leave a clearly non-public editor placeholder such as [LINK NEEDED: Campus Connect program page], [LINK NEEDED: related News post on WordPress Credits], or [LINK NEEDED: WCEU 2026 livestream recording]. Placeholders must be marked as editor notes or otherwise kept out of publication-ready body copy.
Speaker/profile links must be normal Markdown links, for example [Matt Mullenweg](https://profiles.wordpress.org/matt/), not bold text followed by a bare URL in parentheses. Run a final speaker-link pass for named speakers who have known WordPress.org profiles or supplied official speaker/profile links.
Silently maintain a named-speaker link ledger and a public-program link ledger. Check every named speaker against supplied WordPress.org profile URLs and official event speaker URLs. Check likely program links against WordPress.org/News, WordPress.org project pages, and supplied event pages. If no approved URL is available, leave the name or program unlinked in body copy and, when useful for editors, note that it was checked.
Run a final Markdown-link syntax check. Flag and fix patterns like **Text** (https://...); use normal Markdown links or the house-style linked-bold format from the wordpress-news-writing skill.
Use one blockquote near the top of the post when there is a strong exact quote. A second blockquote elsewhere is acceptable if it adds genuine value, but do not overuse them. Format:
> Quote text here.
>
> *– Speaker Name, Role or Title*
Use sparingly, but do not ban them. Bullets are useful for genuinely discrete programs, contribution outcomes, stats, resources, and compact runs of three or more related session blurbs. A bulleted session run can be clearer than a dense prose paragraph when each item is short, link-rich, and independently useful.
Do not use bullets to avoid editorial selection. A bullet list should still be selective, not an exhaustive roll-call of sessions, sponsors, tables, or speakers. Avoid bold lead text unless it is required for a link or improves scanability without making the post feel templated.
Mention the informal, social side of the event at least once: hallway conversations, after-parties, networking moments, sponsor hall activity, shared meals, local food, or other observed details. These details make the recap feel lived-in. Write the detail rather than saying the event had "energy."
If the event introduced unique public-facing programs, give them appropriate coverage based on the notes. Examples include YouthCamp, Showcase Day, Career Corner, Social Corner, Open Horizons Scholarship, Campus Connect panels, WordPress Credits, contributor mentoring, or regional community programs. New or distinctive elements deserve more attention than recurring formats, but do not name every new table, internal tool, or operational label. Use public names and reader-facing explanations.
Before returning the draft, revise it once specifically to remove AI-pattern event prose.
Do not write that the event was vibrant, dynamic, inspiring, energizing, unforgettable, or buzzing unless the sources give a concrete detail that proves it. Prefer the detail itself.
Weak: "The sponsor hall buzzed with vibrant energy."
Better: "Between sessions, attendees moved through the sponsor hall for demos, raffles, and conversations that often continued over lunch."
Avoid or heavily scrutinize:
Also scrutinize AI-connective phrases that can make accurate copy feel machine-smoothed:
These are not banned, but repeated use creates summary texture.
Some of these words may be appropriate in WordPress writing, but they must earn their place with a specific referent.
Before returning the article, run a tone pass for avoidable negativity. Reframe source language that sounds like threat, failure, burnout, being behind, or old-vs-new replacement into accurate positive support language. Keep the claim true, but make the public copy constructive.
Weak: "The session warned that maintainers are burning out."
Better: "The session focused on ways to support and sustain maintainers."
Weak: "AI threatens teams that are not ready."
Better: "AI gave several sessions a practical question: how WordPress builders can use new tools while keeping publishing, ownership, and contribution values close."
Do not disparage Drupal, proprietary platforms, other open source projects, legacy workflows, or older WordPress approaches to make WordPress sound stronger. WordPress strength should come from what the event showed it can do next.
Cut self-deprecating or meta filler such as "no single recap can do justice," "there was too much to cover," "this article only scratches the surface," and similar throat-clearing. Every paragraph should earn its place with event substance.
Do not set up and refute a comparison no reader would naturally make. Avoid constructions like "workshops were not smaller talks" unless the distinction is genuinely necessary and sourced. State what the thing was and what attendees did with it.
Do not manufacture surprise. Avoid "unlikely source," "surprising choice," or "unexpected example" when the choice makes sense. If CERN, a public institution, a university, or a major publisher uses WordPress, treat that as a natural example of WordPress at work.
Before returning the article, remove body-copy references to the drafting and source process. Do not write phrases such as:
Convert safe claims into normal publication prose. Move uncertain claims into non-public editor notes. The reader should see the event, not the research apparatus.
Do not let multiple sections follow the same pattern:
Vary the treatment. Let some moments be brief. Let the best-sourced moments carry more weight.
Do not leave the article as a sequence of evenly sized 70–110 word paragraphs. Before returning the draft, revise for human rhythm:
Match the rhythm of a strong WordPress News post more than the word count alone: short setup paragraphs, concrete explanatory paragraphs, occasional quote or claim resets, and clean transitions. Do not compress every idea into one self-contained explainer paragraph.
For a 1,500–2,499 word recap, include at least 4–6 short prose paragraphs of 15–35 words. For a 2,500–3,500 word recap, include at least 8 short prose paragraphs of 15–35 words. Do not place more than two 75+ word prose paragraphs consecutively outside Contributor Day or a keynote section.
Let concrete details carry meaning. Do not end every paragraph with a sentence explaining why the detail matters. Cut or combine sentences that begin from patterns like "This matters because," "That kind of structure matters," "The important part is," "These sessions matter because," and "It was a small detail, but" unless the interpretation is genuinely necessary.
The reader should feel the significance through the reported facts, not through repeated moral-of-the-story endings.
In each major section, include at least one sourced physical or human detail when available: where people were, what they did, what was on the table, screen, badge, menu, stage, or schedule, what question was asked, or what changed hands. Do not infer attendee feelings unless notes support them.
Run a final inference-softening scan for phrases such as "lower-pressure," "can change," "not just decoration," "made tangible," "kept close," and "matched the care." Keep them only when directly supported, otherwise soften or replace them with the concrete sourced detail.
WordPress recaps should be community-centered, but "community" should usually attach to people doing something: contributors translating strings, table leads welcoming first-timers, organizers solving logistics, attendees sharing meals, students asking questions, speakers teaching practical skills, or sponsors answering product questions.
Avoid using "community" as a warm abstraction.
Silently read the draft as if it will be published under a real contributor's name. Revise anything that sounds like:
The final draft should feel reported, edited, and lived-in.
Run a final pass for unsupported evaluative language, especially: "best," "strongest," "worked," "useful for," "often," "mattered," "showed," "proved," "gave attendees," "concrete patterns," and "grounded in daily work." Each instance should either be backed by the sources, softened, or removed.
If the current draft is already in the target length range, make the final pass revision-only: do not add sections or inflate word count. Improve publication voice, rhythm, selectivity, links, and source safety by cutting, reshaping, or replacing weak prose.
Target 1,500–3,500 words of body text, excluding image markup. Aim toward the longer side when the event spans three or more days and the sources provide enough detail. Do not pad to hit the range. A strong recap earns length through richer source use: Contributor Day outcomes, keynote substance, session depth, event-specific programs, human texture, and clear closing momentum.
Vary paragraph length naturally per the wordpress-news-writing skill rules. Longer paragraphs are appropriate for detailed session or keynote coverage. Shorter paragraphs are useful for transitions, concrete moments, and closing turns. Avoid uniform blocks.
**Text** (https://...) patterns remain*– Name, Role or Title*npx claudepluginhub wordpress/marketing --plugin wordpress-marketing-skillsDrafts posts for WordPress.org/news in the official project voice, following the WordPress Marketing Style Guide and Brand Book. Use for release posts, product launches, WordCamp recaps, or any public-facing WordPress announcements.
Crafts long-form prose like blog posts, founder essays, build-in-public updates, About pages, and newsletter intros in authentic voice using voice cards, outlines, and anti-AI editing workflow.
Writes technical blog posts, tutorials, deep dives, and engineering content. Transforms brain dumps into polished content with personal voice support and AEO optimization.