Run any Skill in Manus with one click

git-branch-pr-workflow

Stars0

Forks0

UpdatedJune 18, 2026 at 19:30

Before making any non-trivial code, docs, or config change -- create a feature branch first, then open a PR. Never commit directly to main. Apply by default before any edit; this is the baseline branch discipline that all other git skills build on.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

joshrotenberg

joshrotenberg/agent-tools

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	git-branch-pr-workflow
description	Before making any non-trivial code, docs, or config change -- create a feature branch first, then open a PR. Never commit directly to main. Apply by default before any edit; this is the baseline branch discipline that all other git skills build on.
allowed-tools	Bash(git ) Bash(gh )

Git branch + PR workflow

Default to git checkout -b <type>/<description> before any edits. Never commit directly to main, even on solo projects. Conventional commit prefixes: feat, fix, refactor, chore, ci, docs, test. Push branch, open PR, let the user (or the dispatcher loop) merge.

When to apply

Any code change beyond a trivial typo
Any docs change that affects committed content
Any config or workflow change

Why

Keeps the commit log on main clean and bisectable
CI runs against the PR before main moves
Squash-merge gives main a clean linear history
Even solo, the PR body is a useful place to record the "why"

How to apply

Before any change, git checkout -b <type>/<short-description>.
Make commits with conventional-commit messages (<type>: <description>; ! marks breaking).
Push: git push -u origin <branch>.
Open the PR: gh pr create [--draft] with a tight body that references the underlying issue (use a Closes #N keyword in the PR body so the merge closes the linked issue).
Wait for CI; merge with gh pr merge --squash --delete-branch.

Commit-message conventions

feat: ... -- new user-visible behavior
fix: ... -- bug fix
refactor: ... -- internal restructuring, no behavior change
chore: ... -- repo maintenance (dependencies, config, etc.)
ci: ... -- CI/release-process changes
docs: ... -- documentation only
test: ... -- tests only

Append ! to mark a breaking change: refactor!: cut --head and --tail (closes #42).

The same prefixes apply to issue titles, not only commits, branches, and PR titles. An issue that proposes a new skill is feat: ...; an issue documenting a bug is fix: .... The triage skill normalizes issue titles to this scheme.

No trailers, author is the repo owner

Do not include "Generated with Claude Code" or "Co-Authored-By" trailers on any commit. The commit author is always the repo owner (Josh Rotenberg <joshrotenberg@gmail.com>); no co-author is added. After committing, verify before pushing:

git log -1 --format='%an <%ae>%n%(trailers)'

The author line must be the repo owner and the trailers must be empty. If a trailer slipped in, amend it out (git commit --amend) before pushing.

git-fix-pr-branching -- how to handle fixes when a PR is open vs merged.
heredoc-backticks -- formatting the PR body without breaking the markdown.

More from this repository

same repository

runner-vs-worker

joshrotenberg/agent-tools

Use when deciding whether to dispatch a runner or a worker for a subtask. Describes the decision boundary, the failure mode when runner is used where worker is intended, and the safe composition pattern.

2026-06-180

local-only-repos

joshrotenberg/agent-tools

When a repo has no GitHub remote (or is not yet a git repo) -- use this to route survey, sweep, and dispatch off the GitHub-centric path. Detect with `git remote` empty; treat blank GitHub columns as expected, not an error; route work to commits + CLAUDE.md instead of issues + PRs; degrade a maintenance sweep to the local-only axes.

2026-06-180

maintenance-sweep

joshrotenberg/agent-tools

When the directive is "status check," "what's new across my projects," or "sweep maintenance" -- run a per-project, read-mostly, non-PR sweep. For each project under the owner-prefixed layout, gather stars/forks, open issues/PRs split into mine vs community vs bots, package downloads, release-due (unreleased conventional commits), a test run, a stale-CLAUDE.md flag, and branch-cleanup candidates. Emit a fresh per-project report every sweep; NEVER cache status back into a workspace/manager CLAUDE.md.

2026-06-180

triage

joshrotenberg/agent-tools

When the issue or PR queue has open unlabeled items -- run a read-only triage pass that labels each one by component, category, priority, and size, flags duplicates, closes noise, and reports the p1 queue before runners are dispatched.

2026-06-180

github-authoring

joshrotenberg/agent-tools

When writing any issue, PR, or commit message, use this for the authoring standard. Covers structure (headings, lists, tables, fenced blocks, the bug block, the before/after) and voice (factual, no emdashes, no editorializing labels, conventional-commit prefixes, no commit trailers).

2026-06-180

workspace-layout

joshrotenberg/agent-tools

The canonical owner-prefixed workspace layout. Every repo lives at ~/Code/<host>/<owner>/<repo> -- no active/ or language segment. Enumerate with `ls ~/Code/github.com/*/*`; resolve siblings by path arithmetic. The manager (workspace-root) CLAUDE.md is a map of where things are and how to read them, never a cache of per-project inventory or status. Load this whenever a session reasons about where a repo lives, walks the workspace, or resolves one project from another.

2026-06-180

name	git-branch-pr-workflow
description	Before making any non-trivial code, docs, or config change -- create a feature branch first, then open a PR. Never commit directly to main. Apply by default before any edit; this is the baseline branch discipline that all other git skills build on.
allowed-tools	Bash(git ) Bash(gh )

Git branch + PR workflow

When to apply

Any code change beyond a trivial typo
Any docs change that affects committed content
Any config or workflow change

Why

Keeps the commit log on main clean and bisectable
CI runs against the PR before main moves
Squash-merge gives main a clean linear history
Even solo, the PR body is a useful place to record the "why"

How to apply

Before any change, git checkout -b <type>/<short-description>.
Make commits with conventional-commit messages (<type>: <description>; ! marks breaking).
Push: git push -u origin <branch>.
Open the PR: gh pr create [--draft] with a tight body that references the underlying issue (use a Closes #N keyword in the PR body so the merge closes the linked issue).
Wait for CI; merge with gh pr merge --squash --delete-branch.

Commit-message conventions

feat: ... -- new user-visible behavior
fix: ... -- bug fix
refactor: ... -- internal restructuring, no behavior change
chore: ... -- repo maintenance (dependencies, config, etc.)
ci: ... -- CI/release-process changes
docs: ... -- documentation only
test: ... -- tests only

Append ! to mark a breaking change: refactor!: cut --head and --tail (closes #42).

No trailers, author is the repo owner

git log -1 --format='%an <%ae>%n%(trailers)'

The author line must be the repo owner and the trailers must be empty. If a trailer slipped in, amend it out (git commit --amend) before pushing.

git-fix-pr-branching -- how to handle fixes when a PR is open vs merged.
heredoc-backticks -- formatting the PR body without breaking the markdown.