git-ship

Git Ship

When this triggers

• User says "ship it", "commit this", "push", "merge this branch", or asks to run git commit, git push, git merge, git rebase, git reset, or git branch -d.
• Any git write operation is about to happen in this project — this skill is the mandatory entry point.

When this does not trigger

• Read-only git commands (git status, git diff, git log, git show, git branch --show-current) — those are fine without invoking this skill.
• Non-git tasks — no overlap with other sibling skills.

Mandatory Invocation

This skill is the ONLY entry point for git write operations in this project. Before running git commit, git push, git merge, git rebase, git reset, git branch -d, or git checkout main — you MUST be inside this skill. Read-only commands (status, diff, log, show, branch --show-current) are fine without invocation.

Required inputs

• Current branch name (git branch --show-current).
• The diff to be committed (git diff / git diff --staged).
• User confirmation before pushing or merging to main.

Pre-Ship Validation (Multi-Tab Safety)

1. Branch guard: Run git branch --show-current. If on main/master, REFUSE and error: "You're on main. This should not happen — a feature branch should have been created at session start." Do NOT proceed with the commit.
2. Run git diff and review ALL hunks. Check if any changes don't belong to the current task/ticket (e.g., changes from another Claude Code tab session).
3. If suspicious mixed changes are detected: warn the user, list the foreign hunks, and suggest using git add -p to selectively stage only the relevant changes.
4. Verify the commit will only include files relevant to the current task.

Workflow

1. Run git status --porcelain to see all changes.
2. Stage explicit paths only. NEVER git add -A / git add . / git add --all — a blanket add sweeps in a parallel session's work (this has happened: ~16 foreign files in one commit). Instead:
   • Derive the list of paths belonging to THIS task from the porcelain output.
   • Show the user that exact file list before staging.
   • Stage them by path: git add path/one path/two.
   • Any dirty file not on the list: name it and ask — do not stage, do not stash it unilaterally.
   • If a PreToolUse hook blocking blanket adds is installed, and it fires, fix the command; do not route around it.
3. Run git diff --staged and confirm the staged set matches the list you showed.
4. Generate a conventional commit message: type(scope): description (under 72 chars).
5. Commit. If amending, verify with git log -1 --stat that the amend replaced the commit rather than stacking a new one.
6. Ask the user: "Push to remote?" — only push if they confirm.
7. Before any push that lands on main, run git fetch && git rebase origin/main first. On conflict, stop and show it — a parallel session may have pushed conflicting docs.