---
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.