docs: add backporting guide and Claude Code project guidelines

Add a contributing guide for backporting changes to stable branches,
covering branch naming conventions, commit message scoping, and the
workflow for creating matching PRs. Also add CLAUDE.md with project
context for Claude Code.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: Saadnajmi

CLAUDE.md

@@ -0,0 +1,49 @@
+# React Native macOS - Claude Code Guidelines
+
+## Repository structure
+
+This is a monorepo fork of React Native with macOS support. Key directories:
+- `packages/react-native/` — Main `react-native-macos` package
+- `packages/virtualized-lists/` — Forked `@react-native-macos/virtualized-lists`
+- `packages/nx-release-version/` — Internal versioning tooling (private)
+- `private/` — Internal packages (eslint plugins, test utils)
+- `docsite/` — Docusaurus documentation site
+- `scripts/releases/` — Release and version bump scripts
+
+## Branching and backporting
+
+When making changes that apply to both `main` and a stable branch (e.g., `0.81-stable`):
+
+1. **Branch naming**: Use `<name>` for main, `0.81/<name>` for stable
+2. **Commit messages**: Use `fix: ...` for main, `fix(0.81): ...` for stable
+3. **Code parity**: Code changes should be identical between branches — only version numbers and branch-specific values should differ
+4. **Create two PRs**: One targeting `main`, one targeting the stable branch
+
+Example:
+```shell
+# Main branch
+git checkout -b fix-something main
+# make changes, commit, push
+
+# Stable branch
+git checkout -b 0.81/fix-something 0.81-stable
+# apply same changes, commit, push
+
+# Create PRs for both
+gh pr create --base main --head fix-something
+gh pr create --base 0.81-stable --head 0.81/fix-something
+```
+
+## Versioning
+
+- **`@react-native/*` packages**: Track upstream React Native version (from `react-native-macos`'s peerDependency on `react-native`). These are all private in this fork.
+- **`react-native-macos` + `@react-native-macos/virtualized-lists`**: Track the macOS release version. Published to npm.
+- **`@react-native-macos/nx-release-version`**: Private internal tooling, pinned to `0.1.0`.
+- Releases are done via `yarn nx release` on stable branches.
+- Run `yarn constraints` to verify version consistency. Use `yarn constraints --fix` to auto-fix.
+
+## Testing changes
+
+- `yarn constraints` — Verify monorepo version consistency
+- `yarn eslint` — Lint check (includes package.json manifest rules)
+- `yarn jest` — Run tests

docsite/docs/contributing/backporting.md

@@ -0,0 +1,78 @@
+---
+sidebar_label: 'Backporting changes'
+sidebar_position: 4
+---
+
+# Backporting changes to stable branches
+
+When a fix or feature lands on `main`, it often needs to be backported to an active stable branch (e.g., `0.81-stable`). To keep code changes consistent between branches, we create matching PRs against both `main` and the stable branch.
+
+## Branch naming convention
+
+| Target branch | PR branch name |
+|---|---|
+| `main` | `<name>` |
+| `0.81-stable` | `0.81/<name>` |
+
+For example, for a fix called `fix-release-constraints`:
+- `fix-release-constraints` → targets `main`
+- `0.81/fix-release-constraints` → targets `0.81-stable`
+
+## Step-by-step guide
+
+### 1. Create the main branch first
+
+```shell
+git checkout -b fix-something main
+# Make your changes
+git commit -m "fix: description of the fix"
+git push origin fix-something
+```
+
+### 2. Create the stable branch with the same changes
+
+```shell
+git checkout -b 0.81/fix-something 0.81-stable
+# Apply the same code changes (cherry-pick, manual, etc.)
+git commit -m "fix(0.81): description of the fix"
+git push origin 0.81/fix-something
+```
+
+:::tip
+Code changes should be identical between both branches. The only differences should be version numbers or other branch-specific values that naturally differ between `main` and stable.
+:::
+
+### 3. Create two PRs
+
+- One PR from `fix-something` → `main`
+- One PR from `0.81/fix-something` → `0.81-stable`
+
+Use the `(0.81)` scope in the commit message and PR title for the stable branch version:
+- `main`: `fix: description of the fix`
+- `0.81-stable`: `fix(0.81): description of the fix`
+
+### Cherry-picking as an alternative
+
+If the changes apply cleanly, you can cherry-pick from the main branch:
+
+```shell
+# After committing on the main branch
+git checkout -b 0.81/fix-something 0.81-stable
+git cherry-pick <commit-sha-from-main>
+# Resolve any conflicts, then push
+git push origin 0.81/fix-something
+```
+
+### Running constraints after changes
+
+After making changes on a stable branch, always verify that yarn constraints pass:
+
+```shell
+yarn constraints
+```
+
+If there are violations, you can auto-fix them:
+
+```shell
+yarn constraints --fix
+```