Skip to main content

add-changeset

Add a changelog entry for a PR. Use when the user asks for a changeset, when finishing a PR that changes user-visible contract behavior, or when the changeset-bot has flagged the PR. Skip for NatSpec-only edits, internal refactors with no observable effect, or repo plumbing.

ソース情報

リポジトリ
OpenZeppelin/openzeppelin-contracts
ソースの最終更新活動
2026年8月21日 13:30
検出された SKILL.md の言語
英語
スター
27,284
フォーク
12,396

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md を表示中

SKILL.md
ソースの指示 · 読み取り専用プレビュー
name
add-changeset
description
Add a changelog entry for a PR. Use when the user asks for a changeset, when finishing a PR that changes user-visible contract behavior, or when the changeset-bot has flagged the PR. Skip for NatSpec-only edits, internal refactors with no observable effect, or repo plumbing.
# Add a changeset ## When to add one Add a changeset when the PR changes **user-visible contract behavior**: a new function, a new contract or extension, a bug fix that changes outputs, a new event, a new error, a new interface ID, or a tighter requirement. **Skip** for: - NatSpec-only changes. - Internal refactors with no observable effect. - Test/mock-only changes. - CI, lint, docgen, dependency bumps that don't change the published `contracts/`. If unsure, err on the side of adding one — release reviewers can downgrade to "skip" by deleting the file before tagging. ## How ```bash npx changeset add ``` The CLI prompts for severity, then opens an editor. Severity: - `patch` — bug fixes, gas optimizations, no API surface change. - `minor` — new contracts, new extensions, new public functions on existing contracts. There is no `major` from contributors — major version bumps are coordinated by maintainers. The resulting file in `.changeset/` looks like: ``` --- 'openzeppelin-solidity': minor --- `ComponentName`: One-sentence description starting with a backtick-quoted component name. ``` ## Format rules - **First word inside the backticks** is the affected contract, extension, or library: `ERC20`, `ERC1155Crosschain`, `Memory`, `Governor`, etc. - **Then a colon, then one sentence** describing the user-visible change. - **Imperative mood** (matching PR titles: "Add", "Fix", not "Added", "Fixed"). Trailing period optional. - **No bullet points**, no headings, no multi-paragraph prose. The release workflow concatenates these verbatim. - **State the change, don't justify it.** Skip "This mirrors ...", "so that ...", "closes a gap where ...", parallels to other functions, or motivation. If the user needs to take action (migration step, breaking rename, tighter requirement they might now hit), state that instead — otherwise the changelog line is just the fact of the change. Rationale belongs in the PR body and commit message, not the changelog. Good examples (taken from existing entries): ``` `Memory`: Add a `isReserved(Slice)` function that checks if the memory occupied by the slice is reserved (i.e. before the free memory pointer). ``` ``` `ERC1155Crosschain`: Add an ERC-1155 extension to embed an ERC-7786 based crosschain bridge directly in the token contract. ``` ``` Add ERC-165 detection for the `IERC6909ContentURI`, `IERC6909TokenSupply` and `IERC6909Metadata` interfaces in the `ERC6909ContentURI`, `ERC6909TokenSupply` and `ERC6909Metadata` contracts respectively. ``` (The last form — no leading backticks — is acceptable when several components are touched at once and a single prefix would be misleading.) ## After committing The `changeset-bot` GitHub check posts a comment confirming the changeset was detected. If the bot complains "No Changeset found" and the PR should not have one (NatSpec-only, etc.), leave a comment justifying it — a maintainer can apply the `ignore-changeset` label.
GitHubで見る