commit

# Smart Commit Analyze outstanding changes and organize them into logical, well-structured commits. ## Process 1. **Check current state**: - Run `git status` to see all modified, staged, and untracked files - Run `git diff` to see unstaged changes - Run `git diff --cached` to see already staged changes 2. **Analyze changes**: - Read the changed files to understand what was modified - Group related changes by: - Feature/functionality (e.g., all auth-related changes together) - Type (e.g., refactoring, bug fix, new feature, docs, tests) - Component/module (e.g., all UI changes, all API changes) 3. **Propose commit groups**: - Present the proposed groupings to the user via AskUserQuestion - Each group should have: - List of files to include - Proposed commit message following conventional commits format - Ask user to confirm, adjust, or skip each group 4. **Create commits**: - For each approved group: - Stage only the relevant files with `git add <files>` - Create commit with the agreed message - Use `git add -p` approach if only parts of a file belong to a commit (ask user first) 5. **Summary**: Show final `git log --oneline -n <count>` of created commits ## Commit Message Format Follow conventional commits: ``` <type>(<scope>): <description> [optional body] Co-Authored-By: Claude <noreply@anthropic.com> ``` Types: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `style`, `perf` ## Examples **Single logical change:** ``` feat(auth): add OAuth2 login flow - Add OAuth2 provider configuration - Implement token refresh logic - Add login/logout UI components ``` **Mixed changes get split:** - `fix(api): handle null response in user endpoint` - `refactor(ui): extract Button component` - `docs: update README with setup instructions` ## Safety - Never commit files that look like secrets (.env, credentials, keys) - Always show the user what will be committed before committing - If unsure about grouping, ask the user