commit（提交）

Gather Context

If the current changes are already known from the conversation context (e.g., you just edited the files), skip these commands. Otherwise, run them to understand the current state:

1. git status — check current status and untracked files
2. git diff HEAD — review all changes

Flag Detection

Parse $ARGUMENTS for flags before proceeding. Natural language equivalents: "amend해줘", "직전 커밋에 합쳐줘", "마지막 커밋 수정" → --amend.

Amend (opt-in only)

Skip this section if any of the following is true: - --amend is NOT set - The last commit is a merge commit (git rev-parse --verify HEAD^2 2>/dev/null succeeds)

When --amend is set, amend the last commit with the current changes.

Step 1 — Check push status:

git log @{u}..HEAD --oneline 2>/dev/null
# - Command fails (no upstream): NOT pushed
# - Non-empty output: NOT pushed (unpushed commits exist)
# - Empty output: already pushed → force push required after amend

Step 2 — Execute amend:

• Stage the relevant files and run git commit --amend.

- Use --no-edit if the change is a minor fix within the same intent. - Update the commit message if the scope or meaning has changed.

• NOT pushed → amend directly and display:

⚡ Amend — --amend flag detected

• Already pushed → display a warning and ask for confirmation before proceeding:

⚠️ Amend + force push — the last commit has already been pushed. Proceed?

• If confirmed: amend and run git push --force-with-lease, then display:

⚡ Force pushed (--force-with-lease)

• If declined: fall through to Task (new commit).

After amend:

• If no unstaged or untracked changes remain → done. Do not proceed to Task.
• If any changes remain → proceed to Task for the remaining changes.

Commit Message Convention

Format: {type}: {description} or {type}({scope}): {description}

Type Prefixes (always lowercase)

Scope (optional)

Add scope in parentheses when the change targets a specific module or component:

• feat(source-map):...
• fix(full-text):...
• test(query-rewriting):...

Description Rules

• Write the description in the language configured in the project's CLAUDE.md. If no language is configured, follow the user's conversational language.
• Keep the subject line concise — aim for under 50 characters.
• Use natural, fluent phrasing. Do not force-translate well-known technical terms. For example, write source_map as-is rather than translating it.
• Focus on WHAT changed and WHY, not HOW.

Multi-line Body (for complex changes)

When the diff involves multiple files or logical units, add a body after a blank line to explain details:

{type}: {subject line}

- {detail 1}
- {detail 2}
- {detail 3}

When to use multi-line:

• 3+ files changed across different concerns
• Non-obvious reasoning behind the change
• Breaking changes or migration notes

When single-line is enough:

• Simple, self-explanatory changes (typo fix, single-file edit, etc.)

Examples

Single-line:

feat: 멀티턴 컨텍스트 유지 기능 추가
fix: 요청 DTO 모델 기본값을 settings 기반으로 통일
refactor: 미사용 openai_api_key/openai_base_url 프로퍼티 제거
style: black 포맷팅 적용
perf: Classification max_tokens 30 → 15로 조정
chore: 보안 취약점 패키지 업데이트 (urllib3, langchain-core)
docs: README 환경변수 가이드 업데이트
test: 멀티턴 컨텍스트 유지 기능 테스트 추가
feat(source-map): 검색하지 않은 턴에서도 source_map 지속 반환
fix(full-text): 전문 조회 실패 시 state 누출 방지
hotfix: uv lock synced

Multi-line:

refactor: Gather Context 불필요한 명령 및 중복 step 제거

- commit: git branch, git log 명령 삭제 (gitStatus/컨벤션 정의로 대체)
- pr: git remote show origin, gh pr list 네트워크 호출 제거
- review: Gather Context 섹션 삭제, 카테고리 불일치 수정

Task

If Amend already committed some or all files, only process the remaining uncommitted changes below. If nothing remains, skip this section.

1. Analyze the diff and identify commit units using the heuristics below. If there are multiple units, plan separate commits for each.

Commit Unit Heuristics

• Split work into commits that are independently revertable and cherry-pickable.
• A commit is too large if reverting it would also remove unrelated intent.
• A commit is too small if cherry-picking it would leave the codebase broken, incomplete, or missing required validation.
• Keep dependent changes in the same commit when splitting them would break a working intermediate state.

- Example: schema/model change + code that reads or writes the new field - Example: function signature change + all required call-site updates - Example: production code change + the tests required to validate that change

• Split changes into separate commits when they have different intent or can be rolled back independently.

- Example: refactor vs feature addition - Example: runtime/app behavior vs seed/tooling/docs updates - Example: mechanical rename/formatting vs behavioral changes

• Do not use layer boundaries alone as the rule.

- Backend and frontend may stay together when both are required for one valid end-to-end change. - Backend and frontend should be split when they can be verified, reverted, or cherry-picked independently.

• When uncertain, evaluate each candidate unit with these checks:

- If this unit alone is reverted, does it remove only one intended change? - If this unit alone is cherry-picked, does the result still build, run, and test coherently? - Are these changes driven by one reason, or are multiple motivations mixed together? - Would this unit make root-cause isolation easier if a regression appears later?

1. For each commit unit:

- Stage the relevant files individually. - Show the proposed commit message. - Use a multi-line body if the commit is intentionally broad but still one cohesive unit. - Create the commit. Follow the session's tool permission settings for approval.

1. Repeat step 2 until all commit units are committed. Do NOT stop after the first commit — handle all units within this single skill invocation.

Important:

• Do NOT use git add -A or git add. — stage specific files by name.
• Do NOT include files that may contain secrets (.env, credentials, tokens, etc.).