TL;DR
- 目的:Perform git cleanup assessment during authorized security testing. Use this skill when indicators of the vulnerability class are present in the target
- 适用:通用
- 输入:目标信息
- 输出:执行结果 + 证据
- 红线:仅限授权范围内;扫描限速 -c 10 -rl 10;所有动作记 oplog
- 关联:上游:003-src-session-start → 下游:003-src-session-start(按需调用)
Individual Branches
Safe to Delete (merged with -d)
| Branch | Merged Into |
|---|---|
| fix/typo | main |
Safe to Delete (squash-merged, requires -D)
| Branch | Merged As |
|---|---|
| feature/login | PR #42 |
Needs Review ([gone] remotes, no PR found)
| Branch | Last Commit |
|---|---|
| experiment/old | abc1234 "WIP something" |
Keep (active work)
| Branch | Status |
|---|---|
| wip/new-feature | 5 unpushed commits |
Worktrees
| Path | Branch | Status |
|---|---|---|
| ../proj-auth | feature/auth | STALE (merged) |
Summary:
- 4 related branches (feature/api-*) - recommend delete all
- 1 merged branch - safe to delete
- 1 squash-merged branch - safe to delete
- 1 needs review
- 1 to keep
Which would you like to clean up?
Use AskUserQuestion with clear options:
- Delete all recommended (groups + merged + squash-merged)
- Delete specific groups/categories
- Let me pick individual branches
**Do not proceed until user responds.**
### GATE 2: Final Confirmation with Exact Commands
Show the EXACT commands that will run, with correct flags:
```markdown
I will execute:
# Merged branches (safe delete)
git branch -d fix/typo
# Squash-merged branches (force delete - work is in main via PRs)
git branch -D feature/login
git branch -D feature/api
git branch -D feature/api-v2
git branch -D feature/api-refactor
git branch -D feature/api-final
# Worktrees
git worktree remove ../proj-auth
Confirm? (yes/no)
IMPORTANT: This is the ONLY confirmation needed for deletion. Do not add extra confirmations if -D is required.
Phase 5: Execute
Run each deletion as a separate command so partial failures don't block remaining deletions. Report the result of each:
git branch -d fix/typo
git branch -D feature/login
git branch -D feature/api
git branch -D feature/api-v2
git branch -D feature/api-refactor
git branch -D feature/api-final
git worktree remove ../proj-auth
If a deletion fails, report the error and continue with remaining deletions.
Phase 6: Report
## Cleanup Complete
### Deleted
- fix/typo
- feature/login
- feature/api
- feature/api-v2
- feature/api-refactor
- feature/api-final
- Worktree: ../proj-auth
### Remaining (4 branches)
| Branch | Status |
|--------|--------|
| main | current |
| wip/new-feature | active work |
| experiment/old | needs review |
Safety Rules
- Never invoke automatically - Only run when user explicitly uses
/git-cleanup - Two confirmation gates only - Analysis review, then deletion confirmation
- Use correct delete command -
-dfor merged,-Dfor squash-merged/superseded - Never touch protected branches - main, master, develop, release/* (filtered programmatically)
- Block dirty worktree removal - Refuse without explicit data loss acknowledgment
- Group related branches - Don't scatter them across categories
Rationalizations to Reject
These are common shortcuts that lead to data loss. Reject them:
| Rationalization | Why It's Wrong |
|---|---|
| "The branch is old, it's probably safe to delete" | Age doesn't indicate merge status. Old branches may contain unmerged work. |
| "I can recover from reflog if needed" | Reflog entries expire. Users often don't know how to use reflog. Don't rely on it as a safety net. |
| "It's just a local branch, nothing important" | Local branches may contain the only copy of work not pushed anywhere. |
| "The PR was merged, so the branch is safe" | Squash merges don't preserve branch history. Verify the specific commits were incorporated. |
"I'll just delete all the [gone] branches" |
[gone] only means the remote was deleted. The local branch may have unpushed commits. |
| "The user seems to want everything deleted" | Always present analysis first. Let the user choose what to delete. |
| "The branch has commits not in main, so it has unpushed work" | "Not in main" ≠ "not pushed". A branch can be synced with its remote but not merged to main. Always check git log origin/<branch>..<branch>. |
When to Use
- Target presents indicators of the vulnerability class this skill covers
- Fingerprint or recon indicates the relevant technology stack is in use
- Authorized testing scope covers the target endpoint or component
- Findings need to be validated through this skill's methodology
When NOT to Use
- Target is clearly outside this skill's scope (refer to related skills)
- No authorization for testing
- Need a different category of testing (use related skills)