70 lines
3.2 KiB
Markdown
70 lines
3.2 KiB
Markdown
---
|
|
description: Commit staged and unstaged changes following Conventional Commits, splitting big changes into smaller logical commits.
|
|
---
|
|
|
|
## User Input
|
|
|
|
```text
|
|
$ARGUMENTS
|
|
```
|
|
|
|
You **MUST** consider the user input before proceeding (if not empty).
|
|
|
|
## Outline
|
|
|
|
1. **Resolve remote URL**: Run `git remote get-url origin` to get the remote URL. All commit references produced by this skill MUST use the remote URL format (e.g., `<remote-url>/commit/<hash>`). Never output bare hashes without the full remote link.
|
|
2. Run `git status` to see all changed and untracked files.
|
|
3. Run `git diff` and `git diff --staged` to understand the changes.
|
|
4. Run `git log --oneline -5` to see recent commit style.
|
|
5. **Analyze and group changes into logical commits.** Review all changed files and determine if they can be separated into smaller, focused commits. Group by:
|
|
- **Purpose**: Bug fix vs feature vs docs vs config — never mix these in one commit.
|
|
- **Scope**: Changes to different modules (frontend, backend, specs, config) should be separate commits unless they are tightly coupled and meaningless without each other.
|
|
- **Independence**: If a subset of changes can stand on its own and still make sense, it should be its own commit.
|
|
- Present the proposed commit grouping to the user for approval before proceeding.
|
|
6. For each logical group, stage only the relevant files using `git add <file>` (never use `git add -A` or `git add .`) and commit them individually.
|
|
7. Write a commit message following the **Conventional Commits** specification.
|
|
8. After each successful commit, report the commit hash as a full remote link: `<remote-url>/commit/<hash>` (using the URL resolved in step 1).
|
|
|
|
### Commit Message Format
|
|
|
|
```
|
|
<type>(<scope>): <short summary>
|
|
|
|
<optional body>
|
|
|
|
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
|
```
|
|
|
|
### Types
|
|
|
|
- `feat`: A new feature
|
|
- `fix`: A bug fix
|
|
- `docs`: Documentation only changes
|
|
- `style`: Changes that do not affect the meaning of the code (white-space, formatting)
|
|
- `refactor`: A code change that neither fixes a bug nor adds a feature
|
|
- `perf`: A code change that improves performance
|
|
- `test`: Adding missing tests or correcting existing tests
|
|
- `build`: Changes that affect the build system or external dependencies
|
|
- `ci`: Changes to CI configuration files and scripts
|
|
- `chore`: Other changes that don't modify src or test files. Claude config files can be categorized here. Example `chore(claude)`
|
|
|
|
### Scope
|
|
|
|
Use the relevant module or area in parentheses:
|
|
- `frontend` — SvelteKit or other frontend changes
|
|
- `backend` — Spring Boot or other backend changes
|
|
- `monitoring` — Prometheus, or Grafana changes
|
|
- `server` — Docker, Docker Compose, Kubernetes changes
|
|
- Omit scope if the change spans multiple areas
|
|
- Append - with application name if available. Example `backend-auth`.
|
|
|
|
### Rules
|
|
|
|
- The summary must be lowercase, imperative mood, no period at the end
|
|
- Keep the summary under 70 characters
|
|
- Use the body for additional context when the summary alone is not sufficient
|
|
- Always end with the `Co-Authored-By` trailer
|
|
- Use a HEREDOC to pass the commit message to `git commit -m`
|
|
- NEVER use `--no-verify` or skip pre-commit hooks
|
|
- NEVER amend a previous commit unless explicitly asked
|