Complete AI Training
Sign inBecome a member

Your job's AI kit

Get your AI kit

Tell us who you are and what you do. We show you your kit right away and email you the link: skills, prompts, AI agents, MCP servers and courses for your job.

500+ jobs ready, and we make a kit for any other job. No payment needed to look.

Share

Skill · Automation

Smart git automation

Smart change detection, auto branch naming, and streamlined commit/PR workflow

Agentic Awesome SkillsLicense: MITAdded Sep 5, 2026
Use it in my AI

How to use it

  1. Start your plan and connect your AI once
  2. Add the skill to your AI, one time only: press Copy skill and paste it into your AI's instructions: a project in ChatGPT, Claude or Grok, a Gem in Gemini, an agent in Microsoft 365 Copilot, or a rule in Cursor. It stays there for every new chat. In Kimi, paste it at the start of a new chat.
  3. Ask for the task in your own words, or say it directly:
Use the Smart git automation skill to help me with this.
SKILL.md2 files in this skill

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.

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.