Menu
Write a description to description GitHub Pull Request.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Generate documentation for new components. Use when writing docs, documenting components, or creating component documentation.
Create story examples for components. Use when writing stories, creating examples, or demonstrating component usage.
Action definitions and keyboard shortcuts in GPUI. Use when implementing actions, keyboard shortcuts, or key bindings.
Async operations and background tasks in GPUI. Use when working with async, spawn, background tasks, or concurrent operations. Essential for handling async I/O, long-running computations, and coordinating between foreground UI updates and background work.
Context management in GPUI including App, Window, and AsyncApp. Use when working with contexts, entity updates, or window operations. Different context types provide different capabilities for UI rendering, entity management, and async operations.
Implementing custom elements using GPUI's low-level Element API (vs. high-level Render/RenderOnce APIs). Use when you need maximum control over layout, prepaint, and paint phases for complex, performance-critical custom UI components that cannot be achieved with Render/RenderOnce traits.
| name | github-pull-request-description |
| description | Write a description to description GitHub Pull Request. |
We less than 150 words description for a PR changes, including new features, bug fixes, and improvements. And if there have APIs break changes (Only crates/ui changes) we should have a section called ## Breaking Changes to list them clearly.
When a pull request introduces breaking changes to a codebase, it's important to clearly communicate these changes to users and developers who rely on the code. A well-written breaking changes description helps ensure that everyone understands what has changed, why it has changed, and how to adapt to the new version.
We can get the changes from the PR diff and summarize them in a clear and concise manner. Aim to provide a clear APIs changes for users to follow.
We pefer the following format for breaking changes descriptions:
diff.## Breaking Changes as the section title.For example:
## Breaking Changes
- Added `id` parameter to `Sidebar::new`.
```diff
- Sidebar::new()
+ Sidebar::new("sidebar")
```
- Removed the `left` and `right` methods; use `side` instead.
> Default is left.
```diff
- Sidebar::right()
+ Sidebar::new("sidebar").side(Side::Right)
```