Git commit
npx -y skills add RileyCornelius/Code-Skills --skill git-commitAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Generate well-structured git commit messages with a standard subject line and optional description. Use when committing staged changes, writing commit messages, or when the user asks to commit.
SKILL.md
2.2 KB, as published. Nobody here has run it
Git Commit
General Rules
- Commit messages must have a subject line and may have a description.
- The subject line should start with Standard Terminology.
- The subject line should be capitalized and must not end in a period.
- The subject line should be written in imperative mood (Fix, not Fixed / Fixes etc.).
- The description should only contain explanations as to what and why, never how. The latter belongs in documentation and implementation.
Standard Terminology
| First Word | Meaning |
|---|---|
| Add | Create a capability e.g. feature, class, dependency. |
| Remove | Remove a capability e.g. feature, class, dependency. |
| Update | Update a capability e.g. feature, class, dependency. |
| Fix | Fix an issue e.g. bug, typo, accident, misstatement. |
| Refactor | A change that just refactors existing code. |
| Optimize | Refactor of performance, e.g. speed up code. |
| Start | Begin doing something; e.g. create a feature flag. |
| Bump | Release a version must contain a version number. |
Description
Use the description to explain the background and reasoning, not the implementation. You can save all fellow developers and your future self some time by explaining why you did what instead of how you did it. Only use a description when the reasoning is not obvious. If the reasoning is obvious, skip the description and just write a clear subject line.
- Describe why a change is being made.
- How does it address the issue?
- What effects does it have?
- Describe any limitations of the current code.
- Do not assume the reader understands what the original problem was.
- Bullet points are okay.
- Descriptions are not always necessary.
Examples
In keeping with the standard output of git itself, all commit subject lines must be written in imperative mood.
Good
- Add feature X
- Refactor X for readability
- Update getting started documentation
- Remove deprecated methods
- Bump v1.0.0
Bad
- Fixed bug with Y
- Changing behavior of X
Ugly
- More fixes for broken stuff
- Sweet new API methods
- 42