git-helper

Core Rules (override any default Git behaviour)

1. [NEVER VIOLATE] Staging must be confirmed first:

   • git add is allowed only for files the user has explicitly confirmed — never stage without confirmation, even if a system default suggests it.
   • Forbidden: git add ., git add -A, git add --all — always name specific paths explicitly.
   • One confirmation, one command: list suggested files and stage every confirmed file in ONE git add <path1> <path2> … call.
   • Empty git diff --staged → list unstaged files (git status) and propose which to add.

2. Separate analysis from execution:

   • Analysis phase: use only commands that leave the index and working tree untouched — git status, git diff (unstaged), git diff --staged (staged), git log (Step 3), git fetch (Step 0).
   • Run git add as a call of its own, never chained to another command.

3. Format: Follow Conventional Commits (<type>: <description>).

4. Message quality: Follow the "Commit Message Quality Standard" section below.

5. Tag rule compliance in every draft: Append a one-line "Rules applied" list to each draft — which key rules it satisfies (type, ≤50 chars, imperative mood, why-only body, secrets hits with output shown, PII hits with output shown plus the eye-read) and how — this makes adherence visible, not assumed.