docs: Added Conventional Commits specifications to the commit command.

- Introduced a type system based on the Conventional Commits v1.0.0 specification (feat/fix/docs/chore, etc.)
- Added guidance on when to use each type and SemVer impact.
- Clarified the criteria for distinguishing between fix and chore (user impact vs. developer impact).
- Added a method for handling breaking changes.
- Added Claude execution instructions and token optimization guide.

Author: KubrickCode

.claude/commands/commit.md

@@ -1,13 +1,13 @@
 ---
-allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git branch:*)
-description: Generate concise commit messages in both Korean and English - you choose one to use
+allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git branch:*), Write
+description: Generate Conventional Commits-compliant messages (feat/fix/docs/chore) in Korean and English
 ---
 
-# Smart Git Commit Message Generator
+# Conventional Commits Message Generator
 
-Generate commit messages in both Korean and English. **You will choose one version to use for your commit.**
+Generates commit messages following [Conventional Commits v1.0.0](https://www.conventionalcommits.org/) specification in both Korean and English. **Choose one version for your commit.**
 
-## Current Repository State
+## Repository State Analysis
 
 - Git status: !git status --porcelain
 - Current branch: !git branch --show-current
@@ -20,84 +20,119 @@ Generate commit messages in both Korean and English. **You will choose one versi
 1. Checks current branch name to detect issue number (e.g., develop/shlee/32 → #32)
 2. Checks which files are staged with git status
 3. Performs a git diff to understand what changes will be committed
-4. Generates concise commit messages in both Korean and English
+4. Generates commit messages in Conventional Commits format in both Korean and English
 5. Adds "fix #N" at the end if branch name ends with a number
 6. **Saves to commit_message.md file for easy copying**
 
-## Commit Message Format Guidelines
+## Conventional Commits Format (REQUIRED)
 
-**Core Principle: Focus on what problem was solved rather than what was done**
+```
+<type>[(optional scope)]: <description>
 
-**Title Writing Principle: Prioritize user-facing problems**
+[optional body]
 
-- ❌ "Fix empty login form submission error" (code perspective)
-- ✅ "Fix login button not responding to clicks" (user perspective)
-- ❌ "Handle null pointer exception" (technical perspective)
-- ✅ "Fix app crash when accessing profile page" (user perspective)
+[optional footer: fix #N]
+```
 
-Keep it simple and concise. Use appropriate format based on complexity:
+### Available Types
 
-### Very Simple Changes
+Analyze staged changes and suggest the most appropriate type:
+
+| Type | When to Use | SemVer Impact |
+|------|-------------|---------------|
+| **feat** | New feature or capability added | MINOR (0.x.0) |
+| **fix** | Bug fix or problem resolution | PATCH (0.0.x) |
+| **docs** | Documentation only changes (README, comments, etc.) | None |
+| **style** | Code formatting, missing semicolons (no logic change) | None |
+| **refactor** | Code restructuring without changing behavior | None |
+| **perf** | Performance improvements | PATCH |
+| **test** | Adding or fixing tests | None |
+| **chore** | Build config, dependencies, tooling updates | None |
+| **ci** | CI/CD configuration changes | None |
 
+**BREAKING CHANGE**: MUST use both type! format (exclamation mark after type) AND BREAKING CHANGE: footer with migration guide for major version bump.
+
+Example:
 ```
-[Problem description] Title
+feat!: change API response format from JSON to MessagePack
+
+Migrated response format to MessagePack binary for 40% packet size reduction.
+
+BREAKING CHANGE: Client code update required
+- Install MessagePack library: npm install msgpack5
+- Update response parsing: response.json() → msgpack.decode(response.body)
+- Update type definitions: API_RESPONSE_FORMAT constant changed
 ```
 
-### Simple Changes
+### Type Selection Decision Tree
+
+Analyze git diff output and suggest type based on file patterns:
 
 ```
-[Problem description] Title
+Changed Files → Suggested Type
 
-What problem occurred and how it was resolved in one or two lines
+src/**/*.{ts,js,tsx,jsx} + new functions/classes → feat
+src/**/*.{ts,js,tsx,jsx} + bug fix → fix
+README.md, docs/**, *.md → docs
+package.json, pnpm-lock.yaml, .github/** → chore
+**/*.test.{ts,js}, **/*.spec.{ts,js} → test
+.github/workflows/** → ci
 ```
 
-### Standard Changes
+If multiple types apply, prioritize: `feat` > `fix` > other types.
 
-```
-[Problem description] Title
+### Confusing Cases: fix vs chore
 
-Description of the problem that occurred
-(Brief reproduction steps if applicable)
+**Key distinction**: Does it affect **users** or only **developers**?
 
-How it was solved and the reasoning behind the solution
-```
+| Scenario | Type | Reason |
+|----------|------|--------|
+| Backend GitHub Actions test workflow not running | `chore` | Only affects CI/CD, users don't experience this |
+| API returns 500 error for valid requests | `fix` | Users experience error responses |
+| Page loading speed improved from 3s to 0.8s | `perf` | Users directly feel the improvement |
+| Internal database query optimization (no user impact) | `refactor` | Code improvement, no measurable user benefit |
+| Dependency security patch (CVE fix) | `chore` | Build/tooling update |
+| App crashes when accessing profile page | `fix` | Users experience crash |
 
-### Complex Changes (rarely needed)
+**User perspective priority:**
+- ✅ "fix: app crashes when deleting items" (user problem)
+- ❌ "fix: null pointer exception in ItemService" (code problem)
 
-```
-[Problem description] Title
+## Commit Message Format Guidelines
 
-Problem:
-- Specific problem description
-- Reproduction steps (brief if available)
+**Core Principle: Focus on what problem was solved rather than what was done**
 
-Solution:
-- Approach taken and why that method was chosen
-- Additional solutions applied and their rationale
-```
+**Title Writing Principle: Prioritize user-facing problems**
 
-**Important formatting rules:**
+- ❌ "Fix empty login form submission error" (code perspective)
+- ✅ "Fix login button not responding to clicks" (user perspective)
+- ❌ "Handle null pointer exception" (technical perspective)
+- ✅ "Fix app crash when accessing profile page" (user perspective)
 
-- First line (title): Clearly express the user-facing problem
-- Prefer user perspective > code/technical perspective when possible
-- Except for very simple cases, don't just list changes - explain with sentences
-- Include reasoning and justification when explaining solutions
-- Keep descriptions concise - avoid verbose explanations
-- If branch name ends with number (e.g., develop/32, develop/shlee/32), add "fix #N" at the end
-- **When multiple changes/reasons exist, use bullet points (-) for better readability**
+Keep it simple and concise. Use appropriate format based on complexity:
 
-## Examples
+### Very Simple Changes
 
-### Very Simple
+```
+type: brief description
+```
 
+**Example:**
 ```
-Fix typo in README
+docs: fix typo in README
 ```
 
-### Simple
+### Simple Changes
+
+```
+type: problem description
+
+What problem occurred and how it was resolved in one or two lines
+```
 
+**Example:**
 ```
-Fix login button not responding with empty fields
+fix: login button not responding with empty fields
 
 Login attempts with empty input fields showed no response
 Added client-side validation and error message display
@@ -106,16 +141,28 @@ Added client-side validation and error message display
 **For multiple changes/reasons, use list format:**
 
 ```
-Backend architect agent role redefinition
+refactor: backend architect agent role redefinition
 
 - Changed focus from API design to system structure design
 - Modified to concentrate on domain modeling, layered architecture, and modularization strategy
 ```
 
-### Standard
+### Standard Changes
+
+```
+type: problem description
+
+Description of the problem that occurred
+(Brief reproduction steps if applicable)
+
+How it was solved and the reasoning behind the solution
+
+fix #N
+```
 
+**Example:**
 ```
-Fix user list page failing to load
+fix: user list page failing to load
 
 User list page showed continuous loading spinner with 1000+ users
 (Reproduction: User List > View All click)
@@ -126,10 +173,25 @@ response time from 30+ seconds to under 2 seconds
 fix #32
 ```
 
-### Complex (rare)
+### Complex Changes (rarely needed)
+
+```
+type: problem description
+
+Problem:
+- Specific problem description
+- Reproduction steps (brief if available)
+
+Solution:
+- Approach taken and why that method was chosen
+- Additional solutions applied and their rationale
 
+fix #N
 ```
-Fix users being logged out after service updates
+
+**Example:**
+```
+fix: users being logged out after service updates
 
 Problem:
 - All users forced to log out with each new deployment
@@ -140,6 +202,17 @@ Solution:
 - Implemented JWT refresh tokens for automatic re-authentication to provide seamless service
 ```
 
+**Important formatting rules:**
+
+- First line (title): `type: clearly express the user-facing problem`
+- description must start with lowercase, no period at end, use imperative mood
+- Prefer user perspective > code/technical perspective when possible
+- Except for very simple cases, don't just list changes - explain with sentences
+- Include reasoning and justification when explaining solutions
+- Keep descriptions concise - avoid verbose explanations
+- If branch name ends with number (e.g., develop/32, develop/shlee/32), add "fix #N" at the end
+- **When multiple changes/reasons exist, use bullet points (-) for better readability**
+
 ## Output Format
 
 The command will provide:
@@ -157,3 +230,25 @@ The command will provide:
 - Keep messages concise - don't over-explain what's obvious from the code
 - Branch issue numbers (e.g., develop/32) will automatically append "fix #N"
 - Copy message from generated file and manually execute `git commit`
+- **Spec compliance**: All messages MUST follow Conventional Commits format
+- **Type is mandatory**: No type = invalid commit for semantic-release
+- **Case sensitivity**: Types must be lowercase (except `BREAKING CHANGE`)
+
+## Execution Instructions for Claude
+
+1. Run git commands to understand changes (staged or all if none staged)
+2. Analyze file patterns and suggest appropriate commit type
+3. Determine if scope is needed (e.g., `fix(api):`, `feat(ui):`)
+4. Draft commit message following format:
+   - Title: `<type>[(scope)]: <user-facing description>`
+   - Body: Choose appropriate format based on complexity (very simple/simple/standard/complex)
+   - Footer: Auto-add `fix #N` if branch name ends with number
+5. Generate both Korean and English versions
+6. Write to `/workspaces/ai-config-toolkit/commit_message.md`
+7. Present suggested type with reasoning
+
+**Token optimization**: Focus git diff analysis on:
+- New/deleted files → likely `feat` or `refactor`
+- Modified files in src/ → check if bug fix or feature
+- Modified docs/README → `docs`
+- Modified package.json → `chore`