Git Rules
Clean commits, PRs, and issues for a React Native / Expo codebase.Recon (Always Run First)
Before planning anything, gather full context:- 2–4 user-facing bullets (what the user would notice)
- 1–3 technical bullets (architecture, perf, cleanup)
Branch Naming
Format
Examples
Rename Branch If Scope Changes
Commit Conventions
Format
Types
Scope
Derive from diff paths first, then feature intent. Pick one primary scope per commit.Known Scopes
Known Scopes
Creating New Scopes
Creating New Scopes
Create new scopes freely when the change doesn’t fit an existing one.Derive from the most specific directory or feature name — don’t force-fit into the table above.New scopes are cheap; vague scopes are expensive.
Commit Message Examples
When to Commit
Commit if any are true:- ✅ UI or user behavior changed
- ✅ Non-trivial fix, perf improvement, or refactor
- ✅ New files added or risky logic touched (payments, keys, storage, networking)
- ✅ Config, tooling, patches, or lockfile changed
Staging
Stage precisely — usegit add -p for mixed files. Plan 2–6 commits for non-trivial work.
Validation Gate
npm run pretty then re-check.
If any other check fails, fix and git commit --amend.
Secret Scanning (Non-Negotiable)
Before staging ANY file, scan diffs for secrets. Refuse to commit if found:- Passwords, API keys, tokens, session cookies
- Mnemonics (12–24 words),
xprv, WIF, raw private keys - Nostr secrets (
nsec1...), hex private keys .envcontents, credential files
If Found
1
Remove from diff
Unstage the file and remove the secret.
2
Confirm .gitignore coverage
Add the file pattern to
.gitignore if not already covered.3
Advise secret rotation
If the secret was already committed, rotate it immediately.
Pull Requests
Push and open PR when work is ready for review:PR Rules
- Title = final conventional commit subject (this becomes the squash-merge message)
- Body is the commit message body — concise, scannable, no filler
- Use
gh pr editto update if scope changes after opening - Link related issues:
Closes #NorRelated: #N
PR Template
GitHub Issues (Rare — Unresolved Bugs Only)
File an issue only when:- A bug was investigated but couldn’t be fixed in the current session
- The root cause is identified but the fix is out of scope or risky
- A flaky behavior needs tracking for future debugging
Issue Rules
- Title is a conventional commit subject (so it reads well in lists)
- Body captures agent context — the investigation is the value
- Label if
ghlabels are available:bug,investigation,help-wanted - Never file issues for feature requests or tasks — only unresolved bugs from the current session
Issue Template
Quick Reference
Complete Workflow Example
1
Create branch
2
Make changes
Write code following contributing guidelines.
3
Run quality checks
4
Stage changes
5
Commit
6
Push and create PR