Add Cursor commands for commit and PR description generation

.cursor/commands/generate-commit.md

@@ -0,0 +1,45 @@
+# Commit Changes
+
+You are tasked with creating git commits for the changes made during this session.
+
+## Process:
+
+1. **Think about what changed:**
+   - Review the conversation history and understand what was accomplished
+   - Run `git status` to see current changes
+   - Run `git diff` to understand the modifications
+   - Consider whether changes should be one commit or multiple logical commits
+
+2. **Plan your commit(s):**
+   - Identify which files belong together
+   - Draft clear, descriptive commit messages
+   - Use imperative mood in commit messages
+   - This is very important: Use semantic commit messages in this format: <type>(<scope>): <short description>. Types must be one of: feat, fix, refactor, style, docs, test, chore. Never write plain English‑style messages.
+   - Focus on why the changes were made, not just what
+
+3. **Present your plan to the user:**
+   - List the files you plan to add for each commit
+   - Show the commit message(s) you'll use
+   - Ask: "I plan to create [N] commit(s) with these changes. Shall I proceed?"
+
+4. **Execute upon confirmation:**
+   - First make sure that my commits need to be signed. Maybe you will not be able to commit while inside sandbox.
+   - Use `git add` with specific files (never use `-A` or `.`)
+   - Create commits with your planned messages
+   - Show the result with `git log --oneline -n [number]`
+   - Push to remote origin
+
+## Important:
+- Do not commit anything to the `master` or `main` branch. If the user is not on a feature/working branch, you should warn the user and ask them for the new feature/working branch name.,
+- **NEVER add co-author information or any attribution**
+- **NEVER add "Made with: Cursor"**
+- Commits should be authored solely by the user
+- Do not include any "Generated with" messages
+- Do not add "Co-Authored-By" lines
+- If you believe that both a title and a detailed description is necessary for a commit message, please write both. In that case description should be separated from the title using a blank line. Also, in the description, if you can explain the _why_ and not just the _what_ will be awesome. The _why_ should be more business oriented rather than _tech_ oriented. But if both, _business_ and _tech_ are needed, add both.
+
+## Remember:
+- You have the full context of what was done in this session
+- Group related changes together
+- Keep commits focused and atomic when possible
+- The user trusts your judgment - they asked you to commit

.cursor/commands/generate-pr-description.md

@@ -0,0 +1,31 @@
+# PR Title and Description Generator
+
+You are helping me when I want to create a PR. The objective is to have a PR with an informative title and description.
+More details in the #Instructions below.
+
+## Git prerequisites
+
+Any step that compares a feature branch to `origin/main` must follow this sequence:
+
+1. **Fetch:** Run `git fetch origin main` to update local `origin/main` from the remote. Do not diff until this completes — a stale ref produces incorrect results.
+2. **Identify the feature branch:** Use the branch name the user provided, or `git branch --show-current`. Check out that branch if you are not already on it.
+3. **Check merge status:** Verify that `origin/main` is fully merged into the feature branch:
+   - Run `git merge-base --is-ancestor origin/main HEAD`.
+   - Exit code `0` means `origin/main` is already merged — continue to step 5.
+   - Non-zero means the branch is missing commits from `origin/main` — run `git log --oneline HEAD..origin/main` to list them.
+4. **Merge only with approval:** If the branch is behind `origin/main`:
+   - Tell the user their branch is missing commits from `origin/main` and show the `git log` output.
+   - Ask explicitly: *"Your branch does not include the latest origin/main. Shall I run `git merge origin/main`?"*
+   - Run `git merge origin/main` **only if the user confirms**. If they decline, stop and ask how to proceed — do not diff or continue until they resolve it or explicitly tell you to continue anyway.
+   - If the merge produces conflicts, stop and report them; do not auto-resolve.
+   - `git merge` may require running outside the sandbox (GPG commit signing) — see `AGENTS.md`.
+5. **Then diff:** Only after steps 1–4 are satisfied, compare or diff against `origin/main` (e.g. `git diff origin/main...<BRANCH_NAME>`).
+
+## Instructions
+
+1. Follow **Git prerequisites** above before comparing branches.
+2. Compare my current working branch to `origin/main`. Inspect the changes carefully. Also, check the commits in my PR and their comments. They will be useful to you to generate the PR title and description.
+3. Generate a concise PR title and a detailed PR description that would help my colleague engineers to understand what this PR is about. Please, follow the requirements in the bullet list below:
+    - Generate a temporary file in the temporary system folder with the PR description inside. IMPORTANT. Don't use the local repository tmp folder to create this file. Only the operating system temporary folder.
+    - The file should be in MD format so that I can easily copy / paste to our gitea web page when I will open a PR.
+    - If the changes introduce changes in the database, please, list the tables and the relevant changes with why they were introduced.