commit（提交）

Commit Automation with WBS & Review

Purpose

Automate git commit workflow with:

• WBS (Work Breakdown Structure) number tracking
• Automated code review based on diff
• Structured commit message generation
• Interactive commit execution

IMPORTANT: Always communicate with the user in Korean (한국어) throughout the entire workflow.

Trigger Conditions

When to activate this skill:

• 커밋해줘 / 커밋 쳐줘 / 커밋 올려줘
• 커밋 메시지 만들어줘 / 커밋메시지 / 커밋 메세지
• git commit / commit message / 커밋 메시지 추천
• "WBS 1234로 커밋" (WBS + commit mention)

When NOT to activate:

• Simple git concept questions (e.g., "커밋이 뭐야?")

Workflow

Performance Note: Cache git command results throughout the workflow. Do not re-run git status, git diff, or git log if already executed in previous steps.

Step 0: WBS Selection

If user provided WBS number in the request:

• Parse patterns:

- Single: "WBS 123", "WBS-123", "123으로 커밋", "커밋 123", "/commit 123" - Multiple: "13, 14로 커밋", "커밋 13 14", "/commit 13, 14"

• Extract number(s) from the request:

- Single number → format as WBS-<number> (e.g., 1234 → WBS-1234) - Multiple numbers → split by comma/space, format each, join with ", " (e.g., "13, 14" → WBS-13, WBS-14)

• IMPORTANT: Skip selection UI and proceed directly to Step 1 with the extracted WBS number(s)

If NO WBS number provided:

1. Run git log -1 --pretty=%B to get the most recent commit message

- This is more reliable than reading .git/COMMIT_EDITMSG (works correctly during amend/rebase) - If this fails, fallback to reading .git/COMMIT_EDITMSG

1. Parse "Context:" section to extract WBS number from the most recent commit
2. Extract the commit subject (first line) as the task description
3. If WBS found (not "N/A"), prepare it as the previous WBS option with format: "WBS-XX (commit subject)"
4. MUST use AskUserQuestion tool to present selection UI:

- header: "WBS 번호" - question: "WBS 작업 번호를 입력해주세요. - 단일: 1234 - 여러 개: 13, 14 또는 13 14 - 없음: '없음' 입력" - Options (in order): - If previous WBS found: label="WBS-<number>", description="<commit subject>" - Always: label="없음", description="WBS 없이 진행" - IMPORTANT: Label must include "WBS-" prefix (e.g., "WBS-9", not just "9") to prevent numeric key conflicts in terminal UI - The tool automatically adds "Other" at the bottom — this serves as the 직접입력 option

1. MANDATORY: Wait for user selection. Do NOT auto-select or assume any option.

Handle user selection:

• Previous WBS option: Use the previous WBS number extracted from git log
• "없음" option: Set WBS to "N/A" and proceed
• "Other" (free text input): Parse the user's typed input:

- If "없음" or empty → set WBS to "N/A" - Otherwise → parse input: - Split by comma or space (e.g., "13, 14" or "13 14") - Format each as WBS-<number> - Join with ", " → WBS-13, WBS-14

• User cancels (Esc): Exit workflow without proceeding

Important: Never invent or guess WBS numbers.

Step 1: Inspect Changes

1. MUST run git status -sb to get branch and file status
2. MUST run diff commands:

- First try: git diff --staged - If empty, try: git diff

1. Summarize changes in 3-5 lines (what files changed, what kind of changes)

Commit Split Detection: If changes span multiple unrelated domains, suggest splitting:

• Backend vs Frontend
• Feature vs Refactor
• Logic vs Formatting
• Dependencies vs Business code

If split is recommended:

1. Explain split criteria and reasoning
2. List files for each commit unit
3. Wait for user approval
4. On approval:

- Stage first unit → git add <files> - Continue with Step 2-6 for first unit - Repeat for remaining units

1. If user says "just do it all at once" → proceed as single commit

Step 2: Code Review

