Git Workflow

Follow repository-specific instructions first. Treat them as the source of truth for branch names, remotes, checks, and pull-request conventions. Read them before changing Git state.

This skill assumes the general Git-safety rules supplied by the environment (preserve unrelated work, approval before destructive remote changes, verbatim CLI output). What it adds:

• commit subjects that name delivered behavior, with a body whenever rationale is not evident from the diff (see Commit Workflow)
• rebase a feature branch onto its base rather than merging the base in
• apply pull-request feedback by amending the relevant existing commit, not a follow-up commit
• when a push rewrites a published branch, use --force-with-lease and reconcile a stale lease before overwriting
• pushing a validated branch and opening or updating its PR is a routine step that needs no separate approval; merging, deleting, and other remote mutations still do

Before Changing Git State

1. Inspect git status, the current branch, and relevant repository instructions.
2. Preserve unrelated changes. Do not discard work or clean history without the required approval. Amend commits only as directed in the commit workflow.
3. Separate exploratory work from completed implementation. Only stage and commit the latter.

Commit Workflow