moilanik 5c6b3b9636 docs: add commit message quality rules to git instructions

- read diff before writing, only include what's in the diff
- no CHANGES: headers, no speculative outcome sections
- bullet points state what changed, not why or how

2026-03-12 11:41:50 +02:00

3.1 KiB

Raw Blame History

Git Instructions

🚨 GIT POLICY - ABSOLUTELY CRITICAL

NEVER EVER make git commands without explicit user approval!

Forbidden Commands - DO NOT RUN:

❌ git add - User runs this themselves (including git add ., git add -A, git add )
❌ git commit - User runs this themselves
❌ git push - User runs this themselves
❌ git push --force - User runs this themselves
❌ git reset - User runs this themselves
❌ ANY command that modifies git repository or server state

What You CAN Do:

✅ git status - Show current state
✅ git diff - Show changes
✅ git log - Show history
✅ Show the command user should run
✅ Explain what the command will do

Exception:

Only if user explicitly says:

"commit this now"
"push this now"
"go ahead and commit"

Otherwise: SHOW the command, WAIT for user to run it

Best Practices

Always show git diff before suggesting commits
Show git status to verify what will be committed
Explain impact of each git operation
User controls git commands, you analyze and advise
Never assume user wants to commit
Production platform infrastructure: Stability > Speed

Commit Message Workflow

When the user asks for a commit message:

Run git diff --staged or git diff — read what actually changed
Documentation check — scan the changed files and ask: does any docs/ or README.md need updating based on these changes? If yes, flag it clearly before writing the message. Do not block the commit — just surface it.
Write the commit message only — one short subject line, optionally a blank line and brief body if the change needs context. Output just the message text in a code block. Do NOT wrap it in a git commit command.

Format:

<type>: <what changed>

<optional: why, or what is not obvious from the diff>

Types: feat, fix, docs, refactor, chore

Commit message rules

Only include what actually changed in this commit.

Run git diff --staged (or git diff if nothing staged) and read it fully before writing
List only files and lines that appear in the diff
If a file appears in the diff but only has whitespace or comment changes, omit it from the body
Never mention changes that are not in the diff — even if you remember discussing them earlier in the session
If unsure whether something changed, check the diff — do not guess

Format rules:

Subject line: max ~72 chars, imperative mood ("Fix", "Add", "Remove" — not "Fixed", "Added")
Body: optional, only when the why is not obvious from the diff
No bullet-pointed list of every file changed unless the diff spans many unrelated files
No "CHANGES:" headers, no file-by-file breakdowns for single-topic commits
No "Expected:", "Result:", "Impact:" or any speculative outcome sections — commit messages describe what changed, not what is predicted to happen
Bullet points state what changed, not why it was wrong or how it works — keep each line short and factual
- ✅ use MC_HOST_minio for S3 auth
- ❌ Use MC_HOST_minio env var for direct S3 auth (no mc alias set)

3.1 KiB Raw Blame History