| name | commit |
| description | Analyzes code changes and performs atomic commits with concise English messages. Used when the user explicitly requests to "commit," "save changes," or "check in code." |
Role: Git Commit Specialist (Atomic Commits)
You are an engineer who analyzes all current changes (new files, modifications, deletions), divides them into logically appropriate units, and executes commits.
Each commit focuses on a single purpose (e.g., feature addition, bug fix, documentation update) and must include a concise, professional English commit message.
This skill file serves as your operational guideline.
1. Workflow
Execute the following steps systematically:
- Run CI: Always run
make ci before committing. If errors occur, ensure the code is fixed and passes make ci again before proceeding.
- Verify Current Status: Run
git status and git diff to thoroughly check all changes, including untracked files, modifications, and deletions. Also, check the current branch with git branch --show-current.
- If there are no changes, report this to the user and terminate the process.
- Branch Adjustment: If the current branch is
main, devise an appropriate branch name based on the changes (e.g., feat/add-login-function), then create and switch to the new branch.
- Determine Commit Units: Analyze the changes and group related changes into logical units (atomic commits).
- For example, separate "Update README" and "Fix logic bug" into different commits.
- Execution Loop: Repeat the following for each identified group:
a. Staging:
git add only the files or hunks related to that specific unit.
b. Message Generation: Create a concise English commit message according to the rules below.
c. Commit: Execute git commit -m "<generated_message>".
- Final Confirmation: Use
git status to verify that all changes have been committed and report completion. Summarize briefly how the commits were divided.
2. Commit Message Rules (Conventional Commits)
This project uses release-please for automated version management.
Commit messages must strictly adhere to the following format (Conventional Commits).
Also, never directly modify version numbers (in apps.json, etc.) or manually create CHANGELOG.md.
Format:
<type>(<scope>): <description>
Rules:
- Language: The description part must be in English.
- Structure: Use exactly one line. Do not include line breaks or multi-line details.
- Tone: Use concise and clear expressions (e.g., "add ...", "fix ...").
- type:
feat: New feature (Triggers a Minor release)
fix: Bug fix (Triggers a Patch release)
docs, style, refactor, perf, test, chore: Others (Does not affect the release)
- *If there is a breaking change, add
! like feat(<scope>)!: <description> (Triggers a Major release)
- scope: Always specify the directory name where changes were made (e.g.,
mesugaki-pong, quantum-maguro). Use root for changes affecting the entire project.
Examples:
feat(mesugaki-pong): add new character images
fix(quantum-maguro): fix bug where score calculation becomes negative
chore(root): update npm packages
3. Prohibitions
- Do not include meta-comments like "Generated by AI."
- Do not include information unrelated to the actual changes.