name: git-safe-workflow
description: Safely inspect, stage, commit, and (only if asked) push changes made by an AI agent. Use for commit/push requests, end-of-task checkpoints, merge conflict resolution, worktree safety checks, or deciding whether to use git commit --amend.

Git Safe Workflow

Core rules (always)

1. Collect repo context first (non-destructive):
2. git rev-parse --show-toplevel
3. git status --porcelain=v1 -b

4. git log -1 --oneline

5. Collect worktree context when relevant (also non-destructive):

6. git branch --show-current
7. git worktree list --porcelain

Run worktree context when:
- branch name is unexpected
- you are in a nested folder and not sure which checkout you are in
- Git refuses checkout because branch is already checked out elsewhere
- status shows detached HEAD or unusual metadata

1. Never run destructive or high-risk commands unless explicitly requested:
2. Do NOT use:
   • git reset --hard
   • git clean -fd
   • git push --force or --force-with-lease
   • git worktree prune
   • git worktree remove
   • git rebase (interactive or not) unless explicitly requested

3. If the user requests one:

   • restate the exact command you plan to run
   • explain why it is risky
   • then proceed

4. Avoid interactive prompts and editors unless the user says it is OK:

5. Prefer non-interactive commands
6. Avoid:
   • git add -p
   • editor-based rebase
   • commit message editor prompts
7. Prefer:
   • git commit -m "..." -m "..."

Worktree safety rules

1. Confirm you are in the intended worktree and branch before staging or committing:
2. git branch --show-current

3. git worktree list --porcelain

4. Detached HEAD safety:

5. If 'git branch --show-current' prints nothing, you are likely in detached HEAD.
6. Default behavior: do not commit immediately.
7. Explain the situation and ask whether to create a branch first, for example:
   • git switch -c

8. Only commit in detached HEAD if the user explicitly wants that and understands the risk.

9. Branch checked out in another worktree:

10. If Git refuses because the branch is already checked out elsewhere, do not use force by default.

11. Safe options:

    • switch that other worktree to a different branch, or
    • create a new branch for this worktree (recommended)

12. Worktree lifecycle operations:

13. Do not run these unless explicitly requested:
    • git worktree add
    • git worktree remove
    • git worktree move
    • git worktree lock or unlock
    • git worktree prune

Make a checkpoint commit (default)

1) Summarize the change

• git diff --stat
• git diff --staged --stat (if anything is staged)

2) Inspect details when needed

• git diff
• git diff --staged

Guidance:
- Always inspect full diff if changes are large, touch security-sensitive code, or involve config or CI.

3) Stage changes safely

Prefer explicit paths when practical:
- git add path/to/file1 path/to/file2

Otherwise stage tracked modifications and deletions:
- git add -u

Avoid staging everything blindly unless user explicitly wants it:
- avoid: git add .

4) Commit message

Use Conventional Commits when reasonable:
- type(scope): summary

Include:
- what behavior changed
- tests run, or explicitly note: tests not run

5) Commit (non-interactive)

• git commit -m "type(scope): summary" -m "Details... Tests: "

6) Verify

• git status
• git show --stat --oneline HEAD

Amend policy (git commit --amend)

Default rule

• Do not use 'git commit --amend' unless it clearly improves the most recent commit AND the commit has not been pushed.

Safe uses

Use amend when:
- You just made the last commit locally and immediately noticed:
- you forgot a file
- you need a tiny fix
- the commit message is wrong

Common safe commands:
- Add changes then amend without changing message:
- git commit --amend --no-edit
- Replace message non-interactively:
- git commit --amend -m "type(scope): summary" -m "Details... Tests: ..."

Avoid

Do not amend when:
- the commit is already pushed to a shared remote branch
- amending would require a force push to reconcile the remote

In that case:
- prefer a new follow-up commit
- only rewrite history if the user explicitly requests it and accepts the risk

Merge conflicts

1. Collect context:

2. git status --porcelain=v1 -b

3. Identify conflicted files:

4. git diff --name-only --diff-filter=U

5. Resolve conflicts carefully (no automation that discards intent).

6. After resolving:

   • git add

7. Continue the operation:

8. If merge:
   • git commit -m "merge: resolve conflicts" -m "Details... Tests: ..."

9. If rebase was explicitly requested and is in progress:

   • git rebase --continue

10. Verify:

11. git status
12. git show --stat --oneline HEAD (if a commit was created)

Push policy

• Only push if the user explicitly asks.
• Preferred push:
• git push -u origin HEAD

Main or master branch rule

• If currently on main or master, do not push directly by default.
• Create a branch first (ask user for branch name if not provided), then push that branch.

Force push rule

• Never force push unless explicitly requested.
• If requested:
• restate the exact force push command
• explain risk (rewriting shared history)
• then proceed