-
Notifications
You must be signed in to change notification settings - Fork 1.3k
chore: add cursor rule for release notes #9033
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
.cursor/rules/release-notes.mdc
Outdated
| feat | Enhancements| | ||
| fix | Fixes | | ||
| docs | Documentation | | ||
| alpha, beta, rc | Under Construction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when I ran this locally, it classified the autocomplete changes as enhancements but probably should've been "under construction". Can we also include in these rules that Cursor should make an effort to scan the associated packages for a release tag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i tried prompting it locally to do this and it seems to do better (moved the autocomplete changes to under construction and the XL dialog one to S2) so it might be possible even though it can't access the pulls directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay so...i tried my best to get it to scan for packages and their release tags but it really is a hit or miss. i've found that i have to prompt it again to look more carefully but at least i don't need to specify a specific component package
5a86d32
I ended up splitting up the rules since I found Cursor performs better with more targeted rules. When I had it all together in one file, sometimes it would leave out commits even when I specified to keep all of them. It also allows us to make adjustments in between steps (like changing which commits go under which category). So yeah, you will have to run it minimum 3x but I think it produces better results. |
Build successful! 🎉 |
Build successful! 🎉 |
## API Changes
react-aria-components/react-aria-components:GridListSectionProps-GridListSectionProps <T> {
- aria-label?: string
- children?: ReactNode | (T) => ReactElement
- className?: string = 'react-aria-GridListSection'
- dependencies?: ReadonlyArray<any>
- id?: Key
- items?: Iterable<T>
- style?: CSSProperties
- value?: T
-} |
Can we use the planning feature to assist with this? https://cursor.com/docs/agent/planning |
ooo interesting, i'll take a look tomorrow |
Ah okay, so the planning feature is kinda interesting because you have this conversation with the Agent to actually build a plan of execution which actually takes more time (?) because then you have to edit it, converse with it, etc. It does say you can save it to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to work well, I think we'll just need to be cognizant that it might not catch everything, but we can pretty easily confirm that via comparing the count of commits classified vs the total number of commits
The way this works is that you have to give the cursor chat two files for context, one containing the release notes rules, and the other a file containing a list of the commits obtained by running our changelog script.
It's not perfect and will still require us to go through manually and fix things, but it's better than nothing!
✅ Pull Request Checklist:
📝 Test Instructions:
🧢 Your Project: