smart git automation

---
name: smart-git-automation
version: 1.0.0
description: "Smart change detection, auto branch naming, and streamlined commit/PR workflow"
risk: critical
source: community
source_type: community
source_repo: mskadu/opencode-agent-skills
license: MIT
license_source: "https://github.com/mskadu/opencode-agent-skills/blob/main/LICENSE"
date_added: "2026-06-05"
---

## 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.