commit

Name: commit
Author: aviflombaum

38stars2forks

How to install commit?

aviflombaum/claude-code-in-avinyc/commit

$npx -y skills add aviflombaum/claude-code-in-avinyc --skill commit

Installs into the current project.

Summary

This skill should be used when the user asks to "commit", "make a commit", "commit my changes", "create commits", "git commit", or wants to commit staged/unstaged changes with logical grouping and conventional commit format.

Files · 1

View on GitHub

SKILL.md

1	# Git Commit Assistant
2
3	Analyze git changes and create logical, well-structured commits using conventional commit format.
4
5	## When to Use
6
7	- User asks to commit changes
8	- Multiple unrelated changes need separate commits
9	- Changes need conventional commit formatting
10
11	## Workflow
12
13	### Step 1: Review Current State
14
15	Run git status to see all changes:
16
17	```bash
18	git status
19	```
20
21	Review both staged and unstaged changes. Identify modified, added, and deleted files.
22
23	### Step 2: Analyze and Plan Commits
24
25	Group changes into logical commits based on:
26
27	- Feature boundaries: Files that implement the same feature together
28	- Type of change: Separate fixes from features from refactors
29	- Scope: Group by component, module, or area of the codebase
30
31	Present the commit plan to the user before proceeding:
32
33	```
34	I see the following logical commits:
35	1. feat(auth): Add password reset - auth/reset.rb, auth/mailer.rb
36	2. fix(api): Handle null responses - api/client.rb
37	3. docs: Update README - README.md
38	```
39
40	### Step 3: Execute Commits One by One
41
42	For each planned commit:
43
44	Stage specific files only:
45	```bash
46	git add <file1> <file2>
47	```
48
49	Verify staging:
50	```bash
51	git status
52	```
53
54	Create commit with conventional format:
55	```bash
56	git commit -m "<type>[scope]: <description>" -m "<body>"
57	```
58
59	Verify commit succeeded:
60	```bash
61	git status
62	```
63
64	Only proceed to the next commit after verifying the current one completed.
65
66	## Conventional Commit Types
67
68	\| Type \| Description \|
69	\|------\|-------------\|
70	\| feat \| New feature \|
71	\| fix \| Bug fix \|
72	\| docs \| Documentation only \|
73	\| style \| Formatting, no code change \|
74	\| refactor \| Code change, no new feature or fix \|
75	\| perf \| Performance improvement \|
76	\| test \| Adding or fixing tests \|
77	\| chore \| Build process, auxiliary tools \|
78
79	## Commit Message Format
80
81	```
82	<type>[optional scope]: <description>
83
84	[optional body]
85
86	[optional footer]
87	```
88
89	- Description: Imperative mood, lowercase, no period ("add feature" not "Added feature.")
90	- Body: Explain what and why, not how
91	- Scope: Component or area affected (auth, api, db, ui)
92
93	## Rules
94
95	1. Never mix unrelated changes in a single commit
96	2. Always verify staging before committing
97	3. Always verify success after committing
98	4. Explain the plan before executing
99	5. Never use `git add .` or `git add -A` without explicit approval
100	6. Never include "Generated with Claude Code" or Co-Authored-By footers
101
102	## Example Session
103
104	```
105	$ git status
106	# Modified: auth/login.rb, auth/signup.rb, README.md, api/client.rb
107
108	Plan:
109	1. feat(auth): Improve login validation - auth/login.rb, auth/signup.rb
110	2. fix(api): Handle timeout errors - api/client.rb
111	3. docs: Add authentication guide - README.md
112
113	Executing commit 1...
114	$ git add auth/login.rb auth/signup.rb
115	$ git status # verify only auth files staged
116	$ git commit -m "feat(auth): improve login validation" -m "Add email format check and rate limiting"
117	$ git status # verify commit succeeded
118
119	Executing commit 2...
120	[continues...]
121	```

People who liked this also viewed

6 picks

Type

commit

38stars2forks

View on GitHub

How to install commit?

aviflombaum/claude-code-in-avinyc/commit

$npx -y skills add aviflombaum/claude-code-in-avinyc --skill commit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Git Commit Assistant
2
3	Analyze git changes and create logical, well-structured commits using conventional commit format.
4
5	## When to Use
6
7	- User asks to commit changes
8	- Multiple unrelated changes need separate commits
9	- Changes need conventional commit formatting
10
11	## Workflow
12
13	### Step 1: Review Current State
14
15	Run git status to see all changes:
16
17	```bash
18	git status
19	```
20
21	Review both staged and unstaged changes. Identify modified, added, and deleted files.
22
23	### Step 2: Analyze and Plan Commits
24
25	Group changes into logical commits based on:
26
27	- Feature boundaries: Files that implement the same feature together
28	- Type of change: Separate fixes from features from refactors
29	- Scope: Group by component, module, or area of the codebase
30
31	Present the commit plan to the user before proceeding:
32
33	```
34	I see the following logical commits:
35	1. feat(auth): Add password reset - auth/reset.rb, auth/mailer.rb
36	2. fix(api): Handle null responses - api/client.rb
37	3. docs: Update README - README.md
38	```
39
40	### Step 3: Execute Commits One by One
41
42	For each planned commit:
43
44	Stage specific files only:
45	```bash
46	git add <file1> <file2>
47	```
48
49	Verify staging:
50	```bash
51	git status
52	```
53
54	Create commit with conventional format:
55	```bash
56	git commit -m "<type>[scope]: <description>" -m "<body>"
57	```
58
59	Verify commit succeeded:
60	```bash
61	git status
62	```
63
64	Only proceed to the next commit after verifying the current one completed.
65
66	## Conventional Commit Types
67
68	\| Type \| Description \|
69	\|------\|-------------\|
70	\| feat \| New feature \|
71	\| fix \| Bug fix \|
72	\| docs \| Documentation only \|
73	\| style \| Formatting, no code change \|
74	\| refactor \| Code change, no new feature or fix \|
75	\| perf \| Performance improvement \|
76	\| test \| Adding or fixing tests \|
77	\| chore \| Build process, auxiliary tools \|
78
79	## Commit Message Format
80
81	```
82	<type>[optional scope]: <description>
83
84	[optional body]
85
86	[optional footer]
87	```
88
89	- Description: Imperative mood, lowercase, no period ("add feature" not "Added feature.")
90	- Body: Explain what and why, not how
91	- Scope: Component or area affected (auth, api, db, ui)
92
93	## Rules
94
95	1. Never mix unrelated changes in a single commit
96	2. Always verify staging before committing
97	3. Always verify success after committing
98	4. Explain the plan before executing
99	5. Never use `git add .` or `git add -A` without explicit approval
100	6. Never include "Generated with Claude Code" or Co-Authored-By footers
101
102	## Example Session
103
104	```
105	$ git status
106	# Modified: auth/login.rb, auth/signup.rb, README.md, api/client.rb
107
108	Plan:
109	1. feat(auth): Improve login validation - auth/login.rb, auth/signup.rb
110	2. fix(api): Handle timeout errors - api/client.rb
111	3. docs: Add authentication guide - README.md
112
113	Executing commit 1...
114	$ git add auth/login.rb auth/signup.rb
115	$ git status # verify only auth files staged
116	$ git commit -m "feat(auth): improve login validation" -m "Add email format check and rate limiting"
117	$ git status # verify commit succeeded
118
119	Executing commit 2...
120	[continues...]
121	```

People who liked this also viewed

6 picks

Type