Absolutely Loving the workflow ever since i added these instructions to the cursor rules
multi-agent
Score: 21 | Author: Sherisabre | Subreddit: r/cursor
Post Content
CusrorRules
ALWAYS update the Changelog.md under [Unreleased] when making changes and update the version number in ProjectSettings.asset (bundleVersion) when releasing a new version.
When Asked to Commit Staged Changes always check changelog to see if the changes in stagedfiles are represented in the changelog before commiting).
When releasing: Review [Unreleased] changes to determine version bump (features→minor, fixes→patch, breaking→major), move changes to new version section with date, update bundleVersion in ProjectSettings.asset, commit as "release: Version X.Y.Z", and create git tag.
here is the changelog files with the instructions.which cursor automatically read and ends up following the instructions inside it as well. what i added in the cursorrules kind of pushes it in the right direction.
it has been automatically updating it throughout my composer agent sessions, loving it. and when making a release i just say.
Do the Release Workflow
#Changelog
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
#Version Numbering
This project uses a three-number versioning system (X.Y.Z):
- X (Major): Breaking changes, major feature overhauls
- Y (Minor): New features, significant improvements
- Z (Patch): Bug fixes, minor improvements
Example: Version 1.2.3
- 1: Major version
- 2: Minor version
- 3: Patch version
When to increment:
- Major (X): When making incompatible changes that might break existing functionality
- Minor (Y): When adding functionality in a backward-compatible manner
- Patch (Z): When making backward-compatible bug fixes
#Making Changelog Entries
#For New Changes in Development:
- Add changes under the
[Unreleased]
section - Categorize them under appropriate headers:
Added
for new featuresChanged
for changes in existing functionalityDeprecated
for soon-to-be removed featuresRemoved
for removed featuresFixed
for bug fixesSecurity
for vulnerability fixesTechnical
for technical changes/dependencies
- Keep entries concise but descriptive
#When Releasing a Version:
- Convert the
[Unreleased]
section to a version number with date (e.g.,[1.0.0] - 2024-01-20
) - Create a new empty
[Unreleased]
section at the top
#General Rules:
- Newest changes always go at the top of the file
- Each version should be in descending order (newest to oldest)
- Group related changes under the same category
- Use bullet points for each entry
#Development Workflow:
- For Every Code Change:
- ALWAYS add an entry to the
[Unreleased]
section in this changelog - Write clear, descriptive change notes
- Categorize changes appropriately using the headers above
- Commit changes with meaningful commit messages
- ALWAYS add an entry to the
- For Version Releases:
- Move
[Unreleased]
changes to a new version section with today’s date - Update version number in
ProjectSettings.asset
(bundleVersion
) - Create a git tag for the version
- Create a new empty
[Unreleased]
section at the top
- Move
#Release Process:
When asked to make a release, follow these steps:
- Review Changes:
- Review all changes under
[Unreleased]
- Ensure all changes are properly categorized
- Verify all changes are documented
- Review all changes under
- Choose Version Number:
- For new features: increment minor version (0.1.0 → 0.2.0)
- For bug fixes: increment patch version (0.1.0 → 0.1.1)
- For breaking changes: increment major version (0.1.0 → 1.0.0)
- Update Files:
- Move
[Unreleased]
changes to new version section with today’s date - Update version in
ProjectSettings.asset
(bundleVersion
) - Create new empty
[Unreleased]
section
- Move
- Commit and Tag:
- Commit all changes with message “release: Version X.Y.Z”
- Create a git tag for the version (e.g.,
v0.2.0
)
#[Unreleased]
Key Takeaways
- No key quotes extracted