changeset

Generate .changeset files with strict formatting and versioning rules.

Updated Jul 18, 2026
One-click install
npx skills add https://github.com/arthrod/conejo-skills --skill changeset-arthrod
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: changeset
Source: https://github.com/arthrod/conejo-skills/tree/main/skills/changeset
Command: npx skills add https://github.com/arthrod/conejo-skills --skill changeset-arthrod

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill eliminates inconsistent, verbose, or improperly formatted release documentation in monorepos, ensuring that every package change is clearly communicated with the correct impact level.

Core Features & Use Cases

  • Strict Formatting: Enforces the one-action-verb-per-bullet rule to maintain clarity.
  • Impact Control: Prevents accidental version explosions by restricting minor changesets for core packages.
  • Use Case: When preparing a release for a monorepo, use this skill to generate a compliant changeset file that correctly categorizes a fix as a patch and follows the required imperative tone.

Quick Start

Use the changeset skill to generate a new release note for the core package that follows the imperative voice and correctly identifies the impact level.

Frequently Asked Questions about changeset

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

FAQPage Schema
How do I standardize monorepo release documentation and enforce consistent formatting?

Standardize monorepo release documentation by enforcing strict formatting and versioning rules for .changeset files, ensuring every package update is clearly communicated with the correct impact level.

How do I generate a compliant changeset file for a single package update?

Generate a compliant changeset file by adhering to single-package file constraints, using imperative voice, and applying specific impact-level restrictions to correctly categorize fixes as patches.

Why do my monorepo changelogs have accidental version explosions for core packages?

Accidental version explosions occur when minor changesets are incorrectly applied to core packages; restrict impact levels for core packages to prevent improper version bumps and maintain stability.

What is the best way to format release notes for monorepo package updates?

Format release notes by applying the one-action-verb-per-bullet rule to maintain clarity, ensuring the required imperative tone is followed for all package update documentation.

Does this monorepo changeset generation approach work for restricting minor version bumps on core packages?

Yes, this approach restricts minor changesets for core packages by applying specific impact-level restrictions, preventing accidental version explosions while standardizing the creation of registry changelogs.