mcpbeat Sign in

Release Post Agent Skill

> Create professional package release blog posts following Tidyverse or Shiny blog conventions. for tidyverse.org or shiny.posit.co, (2) Transform NEWS/changelog content into blog format, (3) Generate acknowledgments sections with contributor lists, (4) Format posts following specific blog platform requirements. Supports both Tidyverse (hugodown) and Shiny (Quarto) blog formats with automated contributor fetching and comprehensive style guidance.

11k tokens
context cost
the whole folder, loaded on every use
5
files
ships runnable scripts
0
copies elsewhere
how many repositories repackaged it
453
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/posit-dev/skills --skill release-post

The instruction itself

19 sections, as written by the author

Package Release Post

Create professional R/Python package release blog posts following Tidyverse or Shiny blog conventions.

Quick Start

  • Identify the blog platform: Tidyverse (tidyverse.org) or Shiny (shiny.posit.co)
  • Verify NEWS.md or changelog exists for the package
  • Gather package info: name, version, repository (e.g., "tidyverse/dplyr")
  • Follow the workflow below
  • Use scripts/get_contributors.R to generate acknowledgments
  • Reference the appropriate formatting guide for final polish

Platform Selection

This skill supports two blog platforms with different formatting requirements:

  • Tidyverse blog (tidyverse.org)
  • Uses hugodown
  • R packages primarily
  • More rigid structure and conventions
  • See references/tidyverse-formatting.md
  • Shiny blog (shiny.posit.co)
  • Uses Quarto
  • R and Python packages
  • More flexible, feature-focused structure
  • See references/shiny-formatting.md

First, determine which platform the post is for, then follow the general workflow and apply platform-specific formatting.

General Workflow

These steps apply to both platforms. Content guidelines are based on Tidyverse best practices but adapt them as needed for Shiny posts.

Step 1: Gather Information

Collect required information:

  • Platform: Tidyverse or Shiny blog?
  • Package name and version: e.g., "dplyr 1.2.0" or "shiny 1.9.0"
  • Repository: GitHub repo in "owner/repo" format
  • Package language: R or Python
  • NEWS content: Read the package's NEWS.md, CHANGELOG, or NEWS
  • Package description: One-sentence core purpose
  • Previous release tag: For contributor fetching (optional)
  • Featured image: For frontmatter (optional but recommended)

Step 2: Structure the Post

Create the post outline following this order:

  • Frontmatter: Platform-specific YAML (see formatting references)
  • Title and Opening:
  • Title: Package name and version
  • Opening: Announcement with one-sentence package description
  • Installation: Code block with installation command
  • Overview: Brief summary with link to full release notes
  • Main Content (choose appropriate sections):
  • Migration guide (if breaking changes) - Always first when present
  • Lifecycle changes (deprecations, soft-deprecations, defunct)
  • Feature sections (one per major feature, descriptive headings)
  • Minor improvements (bulleted list)
  • Acknowledgements (when appropriate):
  • Use scripts/get_contributors.R
  • Format: "A big thank you to all the folks who helped make this release happen:"
  • Comma-separated GitHub links

Step 3: Apply Content Guidelines

Follow the best practices in references/content-guidelines.md:

  • Opening style: "We're [random adjective expressing excitement] to announce the release of..."
  • Section organization: Migration → Lifecycle → Features → Improvements → Acknowledgements
  • Tone: Conversational, professional, enthusiastic but authentic
  • Technical precision: Use exact function names in backticks
  • Focus on benefits: Explain "why" not just "what"
  • Code examples: Realistic, well-commented, properly formatted

Step 4: Transform NEWS Content

Convert NEWS.md bullets to blog-friendly content:

  • Research features thoroughly: Don't just copy NEWS bullets—read function docs, check PRs, understand the context
  • Expand context: Why changes matter, not just what changed
  • Add complete code examples: Show realistic usage with full workflows, not just function signatures
  • Explain concepts first: For unfamiliar features, explain what they are and how they work before showing code
  • Group thematically: Combine related NEWS items into coherent sections
  • Use conversational tone: Transform terse bullets into prose
  • Link documentation: Add relevant links to docs and resources
  • Highlight breaking changes: Make migration paths clear
  • Multi-language parity (Shiny only): For R+Python packages on the Shiny blog, ensure all examples show both languages in tabsets

Step 5: Apply Platform-Specific Formatting

For Tidyverse posts, read references/tidyverse-formatting.md and apply:

  • hugodown frontmatter with slug, photo.url, photo.author
  • Specific slug format: packagename-x-y-z (hyphens replace dots)
  • R code blocks with r language identifier
  • Acknowledgements always included as final section

For Shiny posts, read references/shiny-formatting.md and apply:

  • Quarto frontmatter with YAML anchors for social media
  • Flexible title formatting
  • Use tabsets for Python/R or Express/Core variations
  • Platform-specific code block attributes
  • Acknowledgements optional, varies by post type
  • May use lead paragraphs, callouts, embedded media

Step 6: Generate Acknowledgements

Run the contributor script:

Rscript scripts/get_contributors.R "owner/repo"

Or with a specific starting tag for the previous version (or tag used for last release post):

Rscript scripts/get_contributors.R "owner/repo" "v1.0.0"

