> 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.
npx skills add https://github.com/posit-dev/skills --skill release-post
Create professional R/Python package release blog posts following Tidyverse or Shiny blog conventions.
scripts/get_contributors.R to generate acknowledgmentsThis skill supports two blog platforms with different formatting requirements:
references/tidyverse-formatting.mdreferences/shiny-formatting.mdFirst, determine which platform the post is for, then follow the general workflow and apply platform-specific formatting.
These steps apply to both platforms. Content guidelines are based on Tidyverse best practices but adapt them as needed for Shiny posts.
Collect required information:
Create the post outline following this order:
scripts/get_contributors.RFollow the best practices in references/content-guidelines.md:
Convert NEWS.md bullets to blog-friendly content:
For Tidyverse posts, read references/tidyverse-formatting.md and apply:
slug, photo.url, photo.authorpackagename-x-y-z (hyphens replace dots)r language identifierFor Shiny posts, read references/shiny-formatting.md and apply:
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.
Platform-agnostic checklist:
function() Platform-specific checklist:
Tidyverse:
package-x-y-z (hyphens, not dots)Shiny:
&desc, *desc)open-graph, twitter-card)Load these as needed for detailed guidance:
references/content-guidelines.md - General best practices for all release posts:
references/tidyverse-formatting.md - Tidyverse blog requirements:
references/shiny-formatting.md - Shiny blog requirements:
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 requirementsreferences/shiny-formatting.md: Shiny-specific formatting requirements---
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]
---
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]
...
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.
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.
Use when implementing any feature or bugfix, before writing implementation code
Use when you have a spec or requirements for a multi-step task, before touching code
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.
| 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.
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.
Take posit-dev/release-post from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
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.