# Git Instructions

## 🚨 GIT POLICY - ABSOLUTELY CRITICAL

**NEVER EVER make git commands without explicit user approval!**

### Forbidden Commands - DO NOT RUN:
1. ❌ **git add** - User runs this themselves (including git add ., git add -A, git add <file>)
2. ❌ **git commit** - User runs this themselves  
3. ❌ **git push** - User runs this themselves
4. ❌ **git push --force** - User runs this themselves
5. ❌ **git reset** - User runs this themselves
6. ❌ **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:

1. **Run `git diff --staged` or `git diff`** — read what actually changed
2. **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.
3. **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`