committing-changes

# Git Commit Conventions ## Branch Check Resolve the repository's default branch from the remote rather than assuming `main`. If the current branch is the default, ask for a branch name before staging or committing. Offer to suggest one and confirm before switching. If the default branch cannot be resolved, say so and confirm the current branch is intended before staging. ## Commit Message Format ``` [PM-XXXXX] <type>: <imperative summary> <optional body explaining why, not what> ``` ### Rules 1. **Ticket prefix**: Always include `[PM-XXXXX]` matching the Jira ticket 2. **Type keyword**: Invoke `Skill(labeling-changes)` to pick the conventional commit type. ### Examples ``` [PM-12345] feat: Add biometric unlock timeout configuration Users reported confusion about when biometric prompts appear. This adds a configurable timeout setting to the security preferences. ``` Ambiguous cases — choosing between similar types: ``` # Refactor that also fixes a bug? Use the primary intent: [PM-12345] fix: Resolve null pointer in vault sync retry logic # Test-only change: [PM-12345] test: Add unit tests for biometric timeout edge cases ``` ### Followup Commits Only the first commit on a branch needs the full format (ticket prefix, type keyword, body). Subsequent commits can use a short, descriptive summary with no prefix or body required. ``` Update error handling in login flow ``` --- ## Pre-Commit Quality Gate Before staging, run the `perform-preflight` skill for the full quality gate checklist (tests, lint, security, architecture). Consult the repo's CLAUDE.md for platform-specific build and lint commands.