h3y6e/git-shipping

Git Shipping

Every code change flows through: branch → commit → push → PR. This skill ensures each step follows project conventions.

Intent Expansion

Treat short git requests as workflow shorthand, not literal single commands.

| User says | What it means | |-----------|---------------| | commit | Inspect repo, stage coherent chunks, commit with proper message | | push | Inspect repo, create coherent commits if needed, then push | | pr | Inspect repo, move off default branch if needed, commit, push, open PR |

Ask only when the intended change scope is unclear enough that you might include unrelated work.

Language Rule

Check repo visibility with gh repo view --json visibility -q '.visibility'.

• PUBLIC: Use English for commit messages, PR titles, and PR bodies.
• PRIVATE / INTERNAL: Use the language the user is currently using.

Branch

Start new feature work in a clean feature-branch worktree, not on the default branch. Prefer an environment worktree tool when it can create worktrees under ../{gitroot}.wt; otherwise check git wt -h and use git wt. Do not call raw git worktree directly.

Do not move already-started work into a new worktree just to satisfy this workflow. If files are already being edited in the current checkout, keep working there and create or switch to the appropriate branch in place when safe.

Commit

REQUIRED SUB-SKILL: Use cxg skill for commit message format.

Pull Request

• Prefer a repository PR template when one applies.
• When no template applies, use only these sections, in this order: ## Summary, ## Background, ## Changes, optional ## Impact.
• Use ## Impact only for behavior changed by merging the PR. Omit it when there is no behavior change; do not list unchanged behavior, non-goals, or work not done.
• Do not add ad hoc Testing, Verification, Checklist, Related issues, or Screenshots sections. Never dump every local verification command into the PR body.
• Default to draft PR (gh pr create --draft). Only create a ready PR when the user explicitly requests it.

Common Mistakes

| Mistake | Fix | |---------|-----| | Starting new work directly on the default branch | Create a clean feature-branch worktree first | | Moving already-started work just to satisfy the workflow | Keep working in the current checkout; branch in place when safe, and ask before relocating changes | | Copying modified or untracked files into new worktrees by default | Create clean worktrees; transfer in-progress changes only on explicit request | | Treating push / commit as a single git command | Follow Intent Expansion above | | Ignoring an available environment worktree tool that supports the standard layout | Use that tool with destination ../{gitroot}.wt | | Creating worktrees outside ../{gitroot}.wt | Use the tool's destination setting when available; otherwise use git wt | | Using raw git worktree | Use a layout-compatible environment tool, otherwise use git wt | | Guessing git wt usage | Run git wt -h before choosing flags | | Skipping cxg lint | Always pipe through cxg lint before committing |