Add git workflow cursor rule

.cursor/rules/502-git-workflow.mdc

@@ -0,0 +1,41 @@
+---
+name: Git workflow and pull request conventions
+description: Branching strategy, PR targeting, and git command guidance
+globs:
+  - '.git/**'
+  - '.github/pull_request_template.md'
+  - '.github/**/*.md'
+  - '**/*.md'
+alwaysApply: false
+---
+
+## Git Workflow and Branching Strategy
+
+### Branching Model
+
+- **Base branch**: All feature branches must be created directly from `main`
+- **Branch naming**: Use descriptive names with Jira ticket numbers (e.g., `feature/smar-123-add-new-bridge`, `fix/smar-456-hop-integration`, `chore/smar-789-update-deps`)
+  - Format: `{type}/{JIRA-TICKET}-{description}`
+  - Include Jira ticket number (e.g., `smar-123`) in branch name
+  - Use kebab-case for description
+
+### Pull Request Targeting
+
+- **Default target**: Pull Requests should target `main` directly
+- **Splitting large topics**: For large topics, it is acceptable to split into multiple smaller, focused PRs. In such cases:
+  - Create a feature branch from `main` (e.g., `feature/smar-123-large-topic`)
+  - Create multiple PRs targeting this feature branch (not `main`)
+  - This allows reviewing cumulative changes together in the GitHub changes tab
+  - Once all component PRs are merged into the feature branch, create a final PR from the feature branch to `main`
+- **Rationale**: Default to `main` simplifies review and reduces merge conflicts. Feature branch targeting for large topics enables better cumulative change review
+
+### Special Cases: Always Target Main
+
+Certain file types **must always** target `main`, regardless of whether related work is fully merged:
+
+- **`config/whitelist.json`**: Any PR that updates `whitelist.json` must target `main`, even if:
+  - The new network isn't fully merged yet with `main`
+  - The network is still not in `networks.json`
+  - This is totally fine and expected
+
+- **`config/composerWhitelist.json`**: Any PR that updates `composerWhitelist.json` must target `main`, following the same guidelines as `whitelist.json` (even if related network work isn't fully merged)

.cursor/rules/README.md

@@ -107,4 +107,5 @@ Users can either use the `/analyze-tx <network> <tx_hash>` command directly or t
 | `402-typescript-tests.mdc`     | Bun test structure and expectations for `.test.ts`              | ❌ On match | `**/*.test.ts`                                                                                                |
 | `500-github-actions.mdc`       | GitHub Actions workflows structure and conventions              | ❌ On match | `.github/workflows/**/*.yml`, `.github/workflows/**/*.yaml`, `.github/**/*.yml`, `.github/**/*.yaml`          |
 | `501-audits.mdc`               | Audit log and audit report management                           | ❌ On match | `audit/**/*.json`, `audit/**/*.pdf`, `.github/workflows/**/*audit*.yml`, `.github/workflows/**/*version*.yml` |
+| `502-git-workflow.mdc`         | Git workflow, branching strategy, and PR targeting conventions  | ❌ On match | `.git/**`, `.github/pull_request_template.md`, `.github/**/*.md`, `**/*.md`                                   |
 | `600-transaction-analysis.mdc` | Transaction analysis activation gate                            | ❌ On match | `**/*`                                                                                                        |