Branches and Pull Requests

One branch per task, an issue first, and a person merges.

Start with an issue

Open a GitHub issue before starting work. State the problem and why it matters before the proposed fix: an issue that only describes a solution cannot be argued with. For work that spans several pull requests, open one umbrella issue and attach sub-issues to it.

One branch per task

Cut claude/<short-task-name> (or your own prefix) from the integration branch, do the work there, and open a pull request back into it. Nobody commits to a shared branch.

Sharing a branch has cost real time here: a one-line pull request that silently grew to 92 lines, a six-file conflict between two people’s work, and a deploy branch deleted from under someone mid-task.

A person merges

The author gives the pull request link to the requester. Review comments are answered, each one acted on or declined with a reason.

Deploy branches

Some branches deploy to live sites the moment they move. Treat a merge into one as a release. Which branch deploys which site is recorded in each repository’s AGENTS.md, and is read from the hosting platform, not from memory, before anyone is told a change is live.