Execute git commit operations when user requests to commit or push code changes. Use this skill to generate recommended commit messages, perform local commits, or push to remote repositories...
Generate high-quality Gitmoji-based Korean commit messages and safe Git workflow commands by analyzing the user's current repository state. This skill supports commit, push, repository initialization, and branch creation.
Auto-activate when users request Git write actions:
Korean triggers:
English triggers:
Do NOT activate for:
Use this analysis for commit messages, initial commit messages, and branch names.
Repository state commands:
git rev-parse --is-inside-work-tree 2>/dev/null
git status --porcelain=v1
git diff --cached --stat
git diff --cached
git diff --stat
git diff
If the repository is not initialized yet, inspect files without staging ignored content:
git status --porcelain=v1 2>/dev/null || true
rg --files -g '!.git' -g '!node_modules' -g '!dist' -g '!build' -g '!coverage'
# If rg is unavailable before repository initialization:
find . -type f \
-not -path './.git/*' \
-not -path './node_modules/*' \
-not -path './dist/*' \
-not -path './build/*' \
-not -path './coverage/*'
Semantic classification:
feat - new user-facing capability, new workflow, new integration, or meaningful new behaviorfix - bug correction, broken behavior recovery, validation correction, or error handling correctionrefactor - structure improvement without behavior changeperf - measurable performance improvementtest - test-only changedocs - documentation-only changechore - tooling, dependency, formatting, or maintenance changeinit - first repository commit onlyPriority when multiple types apply:
feat > fix > refactor > perf > test > docs > chore
Use init only for the first commit created by the initialization workflow.
Naming language rules:
create-items, modify-member-business, resolve-login-error.Never run force-style Git operations unless the user explicitly requests the exact force action.
Forbidden unless explicitly requested:
git add -fgit add --forcegit push --forcegit push --force-with-leasegit commit --no-verifyIf a normal Git operation fails because a force action might be needed, stop and explain the cause. Ask the user for explicit approval before running any force command.
Command blocks are intended for Codex agents running a Bash-compatible shell.
On Windows, prefer Git Bash or WSL. PowerShell and CMD require adaptation for shell-specific syntax such as 2>/dev/null, || true, pipes, line continuations, and heredocs; the examples are not native PowerShell/CMD support promises.
For file listing, prefer rg --files when ripgrep is installed. If rg is unavailable, choose the fallback based on repository state.
Inside an initialized Git repository, use Git's ignore-aware listing:
git ls-files --cached --others --exclude-standard
Before repository initialization, use a Bash-compatible find fallback that excludes common generated or dependency directories:
find . -type f \
-not -path './.git/*' \
-not -path './node_modules/*' \
-not -path './dist/*' \
-not -path './build/*' \
-not -path './coverage/*'
Follow these steps sequentially for every commit or push request. For repository initialization, use Repository Initialization Workflow. For branch creation, use Branch Creation Workflow.
Use Bash tool to analyze git repository and detect violations.
1.1 Check if git repository:
git rev-parse --git-dir 2>/dev/null
If fails → "현재 디렉토리가 Git 저장소가 아닙니다."
1.2 Check changes:
git status --porcelain
If empty → "변경사항이 없습니다."
1.3 Get detailed diff:
# Staged changes
git diff --cached
# Unstaged changes (if needed)
git diff
# Statistics
git diff --cached --stat
1.4 Check AI-related files:
Principle: Respect user's .gitignore configuration. Files that passed .gitignore are trusted. Only verify AI-related files require user confirmation.
git diff --cached --name-only
AI-related file patterns (⚠️ User confirmation required):
claudedocs/ - Claude Code analysis/reports.claude/ - Claude Code configuration*.ai.md, *.claude.md - AI-authored markdown.cursor/ - Cursor IDE configuration*.copilot.md - GitHub Copilot files.aider*, aider.*.md - Aider AI files*.gpt.md - ChatGPT related filesIf AI files detected: Present options and handle user choice.
Options:
Handle user choice:
git restore --staged <files>)Important: Do NOT block or warn about other file types (.env, node_modules, etc.). User manages these via .gitignore/.gitignore_global.
Activation trigger: Large changeset (10+ files) OR user explicitly requests commit splitting.
1.5.1 Analyze for grouping potential:
# Count changed files
git diff --cached --name-only | wc -l
If ≥10 files, analyze for logical grouping.
1.5.2 Grouping analysis criteria:
Analyze file relationships using:
src/user/, src/product/ → module-based groupsUser*.kt, Product*.kt, *Test.kt → domain-based groups*.kt, *.py, *.ts, *.java*Test.kt, *_test.py, *.test.ts, *.spec.jsREADME.md, *.md in docs/package.json, build.gradle, *.toml, *.ymlDetailed grouping strategies: references/grouping_strategies.md
1.5.3 Present grouping to user:
Present suggested grouping with file counts and domain names.
Options:
1.5.4 Handle user choice and execute grouped commits:
For each group, execute Step 2 → Step 3 → Step 4 sequentially.
Edge cases:
Use Claude's natural language processing to generate message from diff analysis.
2.1 Analyze diff semantically:
Read the actual code changes from git diff --cached output:
2.2 Select Gitmoji:
Based on change type, refer to references/gitmoji_rules.md for complete guidelines.
Quick Reference: ✨ feat | 🐛 fix | ♻️ refactor | ⚡ perf | ✅ test | 📝 docs | 🔧 chore
Priority when multiple types:
Complete Gitmoji mapping: references/gitmoji_rules.md
2.3 Generate Korean summary:
Format:
<gitmoji> <type>: 한글 핵심 요약 (max 50 chars)
- 핵심 변경사항 1 (1줄, 간결)
- 핵심 변경사항 2 (1줄, 간결)
- 핵심 변경사항 3 (1줄, 간결)
2.4 Quality rules:
✅ MUST follow:
❌ MUST NOT include:
UserService, VectorEntityTypeextractVectorFields(), getUserById()userId, searchQueryUserService.kt, auth.controller.jsPhase 4, T032-1, SC-003)TASK-123, JIRA-456, #789)SC-003, SCENARIO-45)34개 통과, 2개 실패, 커버리지 85%).gitignore, package.json)Complete examples with transformations: references/commit_examples.md
⚠️ CRITICAL RULE - NEVER SKIP THIS STEP
This step is mandatory and must never be skipped under any circumstances. Always show the generated commit message to the user and wait for explicit approval before proceeding to commit execution.
3.1 Display the generated message:
MUST use AskUserQuestion tool to present the commit message to the user. Do not proceed to Step 4 without completing this interaction.
Message format:
📋 Generated commit message:
<full message>
Choose an action:
3.2 Provide exactly 4 options:
3.3 Handle user choice:
Wait for user selection. Do not assume or skip this step.
do_push=falsedo_push=true⚠️ Enforcement: If you proceed to Step 4 without completing Step 3, you are violating the core workflow. The user must see the message and make an explicit choice.
Use Bash tool to execute git operations.
4.1 Stage files:
# Stage all changes
git add .
# Or stage specific files (if user specified)
git add "file1.kt" "file2.py"
4.2 Commit with heredoc:
Use heredoc to safely handle special characters:
git commit -m "$(cat <<'EOF'
✨ feat: 사용자 인증 API 구현
- JWT 토큰 기반 인증
- 리프레시 토큰 자동 갱신
- 로그인/로그아웃 엔드포인트
EOF
)"
4.3 Push (optional):
If user chose "Commit + Push":
git push origin HEAD
4.4 Report results:
Success:
✅ Commit completed: <commit hash>
🚀 Pushed to: origin/<branch>
Failure:
❌ Commit failed: <error message>
Possible causes:
- Pre-commit hooks blocked
- Merge conflict detected
- No changes staged
Push failure (after successful commit):
✅ Commit completed: <commit hash>
⚠️ Push failed: <error message>
Your changes are committed locally.
Try: git push origin HEAD
Use this workflow when the user asks to initialize Git, create an initial commit, or prepare the current directory as a repository.
Check whether the current directory is already a Git repository:
git rev-parse --is-inside-work-tree 2>/dev/null
git rev-parse --verify HEAD 2>/dev/null
If git rev-parse --is-inside-work-tree succeeds, do not run git init again.
git rev-parse --verify HEAD succeeds, continue with the normal commit workflow and use the current diff to generate the message.git rev-parse --verify HEAD fails, the repository is initialized but has no commits. Continue this initialization/initial-commit workflow without running git init again, and use the 🎉 init message path.If it fails, inspect candidate files:
pwd
rg --files -g '!.git' -g '!node_modules' -g '!dist' -g '!build' -g '!coverage'
# If rg is unavailable before repository initialization:
find . -type f \
-not -path './.git/*' \
-not -path './node_modules/*' \
-not -path './dist/*' \
-not -path './build/*' \
-not -path './coverage/*'
If no files are found, ask the user whether to create an empty repository. Do not create an empty commit unless the user explicitly asks.
Run git init only when git rev-parse --is-inside-work-tree failed in Init Step 1:
git init
git status --porcelain=v1
If already inside a repository but git rev-parse --verify HEAD failed, skip git init and continue to staging and initial commit message generation.
Stage files using the user's ignore rules:
git add .
git status --porcelain=v1
git diff --cached --stat
Never use git add -f or git add --force unless the user explicitly requested the exact git add -f or git add --force action.
Reuse the same semantic message-generation rules from Step 2: Generate Commit Message, with this required title format:
🎉 init: 프로젝트 초기 설정
- 기본 작업 구조 구성
- 핵심 설정 파일 추가
- 초기 문서와 실행 기반 정리
Adjust the bullets to match the staged content. Keep the message Korean-first, imperative, under 300 characters, and free of AI signatures.
Show the generated initial commit message and provide exactly 3 options:
git init already ranDo not create the initial commit without explicit user approval.
If the user cancels after staging files, explain that the index may contain staged files. Offer to clean up the index with git restore --staged ., but run it only after explicit user approval.
After approval, run:
git commit -m "$(cat <<'EOF'
🎉 init: 프로젝트 초기 설정
- 기본 작업 구조 구성
- 핵심 설정 파일 추가
- 초기 문서와 실행 기반 정리
EOF
)"
git rev-parse --short HEAD
Report the commit hash and current branch:
git branch --show-current
Use this workflow when the user asks to create a new branch for the current work.
Run:
git rev-parse --is-inside-work-tree 2>/dev/null
git status --porcelain=v1
git branch --show-current
If the directory is not a Git repository, offer to run Repository Initialization Workflow first.
If the worktree has uncommitted changes, do not block branch creation. Use those changes as the primary context for naming unless the user provided a clearer branch purpose.
Use the shared semantic analysis. Prefer user-provided intent over diff inference.
If the user only says something like "브랜치 생성해줘" or "create a branch" without a branch name or topic:
Examples:
feat/create-itemsrefactor/modify-member-businessfix/resolve-login-errordocs/update-guidetest/add-coveragechore/update-toolingUse this format:
<type>/<slug>
Allowed prefixes:
feat/ for new behaviorfix/ for bug fixesrefactor/ for behavior-preserving structure changesperf/ for performance worktest/ for test-only workdocs/ for documentation-only workchore/ for tooling or maintenanceSlug rules:
a-z, 0-9, and -.Before creating the branch, run:
git show-ref --verify --quiet refs/heads/<candidate-branch>
git remote get-url origin
git ls-remote --heads origin <candidate-branch> 2>/dev/null
If git remote get-url origin fails, the repository has no origin remote. Do not offer or run upstream push. Explain that only local branch creation is available unless the user configures a remote.
If the local or remote branch already exists, append a short semantic suffix instead of a number when possible:
feat/create-items → feat/create-items-uifix/resolve-login-error → fix/resolve-login-error-validation-2.Show the generated branch name. If origin exists, provide exactly 4 options:
git switch -c <branch>git switch -c <branch> and git push -u origin <branch>If origin does not exist, provide exactly 3 options:
git switch -c <branch>Do not create or push the branch without explicit user approval.
For local branch creation:
git switch -c <branch>
git branch --show-current
For branch creation with upstream push:
git switch -c <branch>
git push -u origin <branch>
git branch --show-current
If git switch -c fails because the branch exists, do not overwrite it. Ask whether to switch to the existing branch or choose a new name.
Common edge cases and how to handle them. For complete details, see references/edge_cases.md.
Quick Reference:
--no-verify only after the user explicitly requests that exact bypass actiongit push -u origin <branch>Full edge case handling: references/edge_cases.md
Before each commit or push workflow:
Before repository initialization:
🎉 initBefore branch creation:
origin remote verified before offering upstream pushDetailed reference materials:
references/gitmoji_rules.md - Complete Gitmoji mapping (20+ entries) and selection guidelinesreferences/commit_examples.md - Extensive good/bad examples with code reference transformationsreferences/edge_cases.md - Detailed edge case scenarios and solutionsreferences/grouping_strategies.md - Advanced grouping algorithms and project-specific patternsThis skill implements MY_RULES.md Git workflow rules:
✅ Enforced:
✅ Triggers:
✅ Quality:
