Curate Release

Curate the commit history of one pull request so that the release notes semantic-release generates from it read as a coherent story for the people who consume the published package. The commits are the changelog. A real fix typed chore is not merely unmentioned — it can leave the entire release unpublished.

This is a history rewrite only. File contents never change: the tree at HEAD when you finish must be byte-identical to the tree you started from.

When to Use

• A PR is ready to merge and its commits are wip, fix typo, address review, or otherwise meaningless to a customer reading a changelog.
• A repository publishes with semantic-release (or any Conventional Commits analyzer) and merges with a merge or rebase strategy, so individual commits survive into the release.
• An unattended routine fires on a gate label and must reshape the branch without a human present.

Do not use this skill to:

• Change what the code does. Use a normal edit-and-commit flow.
• Write a single commit message for work in progress. Write it directly.
• Curate history for a squash-only repository. Individual commits are discarded at merge; Phase 1 handles this case by proposing a squash title instead.
• Rebase onto a newer base, resolve conflicts, or merge the PR.