Skip to main content

commit

Create git commits following Conventional Commits specification with project-specific branch naming rules

소스 정보

저장소
first-fluke/cratos
최근 소스 활동
2026년 2월 19일 09:21
감지된 SKILL.md 언어
영어
스타
4
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
3 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
commit
description
Create git commits following Conventional Commits specification with project-specific branch naming rules
# Commit Skill - Conventional Commits ## When to use - When user requests "commit this", "commit", "save changes" - When `/commit` command is invoked ## Configuration Project-specific settings: `.cratos/skills/commit/config/commit-config.yaml` ## Commit Types | Type | Description | Branch Prefix | |------|-------------|---------------| | feat | New feature | feature/ | | fix | Bug fix | fix/ | | refactor | Code improvement | refactor/ | | docs | Documentation changes | docs/ | | test | Test additions/modifications | test/ | | chore | Build, configuration, etc. | chore/ | | style | Code style changes | style/ | | perf | Performance improvements | perf/ | ## Commit Format ``` <type>(<scope>): <description> [optional body] Co-Authored-By: First Fluke <our.first.fluke@gmail.com> ``` ## Workflow ### Step 1: Analyze Changes ```bash git status git diff --staged git log --oneline -5 ``` ### Step 1.5: Split by Feature (if needed) If changed files span multiple features/domains, **split commits by feature**. **Split criteria:** - Different scopes (e.g., workflows vs skills vs docs) - Different types (e.g., feat vs fix vs docs) - Logically independent changes **Example:** ``` # Changed files: .agent/workflows/*.md (7 files) → fix(workflows): ... .cratos/skills/**/*.md (4 files) → fix(skills): ... USAGE.md, USAGE-ko.md → docs: ... # Split into 3 commits ``` **Do NOT split when:** - All changes belong to a single feature - Few files changed (5 or fewer) - User requested a single commit ### Step 2: Determine Commit Type Analyze changes → Select appropriate type: - New files added → `feat` - Bug fixed → `fix` - Refactoring → `refactor` - Documentation only → `docs` - Tests added → `test` - Build/config changes → `chore` ### Step 3: Determine Scope Use changed module/component as scope: - `feat(auth)`: Authentication related - `fix(api)`: API related - `refactor(ui)`: UI related - No scope is also valid: `chore: update dependencies` ### Step 4: Write Description - Under 72 characters - Use imperative mood (add, fix, update, remove...) - Lowercase first letter - No trailing period ### Step 5: Confirm with User ``` 📝 Commit message preview: feat(orchestrator): add multi-CLI agent mapping support - Add user-preferences.yaml for CLI configuration - Update spawn-agent.sh to read agent-CLI mapping - Update memory schema with CLI field Co-Authored-By: First Fluke <our.first.fluke@gmail.com> Proceed with this commit? (Y/N/Edit) ``` ### Step 6: Execute Commit After user confirmation: ```bash git add <specific-files> git commit -m "<message>" ``` ## References - Configuration: `config/commit-config.yaml` - Guide: `resources/conventional-commits.md` ## Important Notes - **NEVER** commit without user confirmation - **NEVER** use `git add -A` or `git add .` without explicit permission - **NEVER** commit files that may contain secrets (.env, credentials, etc.) - **ALWAYS** use specific file names when staging - **ALWAYS** use HEREDOC for multi-line commit messages
GitHub에서 보기