commit

# Commit Skill Organizes uncommitted changes into logical, well-structured conventional commits. ## Workflow ### Phase 1: Inventory 1. Run `git status` to see all staged, unstaged, and untracked changes 2. Run `git diff --stat` for unstaged changes and `git diff --cached --stat` for staged 3. Categorize each changed file by: - **Package**: shared, app, extension, api, docs, claude (config), root - **Type**: feat, fix, refactor, chore, docs, test, perf, ci - **Concern**: What logical unit of work does this belong to? ### Phase 2: Group into Commits Group changes into logical thematic commits. Rules: - Each commit should be a single coherent unit of work - Respect dependency order: shared changes before app/extension changes - Never mix unrelated concerns in one commit - Prefer fewer, well-scoped commits over many tiny ones - Config/tooling changes (`.claude/`, `CLAUDE.md`, scripts) go in their own commit Present the proposed grouping to the user: ``` Proposed commits (in order): 1. feat(shared): add JSDoc to coop module public exports - packages/shared/src/modules/coop/flows.ts - packages/shared/src/modules/coop/sync.ts 2. chore(claude): add visual verification hook and debug ladder - .claude/settings.json - .claude/skills/debug/SKILL.md - .claude/agents/cracked-coder.md 3. test(shared): add reusable test fixtures - packages/shared/src/__tests__/fixtures/index.ts Proceed? [y/n/edit] ``` **Wait for user approval before creating any commits.** ### Phase 3: Pre-commit Validation Before each commit: 1. Stage only the files for that commit (`git add <specific files>`) 2. Run `bun format` on staged files 3. Run `bun lint` to check for issues 4. If lint fails, fix and re-stage ### Phase 4: Create Commits For each approved group: 1. `git add <files>` 2. `git commit -m "type(scope): description"` using conventional commit format 3. Verify commit succeeded ### Phase 5: Summary After all commits: 1. Run `git log --oneline -N` (where N = number of new commits) 2. Report what was committed 3. **Never push** unless the user explicitly asks ## Commit Message Format ``` type(scope): concise description Optional body with context if the change is non-obvious. ``` - **Types**: feat, fix, refactor, chore, docs, test, perf, ci - **Scopes**: shared, extension, app, api, docs, claude, root - Keep subject line under 72 characters - Body explains "why", not "what" ## Modes - `--all`: Include all changes (staged + unstaged + untracked) - `--staged`: Only commit what's already staged - No flag: Interactive — show all changes, let user pick ## Safety Rules - Never push to remote unless explicitly asked - Never force-push - Never amend commits without asking - Never commit `.env`, `.env.local`, or credential files - Always present grouping for approval before committing - If changes span shared + downstream, commit shared first