One Goal per Pull Request

Use this principle to make pull-request boundaries express reviewable outcomes rather than implementation convenience. A goal is one coherent product or engineering outcome; it may require several tasks, commits, tests, generated files, or documentation changes.

Activate when

Activate when any of these is true:

• a plan is assigning goals or tasks to tickets, worktrees, branches, or pull requests;
• a proposed pull request contains more than one outcome;
• shared files, ordering, or an intermediate state are being used to justify combining work; or
• implementation discovers pressure to split or combine an approved pull-request group.

Decision rule

Give every independently reviewable goal its own ticket, worktree, branch, and pull request; combine goals only when the approved plan records why separation would be unsafe or would not create a meaningful review boundary, and never change approved grouping silently.

Apply the rule