pr-name について
現在のタイトルと差分をもとにプルリクエスト名を決めるリポジトリ用スキルです。パッケージ変更、内部作業、ドキュメント、スキルの命名規則を示し、開発者に見える主な変更を正確に表す方法を説明します。
主な機能
- 01PR のタイトルと差分の確認
- 02変更種別に応じたプレフィックス選択
- 03対象パッケージの正式名称の使用
- 04開発者に見える主要な結果の記述
- 05ドキュメントとスキル向けの特別規則
活用シーン
- 01変更内容を確認して PR のタイトルを決定
- 02複数パッケージにまたがる変更のタイトル選定
- 03ドキュメントやスキル変更へのリポジトリ固有の接頭辞適用
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ remotion-dev/ remotion --skill pr-nameインストール後、Claude Code で/pr-nameを入力して読み込まれたか確認します。
詳細
プルリクエストを受け取ったら、タイトルを提案する前に現在のタイトルと差分を確認してください。タイトルは開発者向けの変更履歴として扱い、作業の概要や、変更内容をすべて列挙したものにはしないでください。コミットメッセージをそのまま使わないでください。
開発者向けの変更を説明できる範囲で、最も対象を絞ったタイトルを選んでください。最大限に具体的にするのではなく、適切な抽象度を目指してください。具体的な軸を1つ、明確な結果を1つ示します。
プレフィックスを選ぶ
ディレクトリ名や fix(core) のような Conventional Commit のスコープから、プレフィックスを推測しないでください。パッケージの変更については、影響を受けるパッケージの package.json を読み、name の値をそのまま使用してください。
デフォルトでは、そのパッケージ名をプルリクエストのタイトルに使用します。
`[package-name]`: [description]
例:
`@remotion/shapes`: Add heart shape
複数のパッケージに影響する場合は、変更ファイル数が最も多いパッケージとは限らず、ユーザー向けの主要な変更を担うパッケージを使用してください。
変更内容を説明する
以下のガイドラインを順に適用してください。
- 差分から、開発者に見える主な変更を特定します。
- 変更の中心となる公開 API がある場合は、その主要な API をバッククォートで正確に示し、機能を簡潔に説明します。補助的な API は列挙しないでください。
- それ以外の場合は、実現に使用したファイルや実装手順ではなく、何が変わったのかを説明します。技術的な詳細は、開発者が結果を理解する助けになる場合にのみ含めてください。
add、fix、remove、rename、change のような具体的な動詞を優先してください。差分からより明確に説明できる場合は、allow、improve、update handling、support のような曖昧な表現を避けてください。プルリクエストのタイトルには、簡潔で体言止めの表現を使用できます。文法的に完全な文にするためだけに冠詞や冗長な語句を加えないでください。明確さが増す場合は残してください。
タイトルの形式として、次のようなものが役立ちます。
`[package]`: Add `[api]()` for [concise purpose]
`[package]`: Add a `[name]` option to `[api]()` for [concise purpose]
`[package]`: Fix [observable problem] when [condition]
`[package]`: Change `[api]()` to [new observable behavior]
例:
`@remotion/studio-protocol`: Add `addElementLibraryToStudio()` for adding Element Libraries to the config
`@remotion/web-renderer`: Add a `metadata` option to `renderMediaOnWeb()` using Mediabunny's `MetadataTags`
`@remotion/studio`: Remove Asset Inspector quick action scrollbar
最初の例は、主要な API を示してその目的を説明しているため、「Add libraries to Studio」よりも適切です。Studio の CSS の例では、実装に使用した CSS ファイルやオーバーフロー規則ではなく、目に見える結果を意図的に説明しています。
特別な扱い
以下のいずれかに該当する変更には、パッケージ名ではなく、専用のプレフィックスを使用してください。変更されたファイルが含まれるパッケージのディレクトリだけで判断せず、ユーザー向けの影響に基づいて分類してください。
内部テスト、テスト用フィクスチャ、スナップショット、またはテスト基盤を追加、修正、安定化するだけで、リリース済みの動作を変更しない場合は、Internal: プレフィックスを使用してください。公開済みパッケージ内のパッケージ固有のテストにも適用されます。テストがそのパッケージ内にあるという理由だけで、パッケージ名をプレフィックスに使用しないでください。必要であれば、説明にパッケージ名を含めてもかまいません。
Internal: Stabilize registration range test in `@remotion/transitions`
リリース済みの実装変更にテストが伴う場合は、通常どおり影響を受けるパッケージのプレフィックスを使用してください。
ドキュメントのみの変更の場合:
Docs: Add page about heart shape
以下に該当する、より具体的なカテゴリがない内部モノレポ作業の場合は、Internal: プレフィックスを使用してください。
Internal: Simplify release bookkeeping
Remotion Elements に関する変更の場合は、Elements: プレフィックスを使用してください。
Elements: Add animated title element
packages/convert に関する変更の場合は、remotion.dev/convert プレフィックスを使用してください。
remotion.dev/convert: Support trimming
packages/example に関する変更の場合は、Internal Testbed としてください。
Internal testbed: Add trimming sample composition
スキルを追加または変更する場合は、Skills: をプレフィックスにしてください。
Skills: Add `/remotion-upgrade` skill
packages/brand に関する変更の場合は、remotion.dev/brand をプレフィックスにしてください。
remotion.dev/brand: Add animated logo
packages/it-tests に関する変更の場合は、Internal tests をプレフィックスにしてください。
Internal tests: Add video integration test