Diff Scope Rule (Mandatory):

• Review ONLY lines added/removed in the current diff
• Inspect minimal surrounding context
• Do NOT audit unrelated existing code
• Ignore legacy technical debt not introduced by this change
• Do NOT suggest architectural refactors unrelated to this diff

Review Checklist:

1. Potential bugs:

- Null/undefined handling - Edge cases - Error handling - Broken logic

1. Debug leftovers:

- console.log / print / System.out.println - TODO / FIXME comments

1. Security issues:

- Hard-coded secrets/tokens - Sensitive data in logs - SQL injection / XSS vulnerabilities

1. Code quality:

- Code duplication - Poor naming - Overly large functions/files

1. Unintended changes:

- Unrelated formatting changes - Stray files - Generated artifacts (build outputs, lock files if not intended)

Step 3: Review Output

Present review results in Korean using this format:

### 🔍 변경 요약

- [Brief summary of changes]

### ⚠️ 리스크 / 주의점

- [Identified risks or concerns, or "없음" if none]

### 🛠️ 개선 제안

- [Specific suggestions with file:line references, or "없음" if none]

### ✅ 결론

- [리뷰 통과 | 수정 필요 | 커밋 분리 권장]

Step 4: Review Decision Branch

If review result = "리뷰 통과":

• Proceed to Step 5

If review result = "수정 필요":

• Do NOT generate commit message
• Show review output and instruct: "위 이슈를 수정한 뒤 다시 커밋을 요청해주세요."
• If user explicitly says "ignore and commit anyway" → proceed to Step 5

If review result = "커밋 분리 권장":

• Follow Commit Split Guide from Step 1
• Process each unit through Steps 2-6 separately

Step 5: Generate Commit Message

PRE-CHECK: Ensure WBS number has been set in Step 0 (including "N/A" for no WBS). If not set at all, return to Step 0 for user selection.

1. MUST read templates/commit-msg-template.md from skill directory

- This file contains the commit message format, emoji mapping, and all template rules - No user notification, silent check - Follow the template structure and emoji mapping exactly as defined in the file

1. Generate exactly 1 commit message (best candidate only)
2. Do NOT run any git commands in this step

Step 6: Commit Execution

Present commit UI:

1. Display the generated commit message in a code block
2. MUST use AskUserQuestion tool to present selection:

- header: "커밋 실행" - question: "위 커밋 메시지로 진행할까요?" - Options: - label="커밋", description="제안된 메시지로 커밋 실행" - label="수정", description="메시지를 수정한 뒤 커밋" - label="취소", description="커밋하지 않고 종료" - "Other" is automatically added — user can type modified commit message or instructions directly

Handle user selection:

• "커밋" option:

- Check if files are staged: git diff --staged --name-only - IMPORTANT: Escape double quotes and special characters in commit message before executing git commit - If staged files exist → run git commit -m "..." - If nothing staged → list unstaged files, ask user which to add, then run git add <files> → git commit -m "..."

• "수정" option:

- Prompt: "수정할 내용을 입력해주세요 (전체 커밋 메시지 또는 수정 지시):" - Wait for user input - Apply modifications to commit message - Commit with modified message

• "Other" (free text input):

- Treat user input as modification instructions or replacement commit message - Apply modifications and commit

• "취소" option or Esc:

- Exit without committing

Refinement Notes

Why this design:

1. WBS tracking: Company workflow requires linking commits to WBS tasks
2. Automatic WBS suggestion: Reduces friction by suggesting recent WBS numbers
3. Mandatory review: Prevents shipping debug code, secrets, or bugs
4. Template flexibility: Projects can override with custom templates
5. Interactive selection: Gives user control at each decision point

Tool usage patterns:

• Silent execution for context gathering (git log)
• Explicit user prompts for decisions (WBS selection, commit execution)
• Structured output formats for consistency

Error handling:

• Never proceed if review fails (unless user overrides)
• Never invent WBS numbers
• Always confirm before staging/committing files