commit

# Commit Create clean, well-structured git commits that tell a coherent story. ## Process ### 1. Assess the Working Tree Run `git status` (never `-uall`) and `git diff` to understand what changed. Also run `git log --oneline -5` to match the repo's existing commit message style. If there are no changes, say so and stop. ### 2. Group Changes by Intent Look at the changed files and mentally group them: - **Feature**: new functionality (client + server + tests for the same feature = one commit) - **Fix**: bug fixes - **Refactor**: structural changes that don't change behavior - **Docs**: documentation-only changes (CLAUDE.md, README, comments) - **Test**: test-only additions or changes - **Chore**: config, dependencies, tooling Rules for grouping: - **Prefer fewer commits.** A feature that touches 15 files is still one commit if it's one logical change. - **Only split when intent is genuinely different.** "Add collaborative editing" is one commit even if it touches client, server, DB, and tests. But "add collaborative editing" + "fix unrelated CSS bug" should be two commits. - **For a first commit or large initial build, one commit is fine.** Don't artificially split an initial implementation. - **Docs updates that accompany code changes go in the same commit.** Only separate docs commits for docs-only changes. ### 3. Present the Plan Before committing, show the user: - How many commits you plan to make - For each commit: the message and which files are included - Ask...