diff --git a/.cursor/rules/generate-commit-message.mdc b/.cursor/rules/generate-commit-message.mdc new file mode 100644 index 0000000000..a91d856e69 --- /dev/null +++ b/.cursor/rules/generate-commit-message.mdc @@ -0,0 +1,106 @@ +--- +description: This rule can be used to generate a git commit message. This rule depends on staged changes being available in the context to generate better commit messages. +alwaysApply: false +--- + +Act as an expert software engineer preparing a git commit. Your task is to generate a clear, concise commit message based on the staged changes in the current git repository. + +## Commit Message Format + +The commit message _must_ be a single line following the Conventional Commits standard: + +``` +type(scope): subject +``` + +**Maximum length: 50 characters total** + +### Rules + +1. **Format**: `type(scope): subject` + +2. **Type**: Choose the most appropriate type from: + + - `feat`: A new feature + - `fix`: A bug fix + - `refactor`: Code change that neither fixes a bug nor adds a feature + - `perf`: Performance improvement + - `style`: Formatting changes + - `test`: Adding or updating tests + - `docs`: Documentation only changes + - `build`: Build system or dependency changes + - `ci`: CI configuration changes + - `chore`: Other changes + +3. **Scope**: The primary package or area affected: + + - Single package: use the package name (e.g., `button`, `form-field`, `typography`) + - Tools: use the tool name (e.g., `build`, `cli`, `test`) + - Charts: use the chart component name (e.g., `chart-card`, `legend`) + - Chat: use the chat component name (e.g., `message`, `input-bar`) + - Multiple packages: use `*` or general scope (e.g., `deps`, `config`) + - Repository-level: use `repo`, `ci`, `docs`, etc. + +4. **Subject**: A concise description that: + - Uses lowercase (no capital first letter) + - Uses imperative mood ("add" not "added") + - Doesn't end with a period + - Is extremely concise to fit the 50 character limit + - Clearly states what the commit does + +--- + +## Examples + +**Good examples:** + +- `feat(button): add loading state` +- `fix(text-input): prevent cursor jump` +- `refactor(hooks): simplify useIdAllocator` +- `test(table): add sorting tests` +- `docs(button): update API examples` +- `chore(deps): upgrade typescript` +- `feat(*): add dark mode support` +- `fix(combobox): handle rapid filtering` + +**Bad examples:** + +- `feat(button): Added loading state` (uses past tense) +- `fix: bug fix` (too vague, missing scope) +- `Update button component` (missing type and scope) +- `feat(button): Add loading state.` (has period) +- `feat(button): Added a new loading state feature with spinner icon and animation support` (too long) + +--- + +## Instructions + +1. **Analyze the staged changes**: Review all staged files and their diffs to understand: + + - What packages or areas are affected + - What functionality is being added, changed, or removed + - Whether this is a bug fix, new feature, refactor, etc. + +2. **Determine the scope**: + + - If changes are in a single package, use that package name + - If changes span multiple packages, use `*` or an appropriate general scope + - For tooling/config changes, use appropriate scope like `build`, `ci`, `test` + +3. **Write the commit message**: + - Choose the correct type + - Add the scope in parentheses + - Write a concise description + - Ensure the total length is **50 characters or less** + - Be specific but brief + +--- + +## Tips + +- Each commit should represent one logical change +- Be specific but concise due to 50 char limit +- Use abbreviations when necessary (e.g., "config" not "configuration") +- Use present tense imperative: "add", "fix", "update", "remove" +- Prioritize clarity within the character constraint +- If you can't fit the message in 50 chars, simplify the description diff --git a/.cursor/rules/generate-pull-request-details.mdc b/.cursor/rules/generate-pull-request-details.mdc index 128fa820ae..0d94b23658 100644 --- a/.cursor/rules/generate-pull-request-details.mdc +++ b/.cursor/rules/generate-pull-request-details.mdc @@ -1,15 +1,15 @@ --- description: This rule can be used to generate pull request title and description. This rule depends on the `@Branch (Diff with Main Branch)` being included in the context to generate better pull request details. alwaysApply: false -manual: true --- Act as an expert software engineer preparing a pull request. Your task is to generate a PR title and a detailed PR description based on my current branch's diff with the main branch. First, follow these instructions to generate the **PR Title**: -- The final title must be in the format: `[JIRA-ID] type(scope): concise summary of the main change`. -- To find the `JIRA-ID`, inspect the content of any changed files located in the `.changeset/` directory. Extract the Jira ticket code (e.g., `LG-1337`). If you find multiple ticket codes, separate them with a `|` character (e.g., `[LG-1337|LG-4567]`). If no ticket code is found, omit the `[JIRA-ID]` portion entirely. +- The final title _must_ be in the format: `[JIRA-ID] type(scope): concise summary of the main change`. +- To find the `JIRA-ID`, inspect the content of any changed files located in the `.changeset/` directory. Extract the Jira ticket code (e.g., `LG-1337`). +- If you find multiple ticket codes, separate them with a `|` character (e.g., `[LG-1337|LG-4567]`). If no ticket code is found, omit the `[JIRA-ID]` portion entirely. - The `type` (e.g., `feat`, `fix`, `chore`) must follow the Conventional Commits standard based on the most significant change you analyze. - The `scope` should be the most relevant area or component affected (e.g., `button`, `api`, `auth`). - The summary should be a concise, lowercase description of the main change. @@ -21,12 +21,14 @@ Next, use the following template **exactly** to generate the **PR Description**. **IMPORTANT CHECKLIST LOGIC:** You must choose **only one** of the two checklists provided below. To decide which one to use, analyze the file paths in the staged git changes. 1. If you detect that a **net-new directory** has been created directly under `packages/`, `tools/`, `chat/`, or `charts/`, then you **must** use the "For new components" checklist. + ```markdown -- [ ] I have added my new package to the global tsconfig - [ ] I have added my new package to the Table of Contents on the global README - [ ] I have verified the Live Example will look as intended on the design website. ``` + 2. Otherwise, use the "For bug fixes, new features & breaking changes" checklist. + ```markdown - [ ] I have added stories/tests that prove my fix is effective or that my feature works - [ ] I have added necessary documentation (if appropriate) @@ -38,7 +40,11 @@ Do not include both checklists in your final output. ```markdown ## ✍️ Proposed changes -[Generate a **brief and clear** description of the big picture changes and why they are being made. If it fixes a bug or implements a feature, concisely explain the problem being solved.] +[ +Generate a **brief and clear** description of the big picture changes and why they are being made. +If it fixes a bug or implements a feature, concisely explain the problem being solved. +If this summary is longer than 2 paragraphs, include a "TL;DR" section at the top of the summary +] 🎟️ _Jira ticket:_ [Generate a link here using the TICKET-ID(s) you found, like `[LG-1234](https://jira.mongodb.org/browse/LG-1234)`]