Skip to content

Commit 3e56d7f

Browse files
committed
chore: restore .claude configuration files
1 parent da3be2a commit 3e56d7f

File tree

2 files changed

+113
-0
lines changed

2 files changed

+113
-0
lines changed

.claude/commands/commit.md

Lines changed: 110 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,110 @@
1+
# Claude Command: Commit
2+
3+
This command helps you create well-formatted commits with conventional commit messages and emoji.
4+
5+
## Usage
6+
7+
To create a commit, just type:
8+
```
9+
/commit
10+
```
11+
12+
Or with options:
13+
```
14+
/commit --no-verify
15+
```
16+
17+
## What This Command Does
18+
19+
1. Unless specified with `--no-verify`, automatically runs pre-commit checks:
20+
- `mise run check`
21+
2. Checks which files are staged with `git status`
22+
3. If 0 files are staged, automatically adds all modified and new files with `git add`
23+
4. Performs a `git diff` to understand what changes are being committed
24+
5. Analyzes the diff to determine if multiple distinct logical changes are present
25+
6. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
26+
7. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format
27+
28+
## Best Practices for Commits
29+
30+
- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated
31+
- **Atomic commits**: Each commit should contain related changes that serve a single purpose
32+
- **Split large changes**: If changes touch multiple concerns, split them into separate commits
33+
- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
34+
- **Concise first line**: Keep the first line under 72 characters
35+
36+
The commit message should be structured as follows:
37+
38+
```
39+
<type>[optional scope]: <description>
40+
[optional body]
41+
```
42+
43+
Where `type` is one of:
44+
- `feat`: A new feature
45+
- `fix`: A bug fix
46+
- `docs`: Documentation changes
47+
- `deps`: Dependency changes (crate versions, etc)
48+
- `style`: Code style changes (formatting, etc)
49+
- `refactor`: Code changes that neither fix bugs nor add features
50+
- `perf`: Performance improvements
51+
- `test`: Adding or fixing tests
52+
- `chore`: Changes to the build process, tools, etc.
53+
54+
A `scope` MAY be provided after a type. A scope consist of a noun describing a section of the codebase surrounded by parenthesis `fix(parser)`.
55+
56+
57+
## Guidelines for Splitting Commits
58+
59+
When analyzing the diff, consider splitting commits based on these criteria:
60+
61+
1. **Different concerns**: Changes to unrelated parts of the codebase
62+
2. **Different types of changes**: Mixing features, fixes, refactoring, etc.
63+
3. **File patterns**: Changes to different types of files (e.g., source code vs documentation)
64+
4. **Logical grouping**: Changes that would be easier to understand or review separately
65+
5. **Size**: Very large changes that would be clearer if broken down
66+
67+
## Examples
68+
69+
Good commit messages:
70+
- feat: add user authentication system
71+
- fix: resolve memory leak in rendering process
72+
- docs: update API documentation with new endpoints
73+
- refactor: simplify error handling logic in parser
74+
- fix: resolve linter warnings in component files
75+
- chore: improve developer tooling setup process
76+
- feat: implement business logic for transaction validation
77+
- fix: address minor styling inconsistency in header
78+
- fix: patch critical security vulnerability in auth flow
79+
- style: reorganize component structure for better readability
80+
- fix: remove deprecated legacy code
81+
- feat: add input validation for user registration form
82+
- fix: resolve failing CI pipeline tests
83+
- feat: implement analytics tracking for user engagement
84+
- fix: strengthen authentication password requirements
85+
- feat: improve form accessibility for screen readers
86+
87+
Example of splitting commits:
88+
- First commit: feat: add new solc version type definitions
89+
- Second commit: docs: update documentation for new solc versions
90+
- Third commit: chore: update package.json dependencies
91+
- Fourth commit: feat: add type definitions for new API endpoints
92+
- Fifth commit: feat: improve concurrency handling in worker threads
93+
- Sixth commit: fix: resolve linting issues in new code
94+
- Seventh commit: test: add unit tests for new solc version features
95+
- Eighth commit: fix: update dependencies with security vulnerabilities
96+
97+
## Command Options
98+
99+
- `--no-verify`: Skip running the pre-commit checks
100+
101+
## Important Notes
102+
103+
- By default, pre-commit checks (`mise run check`) will run to ensure code quality
104+
- If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first
105+
- If specific files are already staged, the command will only commit those files
106+
- If no files are staged, it will automatically stage all modified and new files
107+
- The commit message will be constructed based on the changes detected
108+
- Before committing, the command will review the diff to identify if multiple commits would be more appropriate
109+
- If suggesting multiple commits, it will help you stage and commit the changes separately
110+
- Always reviews the commit diff to ensure the message matches the changes

.claude/settings.json

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
{
2+
"includeCoAuthoredBy": false
3+
}

0 commit comments

Comments
 (0)