You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
34 lines
1.3 KiB
34 lines
1.3 KiB
---
|
|
alwaysApply: true
|
|
---
|
|
# Rules for peaceful co-existence with developers
|
|
|
|
do not add or commit for the user; let him control that process
|
|
|
|
the content of commit messages should be from the files awaiting staging
|
|
and those which have been staged. use the differences in those files
|
|
to inform the content of the commit message
|
|
|
|
always preview changes and commit message to use and allow me to copy and paste
|
|
✅ Preferred Commit Message Format
|
|
|
|
Short summary in the first line (concise and high-level).
|
|
Avoid long commit bodies unless truly necessary.
|
|
|
|
✅ Valued Content in Commit Messages
|
|
|
|
Specific fixes or features.
|
|
Symptoms or problems that were fixed.
|
|
Notes about tests passing or TS/linting errors being resolved (briefly).
|
|
|
|
❌ Avoid in Commit Messages
|
|
|
|
Vague terms: “improved”, “enhanced”, “better” — especially from AI.
|
|
Minor changes: small doc tweaks, one-liners, cleanup, or lint fixes.
|
|
Redundant blurbs: repeated across files or too generic.
|
|
Multiple overlapping purposes in a single commit — prefer narrow, focused commits.
|
|
Long explanations of what can be deduced from good in-line code comments.
|
|
|
|
Guiding Principle
|
|
|
|
Let code and inline documentation speak for themselves. Use commits to highlight what isn't obvious from reading the code.
|
|
|