git-workflow

Git Workflow

Use this skill for Git procedures. Mandatory authorization and preservation gates remain in the Git rule (${HANDBOOK_ROOT}/rules/130-git.mdc) and the agent audit rule (${HANDBOOK_ROOT}/rules/020-agent-audit.mdc).

Non-Negotiable Workflow

1. Inspect the repository before changing it:

   GIT_REPO_ROOT="$(git rev-parse --show-toplevel)"
   git -C "$GIT_REPO_ROOT" status --short --branch
   git -C "$GIT_REPO_ROOT" branch --show-current
   git -C "$GIT_REPO_ROOT" rev-parse HEAD
   

2. Use the quoted GIT_REPO_ROOT variable for repository-relative paths and artifacts. Never derive the root from pwd or a workspace assumption.

3. Preserve unrelated user changes. Never discard, stash, rewrite, or relocate them merely to simplify the task.

4. Treat commit, push, force update, history rewrite, restore/discard, worktree creation, worktree removal, and destructive branch deletion as separate authorization boundaries. Never create a worktree without explicit HITL approval of the exact repository, path, branch, base ref, and command.

5. Run applicable tests, lint, formatting, type checks, and build steps before proposing a commit.

6. Before committing, show the complete message and exact file list, then wait for explicit confirmation.

7. Respect repository signing policy. If signing fails, stop; never silently create an unsigned commit.

8. Before pushing, fetch with pruning and inspect upstream divergence. Do not blindly pull, rebase, merge, or force-push.

Common Workflows

Create a feature branch

Start from a refreshed remote base.

For a clean worktree:

git fetch origin --prune
git switch main
git pull --ff-only
git switch -c feat/your-feature

When the current worktree has unrelated changes, preserve it. If an isolated worktree is proposed, show the exact repository, destination path, branch, base ref, and command, then wait for explicit HITL approval:

git fetch origin --prune
git worktree add -b feat/your-feature ../project-your-feature origin/main