git-workflowlisted

# Git Workflow ## Iron Law `NEVER REWRITE SHARED HISTORY OR SKIP RECOVERY.` The host owns git mechanics and access permission. This skill owns the gates: recoverability and approval of published text. ## When to Use - Rebases, merge conflicts, bisects, reflog recovery, branch cleanup, PR history repair, force-push decisions, or any GitHub access. ## When NOT to Use - Staging, splitting, or committing reviewed work; use `commit`. - Reviewing correctness; use `code-review`. Refactor planning; use `refactoring`. CI failure triage; use `debugging`. ## Rules 1. Branch without ceremony. Starting new work on the default branch, create a topic branch first. On an existing topic branch, keep going unless the new work is clearly unrelated; then branch off `main` and say which branch received the work. Do not ask which branch to use. 2. The host's permission system owns GitHub access. Hosts already gate network calls and `gh` under the user's account, so do not add a second chat-level ask on top of an approval the host granted. Reserve your own questions for writes that publish user-owned text and for destructive operations. Identify the surface first (`gh` CLI, GitHub MCP, or host tools); `gh` is absent from some sandboxes, which does not mean GitHub is out of reach. 3. Humans approve PR and issue text before it is published. Draft the title and body locally, show them, and get approval of that exact text. Never let a tool open an editor or se