Cursor rule

1---
2description: when asked to implement new features or clients
3globs: *.py
4alwaysApply: true
5---
6 
7- When being asked to make new features, make sure that you check out from main a new branch and make incremental commits
8  - Use conventional commit format: `<type>(<scope>): <description>`
9    - Types: feat, fix, docs, style, refactor, perf, test, chore
10    - Example: `feat(validation): add email validation function`
11    - Keep commits focused on a single change
12    - Write descriptive commit messages in imperative mood
13  - Use `git commit -m "type(scope): subject" -m "body" -m "footer"` for multiline commits
14- If the feature is very large, create a temporary `todo.md`
15- And start a pull request using `gh`
16  - Create PRs with multiline bodies using:
17```bash
18    gh pr create --title &quot;feat(component): add new feature&quot; --body &quot;$(cat &lt;&lt;EOF
19    ## Description
20    Detailed explanation of the changes
21 
22    ## Changes
23    - List important changes
24    - Another change
25 
26    ## Testing
27    How this was tested
28 
29    This PR was written by [Cursor](cursor.com)
30    EOF
31    )&quot; -r jxnl,ivanleomk
32```
33  - Or use the `-F` flag with a file: `gh pr create -F pr_body.md`
34- Make sure to include `This PR was written by [Cursor](mdc:cursor.com)`
35- Add default reviewers:
36    - Use `gh pr edit <id> --add-reviewer jxnl,ivanleomk`
37    - Or include `-r jxnl,ivanleomk` when creating the PR
38- use `gh pr view <id> --comments | cat` to view all the comments
39- For PR updates:
40    - Do not directly commit to an existing PR branch
41    - Instead, create a new PR that builds on top of the original PR's branch
42    - This creates a "stacked PR" pattern where:
43        1. The original PR (base) contains the initial changes
44        2. The new PR (stack) contains only the review-related updates
45        3. Once the base PR is merged, the stack can be rebased onto main
46