windows-git-ops（Windows git 操作）

Windows Git Ops

Overview

Use this skill when the task involves Git commands on Windows PowerShell. It prevents shell-specific mistakes, keeps Git operations auditable, and favors simple non-interactive command sequences over clever chained commands.

Hard Rules

• Assume the shell is PowerShell unless the environment clearly says otherwise.
• Do not use bash-only chaining or redirection syntax such as &&, ||, <<EOF, or other POSIX-only forms.
• Prefer one command per shell invocation for Git operations. Do not compress unrelated steps into a single shell string.
• Use non-interactive Git commands only. Avoid commands that open editors or interactive prompts.
• Before mutating Git state, inspect it with targeted commands such as git status --short, git branch --show-current, git diff --name-only, or git diff --cached --name-only.
• Stage only intended files. Never use broad staging when the change set should stay narrow.
• When committing from a dirty worktree, confirm the staged set matches the intended change before git commit.
• Do not revert, reset, or discard user changes unless the user explicitly asked for it.
• When creating a branch in Codex, use the required codex/ prefix.

PowerShell-Safe Patterns

• For sequential Git steps, run separate commands in separate tool calls.
• When an environment variable is needed for one command, set it explicitly in PowerShell form, for example `$env:PYTHONPATH='.'`.
• When quoting commit messages or paths, use PowerShell-safe quoting and avoid shell tricks copied from bash examples.
• If a command would be easier in bash but the environment is PowerShell, rewrite it for PowerShell instead of assuming bash compatibility.

Standard Workflow

Inspect

Use this sequence before any branch, staging, commit, or merge action:

1. git branch --show-current
2. git status --short
3. git diff --name-only
4. git diff --cached --name-only

Create Branch

1. Inspect current branch and worktree state.
2. Create the branch with git checkout -b codex/<name>.
3. Re-check git branch --show-current if the branch matters to the task.

Commit

1. Inspect unstaged and staged files separately.
2. Stage only the intended paths with explicit git add <path>.
3. Verify staged content with git diff --cached --name-only and, when needed, git diff --cached.
4. Commit with a non-interactive message such as git commit -m "fix: ..." .

Merge Back

1. Ensure the feature branch is committed.
2. git checkout main
3. Confirm main branch state.
4. Merge with git merge --no-ff <branch> -m "<message>" unless the user asked for a different strategy.
5. Confirm final branch and worktree state.

Common Failure Prevention

• If you catch yourself writing cmd1 && cmd2, split it into separate commands.
• If you are unsure whether a helper method or Git flag is valid in this shell, check the real definition or help output before using it.
• If the worktree contains unrelated files, leave them untouched and call them out explicitly in the final summary.
• If a command fails because of shell syntax, rewrite it in native PowerShell form instead of retrying the same pattern.

Output Expectations

• State the current branch when it matters.
• State exactly which files were staged or committed.
• Mention untracked or unrelated files that were intentionally left alone.
• When merge or commit succeeds, report the resulting commit hash if available.