git-safety

# Git Safety Skill

Apply rigorous git safety protocols to prevent data loss and conflicts in collaborative development environments, particularly when multiple agents or developers work concurrently.

## Core Safety Principles

### File Management Rules

**Deleting Files:**
- ⚠️ **STOP before deleting any file to resolve type/lint failures** - Ask the user first
- Only remove obsolete files when changes make them genuinely irrelevant
- Only revert your own work or changes explicitly requested by the user
- **Coordinate with teammates before removing in-progress edits**
- Never assume a file is safe to delete without confirmation

**File Modifications:**
- Always verify file ownership and recent changes before modifying
- Check `git log <file>` to see who last edited
- Communicate before making sweeping changes to shared files

### Environment & Configuration Safety

**Critical: Environment Files**
- 🚫 **NEVER edit `.env` or any environment variable files**
- Only the user may change environment configurations
- This includes `.env`, `.env.local`, `.env.production`, etc.
- If environment changes are needed, inform the user - never make them yourself

**Git Configuration:**
- Never modify `.gitconfig` or repository git settings
- Never amend commits without explicit written approval
- Preserve existing git hooks and configurations

## Destructive Operations - Extreme Caution Required

### Absolutely Forbidden Without Explicit Permission

🚨 **ABSOLUTELY NEVER run these operations unless the user gives explicit, written instruction:**

- `git reset --hard` - Destroys uncommitted work permanently
- `git checkout <old-commit>` - Can lose current work
- `git restore --source=<old-commit>` - Reverts to old state, losing changes
- `rm -rf` - Irreversible file deletion
- `git push --force` - Overwrites remote history
- `git rebase` without safeguards - Can lose commits
- `git clean -fd` - Deletes untracked files permanently

### What Requires User Approval

Before running