gener8v/gener8v.claude-skills.engineering

Git branching

Every change goes on its own branch. This includes a one-line fix and a change with no issue. Do not commit on the base branch.

1. Find the base branch

Use the first source that gives an answer:

1. Repository instructions. Read CLAUDE.md, CONTRIBUTING.md and .github/ documents. If they name a base or integration branch, use it.
2. Remote default branch.

   git symbolic-ref --short refs/remotes/origin/HEAD   # prints origin/<name>
   gh repo view --json defaultBranchRef -q .defaultBranchRef.name
   

3. Ambiguity. If the remote also has develop or development and no document says which one is the base, ask the user. Do not guess.

When an integration branch (for example develop) is the base, a hotfix for a released version starts from the default branch instead. Use that only when the user calls the work a hotfix.

2. Check where you are

git status --porcelain
git rev-parse --abbrev-ref HEAD

• If the working tree has changes that you did not make, stop. Ask the user what to do with them.
• If you are already on a branch for this same work, stay on it.
• If you are on the base branch with your own uncommitted edits, move them: git switch -c <name> keeps them in the working tree.

3. Start the branch from the remote tip

git fetch origin --prune
git switch -c <name> origin/<base>
git log -1 --oneline

Starting from origin/<base> means that a stale local base branch does no harm. Do not run git pull on the base branch to "catch up" first. It is not necessary.

4. Name the branch

Use the repository convention if it has one. If not, use <type>/<ref>-<slug>:

Part	Values
type	feat, fix, docs, chore, refactor, test, release, hotfix
ref	Issue number (42), pipeline ticket (ticket-007), or nothing
slug	Two to five lowercase words, joined with hyphens

Examples: fix/42-null-session-crash, feat/ticket-007-search-filters, docs/readme-install-steps.

5. While you work

• Commit in small steps that each make sense alone. Write the subject in the imperative, 72 characters or fewer. Use the body to say why.
• Do not add a Co-Authored-By: Claude trailer to any commit message. This is a gener8v rule.
• Before the first push, you can rebase onto origin/<base>. After the branch is pushed, merge the base into the branch instead. A rebase of a pushed branch rewrites history, and engineering:git-safety gates that.
• Push with a chain that stops on the first failure:

  set -o pipefail
  git fetch origin && <test command> 2>&1 | tail -n 40 && git push -u origin HEAD
  

  Without set -o pipefail, | tail hides the exit code of the command before it. Never pipe a git command or a test command through tail without it.

Parallel work

For two or more agents that edit code at the same time, read resources/parallel-work.md before you start any agent. In short: one batch branch from the base, one worktree and one branch per agent from the batch branch, and no two agents on the same files.

Done when

• You are on a branch with a clear name, and it starts at the current origin/<base>.
• git status shows no changes that belong to someone else.

Related skills

• engineering:github-pr-merge: open the PR when the work is complete.
• engineering:git-safety: approval rules for force-push, branch deletion and similar commands.
• engineering:github-issue-workflow: the full lifecycle of an issue or a pipeline ticket. It calls this skill first.