make-changes

Create and update Remix package change files following repository changelog conventions.

33.3k|2.8k|Updated Oct 26, 2020
One-click install
npx skills add https://github.com/remix-run/remix --skill make-changes
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: make-changes
Source: https://github.com/remix-run/remix/tree/main/.agents/skills/make-changes
Command: npx skills add https://github.com/remix-run/remix --skill make-changes

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Writing consistent release notes across a multi-package monorepo is error-prone: bump types, file naming, placement, and content depth all follow repo-specific rules. This Skill encodes the Remix repository's .changes conventions so change files are created or updated correctly every time.

Core Features & Use Cases

  • Convention-compliant change files: Generates packages/<package>/.changes/[major|minor|patch].<slug>.md files with correct bump types, including special rules for 0.x packages and prerelease mode.
  • Duplicate detection and updates: Checks existing unpublished change files and updates them in place instead of creating duplicates.
  • Package ownership and re-export handling: Determines which package owns a change and when mirrored notes are needed for the umbrella remix package.
  • Use Case: After merging a bug fix PR to @remix-run/fetch, ask the Skill to write the change file; it picks the right bump type, describes the user-visible symptom, and verifies output with pnpm changes:preview.

Quick Start

Use the make-changes skill to write a change file for the bug fix in PR #1234 affecting the fetch package.

Frequently Asked Questions about make-changes

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a changelog entry for a Remix package?

Create a Markdown file at packages/<package>/.changes/[major|minor|patch].<short-description>.md describing the user-facing change. Run pnpm changes:preview to verify the rendered changelog output before finishing.

How do I choose major, minor, or patch for a change file?

For 0.x packages, use minor for new features and breaking changes, and patch for bug fixes; avoid major unless explicitly instructed. For 1.x+ packages, follow standard semver based on user-facing impact.

Should I update an existing change file or create a new one?

Check the package's .changes directory first. If an unpublished change file already covers the same work, update it in place rather than creating a duplicate note.

When does the remix umbrella package need its own change file?

Add a remix change file only when users consume a changed API through a re-exported remix/... entrypoint. Do not add notes for packages that merely observe changes through dependency updates, since release tooling generates those entries.

What should a breaking change note include?

Describe the old behavior, the new behavior, and the migration path. In 0.x packages, breaking change notes must start with the prefix BREAKING CHANGE: and breaking changes are measured relative to main.