mcpField
P
prepare-release-notes

prepare-release-notes

github.com/remix-run開発56.6k99 回インストール今日更新
リポジトリ

prepare-release-notes について

React Router のメンテナー向けワークフロースキルです。未処理の変更ファイルを整え、必要に応じてリリース向けの説明を加えます。検証とプレビューの手順も含みます。

主な機能

  1. 01未処理の変更ファイルを確認
  2. 02リリース項目の文言を統一
  3. 03詳細説明の必要性を判断
  4. 04リリース出力を検証・プレビュー

活用シーン

  1. 01React Router の変更ファイルの推敲
  2. 02リリース説明の追加要否の判断
  3. 03生成されたリリースノートの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/remix-run/react-router --skill prepare-release-notes

インストール後、Claude Code で/prepare-release-notesを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yamlreferences/whats-changed.md

詳細

リリースノートの準備

保留中の React Router 変更ファイルを整え、生成された変更リストを超えてリリースに物語的な文脈が必要な場合にのみ、手動のリリースノートを追加します。

ワークフロー

  1. ローカルの状態を確認します:
git status --short
find packages -path '*/.changes/*.md' -not -name README.md -not -name .gitkeep -print | sort

  1. 保留中のすべての変更ファイルを読みます。生成された変更履歴やリリース済みノートを直接編集しないでください。

  2. 各変更ファイルを正規化します:

    • 本文から feat:、feat(...)、fix:、fix(...) のセマンティックコミットプレフィックスを削除する
    • 最初の行と最上位のリリース箇条書きには現在形または命令形を使用する: Add、Fix、Remove、Support、Stabilize、Preserve、Update、Avoid、Prevent、Throw、Warn、Expose を優先する
    • ネストされた詳細の箇条書きは、親の箇条書きを補足するものであれば説明的なままでよい。現在形または命令形を強制するためだけに書き換えないこと
    • リリース生成は最初の箇条書き行の後に PR/コミットリンクを付加するため、箇条書き項目から文末のピリオドを削除する
    • ネストされた箇条書き項目からも文末のピリオドを削除する。ただし、句読点がコード、URL、略語、バージョン番号、または削除すると誤りになるその他のトークンの一部である場合は除く
    • 1 つの箇条書きに複数の文が含まれる場合は、より短い親の箇条書きとネストされた箇条書き項目に分割する
    • 最初の行は簡潔でユーザー向けに保つ。詳細や移行に関する注意事項にはネストされた箇条書きを使用する

  3. scripts/changes/whats-changed.md が必要かどうかを検討します:

    • 判断に迷う場合は CHANGELOG.md の例や references/whats-changed.md を読む
    • scripts/changes/whats-changed.md は、機能、将来のフラグの安定化、不安定なフラグ、移行ガイダンス、破壊的なバグ修正、または長文や例を必要とする複雑な挙動に対してのみ追加する
    • 通常のバグ修正、依存関係のクリーンアップ、内部リファクタリング、またはすでに明確なリリース箇条書きには追加しない
    • 追加する場合は本文のみを書く。リリーススクリプトが欠落している場合に ### What's Changed を追加する

  4. 検証します:

pnpm changes:validate
pnpm changes:preview

changes:preview を使用して、生成されたルートのリリースノートを確認し、PR/コミットリンクの配置、セクションの順序、および手動の What's Changed の配置を検証します。依存関係が不足している場合や、コマンドがこの文脈に対してコストが高すぎる場合は、何をスキップしたかを述べてください。

変更ファイルのスタイル

単一行のエントリは、自動的に付加される PR リンクと合わせてよく読めるようにする必要があります:

Fix `href()` to stringify and URL-encode param values like `generatePath()`

追加の文にはネストされた箇条書きを使用します:

Fix route ranking for dynamic parameters with static extension suffixes

- Identify `/:name.xml` as a dynamic segment instead of a static segment
- Preserve static route priority for paths like `/sitemap.xml`

セマンティックコミットプレフィックスは避けてください:

Add support for nub as a package manager

次のようにしないでください:

feat: add support for nub as a package manager.

What's Changed のガイダンス

scripts/changes/whats-changed.md は、パッケージ固有の箇条書きではなく、リリースレベルの物語に使用します。適した候補には以下が含まれます:

  • サンプルコードがあると役立つ、新しいユーザー向け API または機能
  • 不安定な API/フラグの安定化または名称変更。特に採用者が移行を強いられる場合
  • 挙動を変更し、採用ガイダンスを必要とする安定した将来のフラグ
  • デプロイ時の確認を必要とする可能性がある破壊的なバグ修正またはアダプター/ランタイムの挙動変更
  • 個々の箇条書きリストよりも、組み合わせた効果の方が重要な関連する変更の集まり

トーンは直接的かつ実用的に保ちます。生成された ### What's Changed セクションの下に見出しを使用することを優先します:

#### Feature Name

Explain what changed, who it affects, and how to adopt it.

```ts
// Optional short example
```

Minor/Patch/Unstable Changes のすべての箇条書きを重複させないでください。通常の PR レベルの詳細は、生成された変更ファイルに任せます。

既存の変更履歴から抽出した例については references/whats-changed.md を参照してください。

コメント

Markdown 対応