diff --git a/.cursor/rules/commit-changes-rules.mdc b/.cursor/rules/commit-changes-rules.mdc new file mode 100644 index 0000000..e5b9324 --- /dev/null +++ b/.cursor/rules/commit-changes-rules.mdc @@ -0,0 +1,55 @@ +--- +description: Rules for commiting and pushing changes +globs: +alwaysApply: false +--- +# Commit Changes Guidelines + +When making changes to the codebase, follow these guidelines for committing your work: + +## Analysis Process +1. Run `git --no-pager status` to see which files have changed +2. Run `git --no-pager diff` to see the actual changes in the code +3. Analyze the changes to understand the purpose and impact + +## Commit Process +1. Review and stage your changes +2. Prepare a proper commit message (see format below) +3. Commit the changes +4. Push to remote repository + +## Commit Message Format +- Title: One sentence summary (max 120 characters) +- Empty line +- Body: Bullet list of changes (with NO extra lines between bullet points) +- No additional text + +## Example: +``` +Add user authentication to login page + +- Add password validation function +- Create JWT token generation +- Add error handling for invalid credentials +``` + +## Git Command Format +For creating commit messages with proper formatting, use one of these approaches: + +### Method 1: Build commit message using separate echo commands +``` +# Create commit message file line by line +echo "Your commit title" > /tmp/commit-msg.txt +echo "" >> /tmp/commit-msg.txt +echo "- First bullet point" >> /tmp/commit-msg.txt +echo "- Second bullet point" >> /tmp/commit-msg.txt +echo "- Third bullet point" >> /tmp/commit-msg.txt + +# Commit using the file and clean up +git commit -F /tmp/commit-msg.txt && rm /tmp/commit-msg.txt +``` + +### Method 2: For simple commits, use the -m flag twice +``` +git commit -m "Your commit title" -m "- First bullet point" +``` diff --git a/.cursor/rules/conventional-commits.mdc b/.cursor/rules/conventional-commits.mdc deleted file mode 100644 index 464944b..0000000 --- a/.cursor/rules/conventional-commits.mdc +++ /dev/null @@ -1,67 +0,0 @@ ---- -description: "Enforces conventional commit message format for better version control and changelog generation" -globs: ["**/*"] ---- - -# Conventional Commit Messages - -Use the Conventional Commit Messages specification to generate commit messages. - -## Commit Message Structure - -``` -[optional scope]: - -[optional body] - -[optional footer(s)] -``` - -## Commit Types - -- `fix`: Patches a bug in your codebase (correlates with PATCH in Semantic Versioning) -- `feat`: Introduces a new feature to the codebase (correlates with MINOR in Semantic Versioning) -- `BREAKING CHANGE`: Introduces a breaking API change (correlates with MAJOR in Semantic Versioning) -- Other allowed types: `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` - -## Specification Details - -1. Commits MUST be prefixed with a type, followed by an OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space -2. The type `feat` MUST be used when adding a new feature -3. The type `fix` MUST be used when fixing a bug -4. A scope MAY be provided after a type, surrounded by parenthesis (e.g., `fix(parser):`) -5. A description MUST immediately follow the colon and space -6. A longer commit body MAY be provided after the short description -7. One or more footers MAY be provided one blank line after the body -8. Breaking changes MUST be indicated in the type/scope prefix or as a footer -9. If included as a footer, a breaking change MUST use: `BREAKING CHANGE: description` -10. If included in the type/scope prefix, breaking changes MUST use `!` before the `:` -11. Types other than `feat` and `fix` MAY be used -12. Information MUST NOT be treated as case sensitive, except for `BREAKING CHANGE` -13. `BREAKING-CHANGE` MUST be synonymous with `BREAKING CHANGE` - -## Examples - -``` -feat: add new authentication system - -This commit adds a new authentication system using JWT tokens. -The system supports both local and OAuth authentication methods. - -BREAKING CHANGE: Authentication endpoints have been moved to /api/v2/auth -``` - -``` -fix(parser): handle empty input gracefully - -Previously, the parser would throw an error when given empty input. -This commit adds proper handling for empty input cases. -``` - -``` -chore: update dependencies - -- Update React to v18.2.0 -- Update TypeScript to v4.9.5 -- Update Jest to v29.5.0 -``` \ No newline at end of file diff --git a/.cursor/rules/pull-request-rules.mdc b/.cursor/rules/pull-request-rules.mdc new file mode 100644 index 0000000..1f8c0c7 --- /dev/null +++ b/.cursor/rules/pull-request-rules.mdc @@ -0,0 +1,64 @@ +--- +description: Rules for creating and updating pull requests +globs: +alwaysApply: false +--- +Rule Name: pull-request-rules +Description: +# Pull Request Guidelines + +When creating or updating a pull request, follow these guidelines: + +## Analysis Process +1. Run `git --no-pager status` to see which files have changed +2. Run `git --no-pager diff` to compare the current branch with main +3. Analyze the changes to understand the purpose and impact + +## Pull Request Types + +- `fix`: Patches a bug in your codebase (correlates with PATCH in Semantic Versioning) +- `feat`: Introduces a new feature to the codebase (correlates with MINOR in Semantic Versioning) +- `BREAKING CHANGE`: Introduces a breaking API change (correlates with MAJOR in Semantic Versioning) +- Other allowed types: `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` + +## Specification Details + +1. Title MUST be prefixed with a type, followed by an OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space +2. The type `feat` MUST be used when adding a new feature +3. The type `fix` MUST be used when fixing a bug +4. A scope MAY be provided after a type, surrounded by parenthesis (e.g., `fix(parser):`) + +## Pull Request Format +- Title: One sentence summary (max 120 characters) +- Body: + - Bullet list of changes (with NO extra lines between bullet points) + - After the list, add a brief explanation of why this PR is needed +- Do NOT repeat the title in the body + +## Example: +``` +feat: Add user authentication to login page + +Body: +- Add password validation function +- Create JWT token generation +- Add error handling for invalid credentials + +This feature is necessary to secure user accounts and prevent unauthorized access to the application. +``` + +## PR Description Formatting +When creating a PR, ensure that: +- The title is not repeated in the body +- All bullet points are written without extra lines between them +- The body starts directly with bullet points (no introductory text) +- When using GitHub CLI, use `--body-file` instead of `--body` to avoid escape character issues +- Always create the PR body file in the `/tmp/` folder (e.g., `/tmp/pr-body.md`) +In GitHub or similar platforms, preview the PR description to verify there are no unwanted +line breaks between bullet points. + +## Process +1. Analyze changes between main and current branch +2. Create PR title and bullet list description +3. Create new PR or update existing PR tied to current branch +4. Request review if needed diff --git a/.gitignore b/.gitignore index 8e54458..2905a26 100644 --- a/.gitignore +++ b/.gitignore @@ -15,10 +15,6 @@ lerna-debug.log* *.swo .DS_Store -# mcp executable -mcp -mcp-config.json - # JetBrains IDE .idea/