Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions .claude/skills/pr/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -107,14 +107,20 @@ Otherwise, after all launched subagents complete:
- Abort
4. If there are no blockers, briefly summarize the findings and proceed.

## Phase 4: Create the PR
## Phase 4: Update changelogs

5. Run `gh pr create` to create a pull request. The PR body should include:
**MANDATORY — DO NOT SKIP.** Each PR must update changelogs for all packages with consumer-facing changes.
Read the instructions in [`docs/contributing/updating-changelogs.md`](../../../docs/contributing/updating-changelogs.md) and follow them to the letter.
Commit the changes to the current branch with the commit message "docs: Update changelogs" before creating the PR.

## Phase 5: Create the PR

1. Run `gh pr create` to create a pull request. The PR body should include:

- A brief narrative description of the PR
- A summary of the changes (bullet points)
- A brief description of how the code is tested (narrative, not a checklist)

**If this is a stacked PR**, add `--draft` to create it as a draft PR.

6. Return the PR URL and any relevant information. If a review was performed, include the review summary.
2. Return the PR URL and any relevant information. If a review was performed, include the review summary.
10 changes: 10 additions & 0 deletions .claude/skills/update-changelogs/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
---
name: update-changelogs
description: Updates changelogs for all packages with consumer-facing changes.
---

When asked to update changelogs, follow these steps:

1. Read the instructions in [`docs/contributing/updating-changelogs.md`](../../../docs/contributing/updating-changelogs.md) and follow them to the letter.
2. Commit the changes to the current branch with the commit message "docs: Update changelogs" before creating the PR.
3. Return the commit hash and the commit message.
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@ dist/
coverage/
docs/*
!docs/*.md
!docs/contributing

# Logs
logs
Expand Down
29 changes: 1 addition & 28 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -64,34 +64,7 @@ See [`packages/create-package/README.md`](packages/create-package/README.md).

### Updating changelogs

Each package in this repo has a file named `CHANGELOG.md` which is used to
record consumer-facing changes that have been published over time. All
changelogs follow the ["Keep a Changelog"](https://keepachangelog.com/)
specification (enforced by `@metamask/auto-changelog`).

If a PR introduces a consumer-facing change to one or more packages, their changelogs must
be updated. This is enforced by CI. When updating changelogs, keep the following in mind:

- A changelog is not a git history; it is a summary of consumer-facing changes introduced by
a particular release.
- Consider each PR from the perspective of a consumer of an individual package. Changelog
entries may differ between packages.
- For example, if you're introducing feature X to package A, and it contains an incidental
change Y to package B, the package changelogs should reflect this.
- Place new entries under the "Unreleased" section.
- Place changes into categories. Consult the ["Keep a Changelog"](https://keepachangelog.com/en/1.1.0/#how) specification for the list.
- Highlight breaking changes by prefixing them with `**BREAKING:**`.
- Omit non-consumer facing changes from the changelog.
- Do not simply reuse the commit message, but describe exact changes to the API or usable
surface area of the project.
- Use a list nested under a changelog entry to enumerate more details about a change if need be.
- Include links (e.g. `#123) to the pull request(s) that introduced each change.
- Combine like changes from multiple pull requests into a single changelog entry if necessary.
- Split disparate changes from the same pull request into multiple entries if necessary.
- Omit reverted changes from the changelog.

If your PR does not contain any consumer-facing changes, add the label `no-changelog`, and the
changelog validation CI job will be skipped.
See [`docs/contributing/updating-changelogs.md`](docs/contributing/updating-changelogs.md).

### Releasing

Expand Down
29 changes: 29 additions & 0 deletions docs/contributing/updating-changelogs.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# Updating changelogs

Each package in this repo has a file named `CHANGELOG.md` which is used to
record consumer-facing changes that have been published over time. All
changelogs follow the ["Keep a Changelog"](https://keepachangelog.com/)
specification (enforced by `@metamask/auto-changelog`).

If a PR introduces a consumer-facing change to one or more packages, their changelogs must
be updated. This is enforced by CI. When updating changelogs, keep the following in mind:

- A changelog is not a git history; it is a summary of consumer-facing changes introduced by
a particular release.
- Consider each PR from the perspective of a consumer of an individual package. Changelog
entries may differ between packages.
- For example, if you're introducing feature X to package A, and it contains an incidental
change Y to package B, the package changelogs should reflect this.
- Describe entries in natural language; do not simply reuse the commit message.
- Unless you're cutting a new release, place new entries under the "Unreleased" section.
- Place changes into categories. Consult the ["Keep a Changelog"](https://keepachangelog.com/en/1.1.0/#how) specification for the list.
- Highlight breaking changes by prefixing them with `**BREAKING:**`.
- Omit non-consumer facing changes from the changelog.
- Use a list nested under a changelog entry to enumerate more details about a change if need be.
- Include links (e.g. `#123) to the pull request(s) that introduced each change.
- Combine like changes from multiple pull requests into a single changelog entry if necessary.
- Split disparate changes from the same pull request into multiple entries if necessary.
- Only included reverted changes if they were previously released.

If your PR does not contain any consumer-facing changes, add the label `no-changelog`, and the
changelog validation CI job will be skipped.
Loading