home / skills / ab300819 / skills / git-safety

git-safety skill

/skills/git-safety

This skill enforces safe git file operations by mandating git mv/git rm for controlled files and validates status before actions.

npx playbooks add skill ab300819/skills --skill git-safety

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.5 KB
---
name: git-safety
description: Git 操作安全与规范。强制要求使用 git 原生命令处理受控文件,防止丢失索引或产生冗余变更。当 Agent 尝试移动、重命名或删除文件时触发。
---

# Git Safety & Standards

该 Skill 旨在确保在 Git 仓库中进行文件操作时的安全性和历史完整性。

## 核心准则

### 1. 移动与重命名 (Move & Rename)
- **禁止**直接使用 `mv` 命令操作受 Git 跟踪的文件。
- **强制使用** `git mv <old_path> <new_path>`。
- **理由**:确保 Git 自动跟踪文件重构,保留文件的 Git History,避免识别为“删除 + 新增”。

### 2. 删除 (Delete)
- **禁止**直接使用 `rm` 或 `rm -rf` 操作受 Git 跟踪的文件。
- **强制使用** `git rm <path>` 或 `git rm -r <path>`。
- **理由**:直接从工作区和索引中同步移除,避免残留未跟踪的删除变更。

### 3. 操作前自检流程
当 Agent 准备操作文件时,应遵循以下逻辑:
1. **检查状态**:执行 `git ls-files <path>`。
2. **判断**:
   - 如果有输出(说明文件受控)→ 使用 `git mv` / `git rm`。
   - 如果无输出(说明是未跟踪文件)→ 使用普通 `mv` / `rm`。

## 适用场景
- 重构代码导致的文件目录结构调整。
- 删除过时的文档或代码文件。
- 项目清理。

## 约束
- 严禁在未确认文件状态的情况下盲目使用普通文件管理命令。
- 在执行大规模移动操作前,建议先执行 `git status` 确保工作区是干净的。

Overview

This skill enforces safe and consistent Git file operations to preserve repository history and avoid index inconsistencies. It requires using native Git commands for moves, renames, and deletions whenever files are tracked. It triggers when an agent attempts to move, rename, or delete files and prevents unsafe native filesystem commands on tracked files.

How this skill works

Before any file operation, the skill runs git ls-files <path> to determine whether the target is tracked. If the file is tracked, the skill requires git mv or git rm (with -r when needed) so Git updates both the working tree and the index cleanly. If the file is untracked, normal mv or rm are allowed. The skill can also advise running git status before large refactors to ensure a clean working tree.

When to use it

  • Refactoring that moves or renames source files or directories
  • Removing deprecated code, assets, or documentation from the repo
  • Automated agents or scripts that modify repository files
  • Bulk project cleanup where many files are relocated or deleted
  • Any workflow where preserving Git history and index integrity matters

Best practices

  • Always check file tracking status with git ls-files <path> before changing files
  • Use git mv <old> <new> for moves and renames to preserve history
  • Use git rm <path> or git rm -r <path> to remove tracked files and update the index
  • Run git status before large batch operations to ensure a clean working tree
  • Avoid blind use of mv or rm on paths without confirming they are untracked

Example use cases

  • An agent reorganizes a package: detect tracked files and run git mv to preserve commit history
  • A cleanup script removes obsolete docs: use git rm to ensure deletions are recorded in the index
  • A CI job refactors directories: enforce checks so tracked files are moved via git commands
  • A developer script automates file renames: block plain mv for tracked files to prevent orphaned history

FAQ

What if git ls-files returns nothing but the file looks tracked?

If git ls-files <path> returns no output the file is not in the index; use plain mv/rm. If you expect it to be tracked, run git status or git ls-files -s to verify and ensure no submodule or ignore rules interfere.

Can I force native commands when necessary?

You should only bypass the rule when you intentionally want to break tracking. Prefer staging the correct git commands; if you must use native commands, follow up with git add/git rm to reconcile the index.