smart-git-automation – Agents & Automation skill for AI agents

What I do

• Intelligently detect and group related changes
• Auto-generate descriptive branch names from changes
• Streamlined workflow: scan → branch → commit → push → PR with fewer prompts

When to Use

Use this when you want a faster, smarter git workflow that groups changes logically and reduces manual confirmation overhead.

Before grouping, preserve existing staged changes and read repository instructions. Inspect full unstaged/staged diffs and untracked files, not just names/stats; file grouping is advisory and must not absorb unrelated user work. Use the repository branch prefix/template and required checks. For forks, distinguish the upstream PR base from the fork head/remote; verify owner/repo and full head SHA before creation. An amend rewrites history and is not implied by a routine commit request.

Workflow Steps

1. Smart Detection & Grouping

Run in parallel:

• git status - check what's changed
• git diff --stat - see file modification summary
• git diff --name-only - list changed files only
• git diff --staged --stat - see what's already staged

Analyze changes to group them logically:

• Files in the same module/directory → likely related
• Files that were modified together in recent edits → likely related
• New files that complement each other → likely related

Present grouped changes in a clear format, e.g.:

📁 Group 1: UI Components
  - src/components/Button.tsx (modified)
  - src/components/Button.test.tsx (modified)

📁 Group 2: API Layer
  - src/api/client.ts (new)
  - src/api/types.ts (modified)

2. Auto Branch Name Generation

Generate branch name from dominant change pattern:

• Use format: <type>/<short-description>
• Types: feature, fix, refactor, docs, test, chore
• Derive description from most significant changed file/feature
• Convert to kebab-case, max 50 chars
• Examples:
• feature/add-user-auth (from auth-related files)
• fix/login-validation (from validation changes)
• refactor/api-cleanup (from API refactoring)

Show the proposed branch name and ask for one-word confirmation (or type alternative).

3. Streamlined Branch & Commit

• If not on main/master: check if current branch matches proposed name
• If yes: stay on it
• If no: ask to switch or create new
• Create branch only after validating the branch name, then use git checkout -b "$branch_name"
• Stage explicit pathspecs only: git add -- path/to/file ...
• If file paths are generated, keep them NUL-delimited (git diff -z --name-only) and pass them as pathspec arguments.
• Never concatenate untrusted filenames into a shell command and never run the placeholder text literally.
• Auto-generate commit message from changes:
• First line: <type>: <short description> (max 72 chars)
• Body: grouped file changes with brief descriptions
• Commit with generated message, show preview first
• Ask for one-word confirmation to proceed

4. Push & Optional PR

• After commit, ask: "Push to remote? (yes/no/abort)"
• If yes: git push -u origin <branch-name>
• Then ask: "Create PR? (yes/no)"
• If yes:
• Check remote: git remote -v
• If fork: use fork's remote (e.g., mskadu/repo-name)
• Auto-generate PR description from commit messages
• Use gh pr create with:
• Title from branch name
• Body: summary of changes + file breakdown + follow-up notes

Key Rules

• Group related files automatically, but allow user to adjust
• Generate branch names from actual changes, don't ask user to name them
• Reduce confirmations: ask for one-word answers or single confirmation points
• Never commit secrets, credentials, or large binaries
• Check if GitHub repo exists before PR creation
• Skip PR step if user says "no" at any point
• If branch already exists with changes, offer to amend or add new commit

Limitations

• Do not bypass repository-specific maintainer rules, branch policies, or required review gates.
• Confirm destructive or publishing actions explicitly; this skill should streamline routine Git flow, not remove accountability.