writing-releases
$
npx mdskill add medusajs/medusa/writing-releasesDrafts Medusa release notes from commit data.
- Generates formatted release descriptions from commit and PR metadata.
- Integrates with GitHub for release note publishing.
- Decides content based on release type and breaking change presence.
- Delivers output as markdown with mandatory changelog links.
SKILL.md
.github/skills/writing-releasesView on GitHub ↗
--- name: writing-releases description: Writes GitHub release notes for Medusa releases in the established style. Use when generating a draft release description from a list of commits and PR metadata. Covers minimal patch releases, single-highlight releases, multi-feature releases, and releases with breaking changes. --- # Writing Medusa Release Notes Generates GitHub release notes from commit/PR data in the established Medusa style. ## Constraints - **Full Changelog link is mandatory** — always the last line: `**Full Changelog**: [vPREV...vNEW](compare-url)` - **No top-level Breaking Changes section** — breaking changes are embedded inside their Highlight subsection with `🚧 Breaking change`, never in a separate `## Breaking Changes` heading - **Bullet format is strict** — every entry in Features/Bugs/Chores/etc. must include author link and PR link (see `reference/format.md`) - **Highlights are not a summary of all PRs** — only significant changes qualify; routine additions go in Features/Bugs bullets only (see `reference/release-types.md`) - **No emojis** — the only permitted emoji is `🚧` on breaking change highlights; use none anywhere else - **Code block required for actionable steps** — if a highlight requires the developer to install a package, run a command, or update config, include a fenced code block with the exact command(s) ## Load Reference Files When Needed > **Load at least one reference file before writing.** | Task | Load | |------|------| | Formatting sections and bullets | `reference/format.md` | | Deciding whether to write Highlights, and identifying breaking changes | `reference/release-types.md` | | Writing the Highlights section | `reference/highlights.md` | ## Quick Reference ### Release type decision | Commit set | Release type | |-----------|-------------| | Only routine fixes/chores, no user-facing impact | Minimal — no Highlights section | | One important change is the main reason for the release | Single Highlight | | Multiple significant features or fixes | Multi-Highlight | | Any PR with a minor changeset in `.changeset/` | Add `🚧` to that Highlight | ### Section order (include only sections with entries) ``` ## Highlights ## Features ## Bugs ## Documentation ## Chores ## Other Changes ## New Contributors **Full Changelog**: [vPREV...vNEW](url) ``` ## Common Mistakes - [ ] Adding a title or `# Heading` at the top — release notes have no title, start directly with the first section - [ ] Adding a `## Breaking Changes` top-level section — embed inside the Highlight instead - [ ] Putting a routine bug fix or small feature addition in Highlights - [ ] Missing the Full Changelog link at the end - [ ] Bullet missing author link or PR link - [ ] Using PR title verbatim as a Highlight heading — write a descriptive outcome-focused title - [ ] Treating every `feat:` commit as a Highlight candidate - [ ] Using emojis anywhere except `🚧` on breaking change highlights - [ ] Writing a Highlight that requires a developer action (install, run, config change) without a fenced code block ## Reference Files ``` reference/format.md — section order, bullet format, commit prefix → section mapping reference/release-types.md — when to add Highlights, breaking change detection, highlight criteria reference/highlights.md — how to write Highlight subsections ```
More from medusajs/medusa
- reviewing-prsReviews GitHub pull requests for the Medusa repository. Checks PR template compliance, contribution guidelines, code conventions, and community contribution limits. Posts a review comment and applies initial-approval or requires-more label. Use when a PR is opened or updated.
- triaging-issuesTriages GitHub issues for the Medusa repository. Use when a GitHub issue is opened or receives a new comment. Categorizes the issue, validates it, executes the correct response flow, manages labels, and closes issues when appropriate. Accepts issue number as required argument plus optional title, body, and author.
- writing-docsWrites and updates Medusa documentation MDX files for the book, resources, ui, user-guide, and cloud projects. Use when making documentation changes based on code diffs, adding new pages, updating existing content, or updating component examples. ALWAYS load this skill before modifying any MDX file in www/apps/.
- writing-tsdocsAdds and updates TypeDoc (TSDoc) comments to TypeScript source files in the Medusa codebase. Covers HTTP types, API routes, UI components, data models, service interfaces, JS SDK methods, abstract providers, workflow SDK functions, core-flows workflows and steps, and events. Use when adding TSDoc comments to files in packages/core/types/src/http, packages/medusa/src/api, packages/design-system/ui/src/components, packages/modules/*/src/models, packages/core/types/src, packages/core/js-sdk/src, packages/core/utils/src, packages/core/workflows-sdk/src/utils/composer, packages/core/core-flows/src, or packages/core/utils/src/core-flows/events.ts.
- writing-tutorialsCreates Medusa documentation tutorials in two phases: first builds the tutorial feature in an example project (with planning, coding, and tests), then writes the MDX documentation. Use when creating a new how-to tutorial or integration guide for the Medusa docs. Handles both feature implementation and documentation writing, but only one phase at a time.