Generate Labels
Overview
The generate_labels tool scans the PR code changes and generates custom labels for the PR based on the content and context of the changes.
It can be invoked manually by commenting on any PR:
/generate_labels
Example usage
Invoke the tool manually by commenting /generate_labels on any PR.
The tool will analyze the PR and add appropriate labels.
Configuration options
The generate_labels tool uses configurations from the [pr_description] section for custom labels.
Enabling custom labels
To use custom labels, you need to enable them in the configuration:
[config]
enable_custom_labels = true
Defining custom labels
You can define your own custom labels in the [custom_labels] section. See the custom_labels.toml file for examples.
Example configuration:
[custom_labels."Bug fix"]
description = "A fix for a bug in the codebase"
[custom_labels."Feature"]
description = "A new feature or enhancement"
[custom_labels."Documentation"]
description = "Documentation changes only"
[custom_labels."Tests"]
description = "Adding or modifying tests"
[custom_labels."Refactoring"]
description = "Code refactoring without functional changes"
How labels are applied
- The tool analyzes the PR diff and commit messages
- It uses AI to determine which labels best match the PR content
- Labels are automatically applied to the PR (if the git provider supports it)
- If labels cannot be applied directly, they are published as a comment
Both /generate_labels and /describe filter model-generated labels before publishing.
The allowed set contains the built-in PR types (Bug fix, Tests, Enhancement,
Documentation, Other) plus the configured custom label names when custom labels
are enabled. With custom labels enabled but no custom set configured, the default
set also includes Bug fix with tests. Matching ignores case, and unknown generated
labels are dropped with a warning. Existing human-added labels are preserved and
are not restricted by this filter.
Prompt enum keys such as bug_fix and RELEASE_READY are resolved to their
allowed display names, ignoring case. If a nonempty model response contains only
rejected labels, /generate_labels leaves the current labels unchanged. An
explicit labels: [] response retains the existing behavior of clearing old
bot-owned labels while preserving human-added labels.
Comparison with /describe labels
The /describe tool also generates labels as part of its output. The key differences are:
| Feature | /generate_labels | /describe |
|---|---|---|
| Purpose | Dedicated label generation | Full PR description with labels |
| Output | Labels only | Title, summary, walkthrough, and labels |
| Custom labels | ✅ Supported | ✅ Supported |
| Use case | When you only need labels | When you want a complete PR description |
Tips
- Use custom labels that match your team's workflow and labeling conventions
- Combine with automation to automatically label PRs when they are opened
- Review the generated labels and adjust custom label descriptions if the AI consistently misclassifies PRs