Copy the markdown output into the Acknowledgements section.

Step 7: Review and Polish

Platform-agnostic checklist:

  • [ ] Frontmatter complete with all required fields
  • [ ] Opening clearly states package purpose
  • [ ] Installation code block present (both languages if applicable)
  • [ ] Sections organized logically
  • [ ] Code examples use proper syntax highlighting
  • [ ] Function names in backticks with parentheses: function()
  • [ ] Package names are not backticked or otherwise styled
  • [ ] Tone is conversational but not marketing-speak
  • [ ] No superlatives ("powerful", "rich", "seamless", etc.)
  • [ ] Features explained with context, not just listed
  • [ ] Concepts explained before showing code
  • [ ] All examples show R and Python variants (if applicable)
  • [ ] Links to full release notes included

Platform-specific checklist:

Tidyverse:

  • [ ] Slug format: package-x-y-z (hyphens, not dots)
  • [ ] Photo URL and author included
  • [ ] Acknowledgements section is final section
  • [ ] All contributors listed alphabetically

Shiny:

  • [ ] YAML anchors used for description (&desc, *desc)
  • [ ] Social media cards configured (open-graph, twitter-card)
  • [ ] Appropriate filters specified if using tabsets/shinylive
  • [ ] Tabsets used for showing paired variants (Python/R, Express/Core)
  • [ ] Multi-language tabsets used consistently (for R+Python packages only)

Reference Documentation

Load these as needed for detailed guidance:

Content Guidelines

references/content-guidelines.md - General best practices for all release posts:

  • Post structure and organization
  • Opening style and tone
  • Section hierarchy and organization
  • Code examples and formatting
  • Before/after patterns
  • Acknowledgments conventions

Platform-Specific Formatting

references/tidyverse-formatting.md - Tidyverse blog requirements:

  • hugodown frontmatter structure
  • Slug and title conventions
  • Photo attribution
  • Code block formatting
  • Lifecycle section structure
  • Acknowledgements format

references/shiny-formatting.md - Shiny blog requirements:

  • Quarto frontmatter with YAML anchors
  • Social media card configuration
  • Lead paragraphs and callouts
  • Tabsets for variants
  • Line highlighting and annotations
  • Video embedding
  • Flexible acknowledgements

Resources

  • scripts/get_contributors.R: Fetch formatted contributor list using usethis::use_tidy_thanks()
  • references/content-guidelines.md: General content best practices (platform-agnostic)
  • references/tidyverse-formatting.md: Tidyverse-specific formatting requirements
  • references/shiny-formatting.md: Shiny-specific formatting requirements

Platform-Specific Quick Reference

Tidyverse Post Template

---
output: hugodown::hugo_document
slug: package-x-y-z
title: package x.y.z
date: YYYY-MM-DD
author: Your Name
description: >
    Brief description
photo:
  url: https://unsplash.com/photos/id
  author: Photographer Name
categories: [package]
tags: [package]
---

# package x.y.z

We're pleased to announce the release of package x.y.z...

install.packages("package")


...

## Acknowledgements

A big thank you to all the folks who helped make this release happen:

[Contributors from get_contributors.R]

Shiny Post Template

---
title: Package Name x.y.z
description: &desc |
  Brief description of the release.
author: "Your Name"
date: "YYYY-MM-DD"

image: feature.png

open-graph:
  image: feature.png
  description: *desc
twitter-card:
  image: feature.png
  description: *desc
---

# package x.y.z

We're excited to announce package x.y.z...

[Installation for Python or R]

...

Tips

  • Breaking changes first: Put migration guides before features
  • Highlight the wins: Lead with the most exciting features
  • Show don't tell: Use code examples liberally
  • Link generously: Help readers find more information
  • Keep it conversational: Write like you're explaining to a colleague
  • Be authentic: Enthusiasm should feel genuine, not marketing-speak

Other skills for the same job

different authors, same section of the catalogue
Doc Coauthoring
by anthropics
vendor ×10

Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.

4k tokens
Changelog Generator
by frostant
×9

Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.

774 tokens
Test Driven Development
by w95
×7

Use when implementing any feature or bugfix, before writing implementation code

2k tokens
Writing Plans
by ZhanlinCui
×4

Use when you have a spec or requirements for a multi-step task, before touching code

816 tokens
Writing Skills
by ZhanlinCui
×4

Use when creating new skills, editing existing skills, or verifying skills work before deployment

26k tokens scripts
Crafting Effective Readmes
by softaworks
×3

Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.

15k tokens
Humanizer
by softaworks
×3

| Remove signs of AI-generated writing from text. Use when editing or reviewing text to make it sound more natural and human-written. Based on Wikipedia's inflated symbolism, promotional language, superficial -ing analyses, vague attributions, em dash overuse, rule of three, AI vocabulary words, negative parallelisms, and excessive conjunctive phrases.

6k tokens
Opentrons Integration
by christophacham
×3

Official Opentrons Protocol API for OT-2 and Flex robots. Use when writing protocols specifically for Opentrons hardware with full access to Protocol API v2 features. Best for production Opentrons protocols, official API compatibility. For multi-vendor automation or broader equipment control use pylabrobot.

9k tokens scripts

How to use it

Copy the folder

Take posit-dev/release-post from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.