// Write or review Kueue PR release notes. Use when a user asks to draft, refine, validate, or combine release notes for a Kueue pull request, especially when deciding whether the note should be framed as a bugfix, feature, observability improvement, or breaking change.
| name | kueue-release-notes |
| description | Write or review Kueue PR release notes. Use when a user asks to draft, refine, validate, or combine release notes for a Kueue pull request, especially when deciding whether the note should be framed as a bugfix, feature, observability improvement, or breaking change. |
| license | Apache-2.0 |
| metadata | {"copyright":"The Kubernetes Authors"} |
Use this skill when writing or reviewing a Kueue release note for a pull request.
The goal is to produce a concise, professional release note describing the user-observable change rather than only the implementation detail.
Final output is three release-note variants plus rationale for key decisions:
If the user asks for only one version, provide the Balanced variant.
For breaking changes, include a mitigation section starting exactly with ACTION REQUIRED:.
Use this when users must change manifests, Helm values, CLI flags, configuration, workloads, namespace layout, RBAC, CRDs, or operational procedures before or during upgrade.
The mitigation must be specific and actionable. For installer-specific behavior, distinguish Helm and manifest-based installs explicitly.
Example:
<Prefix>: <short description of changed behavior>.
ACTION REQUIRED: If <affected scenario>, <mitigation before upgrading>. <Optional caveat>.
Read the PR description, linked issue, release-note text, and relevant changed files.
Identify:
Do not rely only on the PR title. PR titles often describe the implementation, while release notes should describe the user-visible effect.
Describe what changes for users, operators, or integrators.
Good user-observable aspects include:
Avoid release notes that only say what code changed, such as:
If an implementation detail is important to understand the user-visible behavior, include it briefly after the scenario.
Default to one bullet with one or two sentences.
Use:
Fixed, Improved, Removed;Workload, ClusterQueue, LocalQueue, MultiKueueCluster, AdmissionCheck, namespaceSelector.Avoid:
For bugfixes, make the broken scenario clear.
Preferred shape:
<Prefix>: Fixed a bug where <scenario> could <bad user-visible effect>.
Optional second sentence:
Kueue now <brief fix or new behavior>.
Examples of good bugfix framing:
MultiKueue: Fixed a bug where one slow or unresponsive remote cluster could stall reconciliation for other MultiKueueClusters, even when `controller.groupKindConcurrency["MultiKueueCluster.kueue.x-k8s.io"]` was set above 1. This could delay or block workload admission through other healthy clusters.
KueueViz: Fixed the navigation bar to avoid layout breakage on narrow mobile screens.
Avoid starting with implementation details:
MultiKueue: Changed remote watch establishment to use per-cluster locking.
That implementation detail can be included only if it explains the user-visible outcome.
For features and enhancements, describe the new capability and why users or operators benefit from it.
Preferred shape:
<Prefix>: Added <capability>, allowing users to <user-visible outcome>.
If the feature is gated, mention the feature gate or configuration field only when users need it to use the capability.
Logs, metrics, events, and visibility endpoints are user-facing for operators.
Use Observability: when the main effect is improved debugging, reduced noise, corrected metrics, or clearer operational signals.
Examples:
Observability: Fixed `kueue_cohort_subtree_quota` and `kueue_cohort_subtree_resource_reservations` to report CPU resources in CPU units instead of raw milliCPU values.
Observability: Improved FairSharing strategy-evaluation logs by including DRS share values at verbosity level V(4).
Follow the critical breaking-change rule near the top of this skill.
The mitigation must tell affected users exactly what to change before upgrading.
When behavior differs by installation method, explicitly distinguish manifest-based and Helm-based installations.
Example mitigation details may include:
For deprecated option removals, name the removed option and its replacement.
Preferred shape:
<Prefix>: Removed the deprecated `<flag-or-field>` option. Use `<replacement>` instead.
Include a breaking-change mitigation when users must update their configuration before upgrading.
Start the note with a prefix that narrows the scope.
Prefer the smallest accurate user-facing area, for example:
MultiKueue:TAS:Helm:KueueViz:Observability:Scheduling:VisibilityOnDemand:LeaderWorkerSet:ElasticJobsViaWorkloadSlices:<integration name>: such as JobSet:, StatefulSet:, or RayJob:Use a combined prefix when the change is intentionally scoped to two areas, for example:
LeaderWorkerSet & StatefulSet:Helm and manifests:Avoid broad prefixes such as Kueue: unless the change truly affects the whole project or no narrower area applies.
Before proposing the final note, use this checklist as a starting point and add any PR-specific checks needed for accuracy:
Provide the final answer in this order:
The rationale should expand on the key decisions, especially:
<Prefix>: Fixed a bug where <scenario> could <user-visible impact>.
<Prefix>: Fixed a bug where <scenario> could <user-visible impact>. Kueue now <brief new behavior>.
<Prefix>: Added <capability>, allowing users to <user-visible outcome>.
Observability: Improved <logs|metrics|events|visibility endpoint> by <specific change>, making it easier to <debug|monitor|understand user-visible behavior>.
<Prefix>: <short description of changed behavior>.
ACTION REQUIRED: If <affected scenario>, <mitigation before upgrading>. <Optional caveat>.
<Prefix>: Removed the deprecated `<flag-or-field>` option. Use `<replacement>` instead.
ACTION REQUIRED: If your installation uses `<flag-or-field>`, remove it before upgrading and configure `<replacement>`.
Review that algorithm comments match the implementation. Use when a comment describes a formula or algorithm and you want to verify it matches what the code actually does.
Review that new CRD fields have complete godoc comments with enum value descriptions.
Review that paired operations and fields that always appear together are encapsulated in a helper or nested struct.
Review that local variables with unnecessarily wide scope are extracted into helper functions.
Review that new feature-gated behavior has explicit gate checks on all reachable code paths.
Review that update/mutation logic has integration test coverage in test/integration/.