PR Name

When given a pull request, inspect its current title and diff before proposing a name. Treat the title as a changelog entry for developers, not as a high-level summary of the work and not as an inventory of everything that changed. Do not automatically reuse the commit message.

Choose the narrowest title that still explains the developer-facing change. Aim for the right abstraction level rather than maximum specificity: use one concrete anchor and one clear outcome.

Choose the prefix

Do not infer the prefix from the directory name or from a Conventional Commit scope such as fix(core). For a package change, read the affected package's package.json and use its exact name value.

By default, use that package name in the PR title:

`[package-name]`: [description]

For example:

`@remotion/shapes`: Add heart shape

If multiple packages are affected, use the package that owns the primary user-facing change, not necessarily the package with the most changed files.

Describe the change

Use these guidelines in order:

1. Identify the main developer-visible change from the diff.
2. If a public API is central to the change, name the primary API exactly in backticks and briefly explain what it does. Do not list supporting APIs.
3. Otherwise, describe what changed rather than the files or implementation steps used to achieve it. Include technical details only when they help developers understand the result.