Menu
Write user-facing release notes for a Bitwarden release from a Jira release tag and the
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/bitwarden/ai-plugins --skill writing-release-notesThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
| name | writing-release-notes |
| description | Write user-facing release notes for a Bitwarden release from a Jira release tag and the |
| allowed-tools | mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_issues, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue_comments |
Produce concise, user-facing release notes for a Bitwarden release. The output is what customers read — on GitHub, in the App Store, or in Google Play — so every word should be benefit-oriented, jargon-free, and accurate about what users will actually experience.
Automated Jira lookups require the bitwarden-atlassian-tools plugin (its MCP server exposes search_issues, get_issue, and get_issue_comments). Without it, or when running in a Claude.ai Project (MCP tools are unavailable there), fall back to asking the user to paste the release page content and the Slack thread text directly — the rest of this skill works identically either way. There is no Slack MCP integration in this marketplace; the Slack thread is always gathered by asking the user to paste it.
Gather two inputs before writing anything:
Ask the user for the Jira release page URL (e.g. https://bitwarden.atlassian.net/projects/CL/versions/12345/tab/release-report-all-issues) or the release version name (e.g. 2025.7.0).
If search_issues is available, resolve the query:
/versions/) and query by ID: fixVersion = 12345 ORDER BY issuetype ASCfixVersion = "2025.7.0" ORDER BY issuetype ASCCall search_issues with fields: ["summary", "issuetype", "labels", "components", "status", "description"], and page through results using the returned nextPageToken until none is returned. For each issue, capture summary, issue type, labels, components, status, and any feature flag references found in the description. Feature flag references usually surface more completely in the Slack thread (Step 1b); only call get_issue_comments for individual issues where the flag is ambiguous after checking both sources.
If MCP tools are not available (web app context), ask the user to paste the release page content or a list of ticket summaries directly into the conversation.
The #release Slack thread is posted weekly and specifies which feature flags are toggled for the release. This is critical for two reasons:
Ask the user to paste the thread content.
Parse the thread to extract:
Identify:
If the release covers multiple repos with separate release notes (e.g., clients and server each have their own GitHub release), confirm with the user whether they want notes for all or one.
Go through every issue in the release and classify it. Only items that pass the filter appear as named bullet points.
Feature flags that are fully removed from the server codebase in this release. Flag removal is the moment self-hosted users gain access to a feature. Write each removal as a user-facing line describing what the feature does — not the internal flag identifier. See Step 4 for format.
Added, Updated, Fixed, Improved, RemovedVarious under-the-hood improvements and minor bug fixesInformative, brief, benefit-forward. Avoid marketing superlatives ("exciting", "powerful"). Avoid engineering jargon ("refactored", "migrated", "scaffolded", "deprecated"). Write for a non-technical user who wants to know if anything changed that affects them.
Flag removal lines describe the feature the flag was guarding, in plain user-facing language. Look up the associated Jira ticket, Confluence page, or Slack thread description to find the right framing. The internal flag name is a lookup key only — it never appears in the output.
Use the format:
Removed feature flag for [user-facing description of what the feature does]
Example: a flag named pm-36859-refactor-org-collections-vault-component becomes:
Removed feature flag for organization vault collection management improvements
Self-hosted users are the primary audience for this line — they are receiving the feature for the first time when the flag is removed, so the description should communicate the benefit clearly.
Updated UI for centralized ownership policy
Added a product tour for access intelligence
Added information banner to SCIM setup page
Added a checkout success page following Stripe payment flows
Various under-the-hood improvements and minor bug fixes
Added support for flexible collection permissions for enterprise plans
Improved admin console filtering for large organizations
Removed feature flag for flexible collection permission management
Removed feature flag for bulk collection management improvements
Various under-the-hood improvements and minor bug fixes
Before presenting the final output, check:
Reviews Claude configuration files for security, structure, and prompt engineering quality. Use when reviewing changes to CLAUDE.md, agents, prompts, commands, hooks, or settings. Routes each file type to a targeted review skill and returns classified findings. Flags settings.local.json appearing in a changeset, hardcoded secrets, malformed YAML, insecure agent tool access, and unsafe hook commands. Does not review SKILL.md files — plugin-dev:skill-reviewer owns those.
Perform a rigorous, multi-agent code review with architecture-compliance, parallel quality/security analysis, finding validation, and severity audit. Use when the user asks for a structured, deep, thorough, multi-pass, or multi-agent code review — or a review that includes architecture/pattern compliance, confidence-scored findings, or a severity audit. Use when the user asks for a code review across a commit range, time window, or N most recent commits in a locally checked-out repo.
Use this skill when posting the final summary comment after all inline comments are posted. Apply as the LAST step of code review after all findings are classified and inline comments are complete. Detects context (agent mode sticky comment, GitHub Actions MCP tool, or local file) and routes output accordingly.
Based on SOC occupation classification
