build(cursor): implement automation rules for commits and PRs

[RodolfoBonis]

Pull Request: Build Cursor - Implement Automation Rules for Commits and PRs

📋 Summary

This pull request introduces a new automation system for the Cursor tool, focusing on two key areas:

1. Individual Commit Automation: Utilizing conventional commit messages.
2. Automated Pull Request Creation: Generating detailed and structured PR descriptions.

🔧 Type of Change

• 🔧 Chore (maintenance, configuration)
• 📝 Documentation (development setup)

📁 Modified Files

• .cursor/rules/commit-flow.mdc: Rule for automating individual commits using conventional commits.
• .cursor/rules/pr-creation.mdc: Rule for automated creation of Pull Requests with structured descriptions.

💡 Motivation and Context

The primary goal of this implementation is to streamline the development workflow by providing:

1. Commit Automation:

   • When a user requests "commit changes", the system automatically:
     • Analyzes each modified file individually.
     • Classifies changes using conventional commits.
     • Creates well-documented and structured commits.

2. PR Automation:

   • Upon the request "create PR for [branch]", the system:
     • Analyzes differences between branches.
     • Generates detailed and structured descriptions.
     • Creates PRs using standardized templates.

🚀 How to Test

1. Testing the Commit Rule:

   # Make some changes to the files
   # Run: "commit changes"
   # Verify that individual commits were created

2. Testing the PR Rule:

   # Create a new branch with changes
   # Run: "create PR for main"
   # Verify that a PR was created with a detailed description

📝 Included Commits

• 509c131 - build(cursor): add commit flow automation rule
• ede8b35 - build(cursor): add PR creation automation rule
• b8b31fa - build(cursor): fix PR creation rule content

🔗 Related Issues

This implementation aims to enhance the development experience and standardize commits/PRs.

✅ Checklist

• Code reviewed and tested
• Documentation updated (Cursor rules)
• Conceptual tests performed
• No conflicts with the target branch
• Rules adhere to established standards
• PR and commit templates defined

🎯 Benefits

• Consistency: Ensures all commits follow conventional commit guidelines.
• Efficiency: Automation reduces the time required to create PRs.
• Quality: Standardized and detailed descriptions enhance clarity.
• Documentation: Automatically documents changes, improving traceability.

⚠️ Considerations for Reviewers

• Ensure that the automation rules align with the team's agreed-upon commit and PR standards.
• Review the newly added .mdc files for clarity and completeness.
• Consider potential edge cases in commit classification and PR generation.

Your feedback on these changes would be greatly appreciated! Thank you for your time and consideration.

[github-actions]

Code Review by OpenAI

Prompt too long for OpenAI: 10123 characters, sending only first 8000 characters
The code changes you've provided introduce two new markdown files: commit-flow.mdc and pr-creation.mdc. These files define automation rules for committing changes and creating pull requests (PRs) in a repository. Here’s a detailed review of the changes:

General Feedback

1. Clarity and Structure:

   • The files are well-structured and clearly outline the objectives, processes, and guidelines for both committing changes and creating pull requests. The use of headings and sections makes it easy to navigate.

2. Conventional Commits:

   • The incorporation of conventional commit types is beneficial for maintaining a consistent commit history and making it easier to generate changelogs or automate releases.

3. Automation Steps:

   • The step-by-step instructions for both committing and PR creation provide clear guidance on how to use the automation effectively. This will be helpful for users unfamiliar with the processes.

Specific Feedback on commit-flow.mdc

1. Initial Analysis:

   • The command git status is a good starting point. It might be beneficial to mention that this command should be run in the repository's root directory.

2. File Analysis:

   • The process of analyzing each modified file and classifying changes is clearly defined. Consider adding a note about how to handle files that do not fit neatly into one of the conventional commit types.

3. Commit Message Structure:

   • The commit message structure is well-defined. It might be helpful to mention that the body of the commit message should be wrapped at 72 characters for better readability.

4. Detailed Diff Analysis:

   • This section is crucial for understanding the impact of changes. Consider providing examples or templates for how to analyze the diff content effectively.

5. Final Summary:

   • The final summary of created commits is a nice touch. It could be beneficial to specify how this summary should be presented (e.g., as a markdown list).

Specific Feedback on pr-creation.mdc

1. Branch Analysis:

   • The section on branch analysis is clear. You may want to include a note on how to handle situations where the target branch is not specified by the user.

2. PR Description Generation:

   • The PR description template is comprehensive and covers all necessary aspects. However, consider adding examples for each section to guide users on what to include.

3. File Change Analysis:

   • This section is well thought out. It might be useful to provide examples of how to categorize changes for clarity.

4. Commit Analysis:

   • The analysis of commits is a great addition. It could be enhanced by suggesting how to handle commits that may not follow the conventional format.

5. Checklist:

   • The checklist at the end is a good practice to ensure quality before merging. It might be helpful to clarify what "Código revisado e testado" means in the context of the project, especially if the audience may not be familiar with Portuguese.

Additional Suggestions

• Examples: Including more examples throughout the documents could improve understanding, especially for users less familiar with Git or conventional commits.
• Version Control: Consider adding a version control section at the top of each file to track changes over time.
• Links to Resources: Providing links to external resources (like the Conventional Commits specification) could further help users understand the concepts being applied.

Conclusion

Overall, these changes enhance the automation and clarity of the commit and PR processes. The structure and content are solid, but incorporating examples and additional clarifications could further improve usability. Great job on this commit!