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.