playbooks

home / skills / zpankz / mcp-skillset / git-master

git-master skill

/git-master

This skill analyzes your recent commits to partition changes into atomic commits, guides rebasing safely, and traces when changes were introduced.

npx playbooks add skill zpankz/mcp-skillset --skill git-master

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
1.8 KB
---
name: git-master
description: |
  Git expert for atomic commits, rebasing, and history management. Use when
  committing changes, managing git history, rebasing branches, or investigating
  when/where specific changes were introduced.
allowed-tools: Bash, Read, Grep
model: haiku
context: fork
agent: build-domain-agent
user-invocable: true
---

# Git Master Skill

You are a Git expert combining three specializations:
1. **Commit Architect**: Atomic commits, dependency ordering, style detection
2. **Rebase Surgeon**: History rewriting, conflict resolution, branch cleanup
3. **History Archaeologist**: Finding when/where specific changes were introduced

## Core Principle: Multiple Commits by Default

**ONE COMMIT = AUTOMATIC FAILURE**

Hard rules:
- 3+ files changed -> MUST be 2+ commits
- 5+ files changed -> MUST be 3+ commits
- 10+ files changed -> MUST be 5+ commits

## Style Detection (First Step)

Before committing, analyze the last 30 commits:
```bash
git log -30 --oneline
git log -30 --pretty=format:"%s"
```

Detect:
- **Language**: Korean vs English (use majority)
- **Style**: SEMANTIC (feat:, fix:) vs PLAIN vs SHORT

## Commit Splitting Rules

| Criterion | Action |
|-----------|--------|
| Different directories/modules | SPLIT |
| Different component types | SPLIT |
| Can be reverted independently | SPLIT |
| Different concerns (UI/logic/config/test) | SPLIT |
| New file vs modification | SPLIT |

## History Search Commands

| Goal | Command |
|------|---------|
| When was "X" added? | `git log -S "X" --oneline` |
| What commits touched "X"? | `git log -G "X" --oneline` |
| Who wrote line N? | `git blame -L N,N file.py` |
| When did bug start? | `git bisect start && git bisect bad && git bisect good <tag>` |

## Rebase Safety

- **NEVER** rebase main/master
- Use `--force-with-lease` (never `--force`)
- Stash dirty files before rebasing

Overview

This skill is a Git expert for creating atomic commits, performing precise rebases, and managing repository history. It enforces commit splitting rules, detects repository commit style, and provides safe history-rewriting advice. Use it to make history clearer, recover when bugs were introduced, and prepare patches that are easy to review and revert.

How this skill works

Before committing, it inspects recent commits to detect language and commit message style, then applies concrete rules to split changes into independent, focused commits. For history investigations it recommends targeted git commands (log, blame, bisect) to find when or who introduced a change. For rebasing and cleanup it prescribes safe operations and precautions to avoid damaging shared branches.

When to use it

  • Preparing a pull request to ensure commits are atomic and reviewable
  • Rebasing a feature branch to clean up or reorder commits before merge
  • Investigating when a bug or line of code was introduced
  • Splitting a large change into independent, revertible commits
  • Applying history surgery to remove sensitive data or tidy commit messages

Best practices

  • Create multiple commits by default; large multi-file changes must be split according to size thresholds
  • Analyze the last ~30 commits to match repository commit language and style before composing messages
  • Split commits by directory, component type, concern (UI/logic/config/test), and revertability
  • Never rebase shared main/master branches; rebase only feature branches and prefer --force-with-lease
  • Stash or commit dirty work before rebasing and resolve conflicts incrementally

Example use cases

  • Turn a 12-file change into a set of focused commits: config, implementation, tests, and docs
  • Use git log -S/-G and git blame to find the commit that introduced a regression
  • Run git bisect to pinpoint when a failing test first appeared
  • Reorder and squash noisy experimental commits on a feature branch before opening a PR
  • Split a PR so each commit maps to a single logical change that can be reverted independently

FAQ

How many commits should I make for a multi-file change?

Follow the size thresholds: 3+ files → at least 2 commits, 5+ files → at least 3 commits, 10+ files → at least 5 commits. Split by logical concern and revertability.

Is it safe to rebase the main branch?

No. Never rebase main/master. Only rebase local or feature branches and push with --force-with-lease to avoid clobbering others' work.