Branch workflow

Skill ToruAI/toru-claude-agents/skills/branch-workflow

Branch and commit conventions that keep an agent's work reviewable — one branch per task, main stays clean, nothing force-pushed.From its SKILL.md

Install

npx -y skills add ToruAI/toru-claude-agents --skill branch-workflow

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

15 stars15 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
runs commandsInstructs the agent to run 8 commands, including `git checkout main` and 7 more.

SKILL.md

2.4 KB, 590 tokens by cl100k_base, as published. Nobody here has run it

Branch Workflow - Safe Autonomous Coding

All work happens on branches. Main stays clean. The user reviews before merge.

Branch Naming

feat/TASK-ID-short-description    # New features
fix/TASK-ID-short-description     # Bug fixes
docs/TASK-ID-short-description    # Documentation
research/TASK-ID-description      # Exploration
refactor/TASK-ID-description      # Code improvements

Examples:

feat/API-142-rate-limiting
fix/WEB-87-login-redirect
docs/API-150-auth-guide

Commit Format

TASK-ID: Brief description of change

- Detail 1
- Detail 2

Co-Authored-By: Claude <co-author>

Good commits:

Atomic (one logical change)
Buildable (tests pass at each commit)
Descriptive (explains what, not how)

Workflow

Starting Work

git checkout main
git pull origin main
git checkout -b feat/TASK-ID-description

During Work

# Commit often
git add -A
git commit -m "TASK-ID: Implement X"

# Push periodically
git push -u origin feat/TASK-ID-description

Finishing Work

# Ensure tests pass
cargo test  # or npm test, pytest, etc.

# Push final state
git push

# Log completion (megg or BACKLOG.md)

Rules

NEVER Do

Push directly to main
Force push (git push --force)
Merge your own branches
Delete branches without the user's approval
Commit secrets or credentials

ALWAYS Do

Create branch before changing code
Run tests before pushing
Commit with clear messages
Push branches for review
Document decisions

When Blocked

Push current work to branch
Document blocker in .megg/blocked.md or commit message
Move to next task
The user will review on return

Review Workflow

The user reviews branches by:

# See all work
git branch -a

# Review specific branch
git log main..feat/BRANCH-NAME
git diff main..feat/BRANCH-NAME

# Merge if good
git checkout main
git merge feat/BRANCH-NAME

Integration with OpenSpec

For OpenSpec changes:

Branch name matches change ID: feat/add-plugin-system
One branch per OpenSpec change
Archive OpenSpec change only after merge

Emergency Fixes

For critical bugs in production:

Create hotfix/description branch
Minimal fix only
Tests must pass
Document urgency in commit
Flag for immediate user review

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most pr commit review skills give in 590 tokens

Counted across 1,055 of the 1,911 authors here whose files we hold, read 2026-09-06

Use conventional commit message formatin 150 of 1055, across 145 files
Announce skill usage at startin 78 of 1055
Use imperative mood for commit descriptionsin 54 of 1055, across 51 files
Add directory to gitignore if not ignoredin 52 of 1055, across 41 files
Use imperative mood for commit subjectin 52 of 1055
Run tests to verify clean baselinein 42 of 1055, across 32 files
Push branch to originin 40 of 1055, across 38 files
Verify worktree directory is ignored before creationin 39 of 1055, across 32 files
Delete branches after mergingin 38 of 1055, across 30 files
Create worktree with new branchin 37 of 1055, across 32 files
Wrap body text at 72 charactersin 36 of 1055, across 34 files
Auto-detect and run project setupin 35 of 1055, across 27 files

Said here and by no other author read

Pull main before starting work
Document decisions
Document blockers in the designated file

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.