# Commit Me

> Use when staging and committing changes across one or multiple git repositories/workspaces, needing conventional commit messages, or grouping uncommitted changes into logical atomic commits.

- Skill: `w3wide/commit-me` (Agent Skill)
- Install (CLI): `npx skillmds@latest add w3wide/commit-me`
- Raw SKILL.md: https://api.skillmd.com/api/skills/w3wide/commit-me/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: w3wide (https://skillmd.com/u/w3wide)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/w3wide/commit-me

---


# Commit-Me Skill Guide

This skill guides the agent in staging and committing files across active git workspaces, splitting changes into logical, functional commit groups with Conventional Commit messages, utilizing a Preview & Confirm workflow.

## When to Use
- When committing changes across single or multiple active git workspaces.
- When multiple unrelated or loosely related changes need to be split into atomic, logical commits.
- When drafting clear Conventional Commit messages (`feat`, `fix`, `refactor`, `build`, etc.).

## When NOT to Use
- When the user explicitly instructs to run a raw `git commit -a` without grouping or confirmation.
- When committing changes without user authorization.

---

## Execution Workflow

Follow this systematic step-by-step workflow:

### Step 1: Scan and Detect Changes
1. Identify all active workspaces/repositories.
2. For each workspace, run `git status` to find all unstaged modified files, staged files, and untracked files.
3. If there are no changes across all workspaces, report: "No modifications detected in any active workspace." and terminate.

### Step 2: Group Changes Functionally
Analyze the diffs and file purposes. Group the changes into cohesive functional units:
- **Tightly Coupled Files**: If a change in a core model file requires updates in the view controller/screen, they MUST be grouped together in the same commit.
- **Separate Features**: If changes relate to distinct features (e.g., ads integration vs. color theme updates), they MUST be placed in separate commits.
- **Configurations**: Separate configuration files (e.g., `.gitignore`, `build.gradle`, config manifests) from functional source code changes when they are not directly required by the new feature code.

### Step 3: Format Conventional Commit Messages
For each group, draft a Conventional Commit message:
- Format: `<type>(<scope>): <intent-focused description in lowercase>`
- Types:
  - `feat`: New feature/mechanic
  - `fix`: Bug fix
  - `style`: Theme/style updates, color palette changes, layout styling (no logic change)
  - `refactor`: Code restructuring without adding features or fixing bugs
  - `build`: Build system, Gradle configs, dependency catalog/version updates
  - `chore`: Gitignore updates, tooling, repo maintenance
  - `docs`: Documentation updates
- **Intent-First Principle (Crucial)**:
  - Focus on WHY and WHAT subsystem is affected, rather than listing mechanical changes or raw variable names.
  - Never generate generic messages like "update dependencies", "fix bugs", or "update files".
  - For dependency updates, identify the functional objective/domain:
    * E.g., for auth/credential upgrades: `build(auth): upgrade google auth and credential manager dependencies`
    * E.g., for ads SDK: `build(ads): upgrade google admob sdk dependencies`
  - For code changes, describe the capability or behavioral impact.
- Examples:
  - `feat(ads): integrate Google AdMob rewarded revive callback`
  - `build(auth): upgrade google auth and credential manager dependencies`
  - `style(theme): update LightPalette hex color codes`
  - `chore(git): ignore local material-theme.json file`

### Step 4: Preview Plan and Request Approval
Present the proposed commit plan to the user in a clean markdown table. The preview MUST contain:
1. **Workspace**: The path/name of the repository.
2. **Commit Message**: The proposed Conventional Commit message.
3. **Target Files**: List of files to be included in this specific commit.

Ask the user: "Should I proceed with this commit plan?"
**CRITICAL**: You must wait for the user's explicit confirmation before running any commit command.

### Step 5: Execution
Once the user approves the plan:
1. For each planned commit group:
   - Run `git reset` on the workspace to ensure a clean staging state.
   - Run `git add <file1> <file2> ...` for files belonging to the current commit.
   - Run `git commit -m "<message>"` to commit the staged files.
2. After all commits are made, print a summary showing the commit SHAs, messages, and target workspaces.

---

## Common Mistakes to Avoid
- **Auto-committing without user confirmation**: Always preview first and get explicit permission.
- **Vague commit messages**: Avoid commit messages like "updated files" or "wip".
- **Bundling unrelated changes**: Do not combine configuration chores with core business logic changes in a single commit.