The biggest change in how I ship this year was not a tool. It was a rule: one task, one pull request, and nothing else rides along. It sounds slow. It is the fastest I have ever moved.
One task, one PR
A pull request is a promise that one thing changed. When a branch carries a refactor, a new feature and a drive-by fix, review turns into archaeology. When it carries one thing, review takes minutes and a revert is a single click.
If I can’t describe the PR in one line, it is two PRs.
How small is small
I aim for diffs a reviewer can read in one sitting, usually under 300 changed lines. Bigger work gets a short plan first, split into tasks that each fit in one PR.
- Write the goal in one sentence.
- List the acceptance criteria as checkboxes.
- Cut the list until each part can merge on its own.
The checklist
Before I open a pull request, the same script runs every time. If it fails, the PR waits.
// one command, the same gate for people and agents
"check": "pnpm typecheck && pnpm lint && pnpm test && pnpm build"- Done: The title is one Conventional Commit line
- Done: Checks pass locally
- Done: It works at 390px wide
- Not done: Screenshots only if the change is visual
When agents write the code
Small PRs matter even more when an agent writes them. A narrow task keeps the agent on track, and a short diff is something I can actually review. I keep the rules in one file, AGENTS.md, so every agent reads the same playbook.
What goes in AGENTS.md?
The stack, the never-list, which skill to use for which task, and the checks that must pass before saying done. Short enough to read in a minute.
None of this is new. It is just gardening: plant small, tend often, and pull the weeds before they spread. The same rule keeps BakerMind growing.