When should I avoid pushing to the main branch?

Never push to the default branch unless explicitly instructed; use a topic branch for changes.

How should I name branches?

Always use a topic branch with a short hyphenated name that describes the work.

git

npx machina-cli add skill bendrucker/claude/git --openclaw

Files (1)

SKILL.md

842 B

Git

Never git push to the default branch (usually main or master) unless I explicitly instruct you to do so.
Always use a topic branch with a few brief word hyphenated name

Commit Messages

For multi-line commit messages:

Simple (subject + body): Use multiple -m flags. Each -m creates a separate paragraph:
```
git commit -m "Subject line" -m "Body paragraph here."
```
Complex: Use the Write tool to write to tmp/commit-msg.md, then git commit -F tmp/commit-msg.md

Do not use heredocs — they create temp files that fail in sandbox environments. This includes git commit -m "$(cat <<'EOF' ... EOF)" and cat > file << 'EOF'.

Source

git clone https://github.com/bendrucker/claude/blob/main/plugins/git/skills/git/SKILL.mdView on GitHub

Overview

This skill codifies safe Git practices for everyday development. It emphasizes not pushing to the default branch unless instructed, and always starting work on a topic branch with a short hyphenated name. Clear commit messages help teams track changes and review history more easily.

How This Skill Works

It enforces rules like never pushing to the default branch unless instructed and always starting work on a topic branch with a hyphenated name. For commits, use multiple -m flags for simple multi line messages; for complex messages, write to tmp/commit-msg.md and commit with -F tmp/commit-msg.md. It also warns against heredocs because they can fail in sandbox environments.

When to Use It

Starting new features or fixes on a topic branch before merging.
Collaborating with others via per feature branches and pull or merge requests.
Preparing clean, readable commit history with structured messages.
Avoiding accidental pushes to the default branch on shared repos.
Refining work before asking for code review or integration.

Quick Start

Step 1: Create a topic branch: git checkout -b feature-xyz
Step 2: Stage and commit with clear messages: git add . ; git commit -m Subject -m Body
Step 3: Push the branch for review: git push -u origin feature-xyz

Best Practices

Always create a topic branch with a short hyphenated name.
Never push to the default branch unless explicitly instructed.
Use multi-line commit messages with -m for simple cases.
For complex commits, write the message to tmp/commit-msg.md and use -F to include it.
Avoid heredocs to prevent sandbox failures.

Example Use Cases

Developing a new feature on a topic branch, then pushing and opening a PR.
Fixing a bug on a separate branch to isolate changes for review.
Preparing a complex commit by writing a detailed message to tmp/commit-msg.md and committing with -F.
Ensuring no pushes to main occur during collaboration with teammates.
Reviewing a feature branch and merging it into main after approval.

Frequently Asked Questions

Add this skill to your agents