# Keep agent PRs small: one concern per branch

> A developer's setup from r/ExperiencedDevs: the agent plans a feature into small chunks, writes the approved plan to the repo, and ships one stacked PR per concern.

- **Category:** [Coding](https://stepgleam.com/categories/coding)
- **Difficulty:** Advanced
- **Time:** ~40 minutes
- **Tools:** Claude Code, Git, GitHub, Cursor
- **Reliability score:** 70/100
- **Steps:** 4
- **Last updated:** 2026-10-26
- **Published:** 2026-10-26

## Tools used

- [Claude Code](https://code.claude.com/docs) — Coding agent that reads, edits and tests the repo
- [Git](https://git-scm.com) — Checkpoints and small commits
- [GitHub](https://github.com) — Pull requests and CI
- [Cursor](https://cursor.com/docs) — Editor agent with Plan Mode

## What you'll get

A feature delivered as a short stack of small PRs that each take minutes to review, instead of one 40-file monster.

## Who this is for

Developers who already use an agent for features and struggle to review its output.

## Before you start

Coding agents tend to dump schema, business logic and route handlers into one giant diff. One developer on r/ExperiencedDevs described the workflow shift that fixed this for them: plan in chunks, save the plan in the repo, and ship one branch per concern as stacked PRs. Cursor's own docs recommend small, semantic commits for the same reason.

## Steps

### Step 1: Ask the agent to plan the feature as ordered chunks

**Tool:** Claude Code

In plan mode, ask for the feature split into ordered chunks, one concern each. In the source post's FastAPI example: 1) schema and migrations only, 2) request/response schemas, 3) business logic only, 4) HTTP route handlers only.

**Why this works:** Each chunk becomes a diff with one story, which a reviewer can follow.

**Prompt:**

```
Plan this feature as an ordered list of chunks where each chunk touches one concern only (for example schema, validators, service layer, routes). For each chunk give a branch name and the files it will touch.
```

[Open step 1](https://stepgleam.com/guides/keep-agent-prs-small-one-concern-per-branch#step-1)

### Step 2: Write the approved plan to a file in the repo

**Tool:** Claude Code

Once you approve the plan, have the agent write it to `FEATURE_PLAN.md` in the repo. The author does this so the agent *"can remember it throughout and across sessions without any context drift."*

**Why this works:** A file survives context resets; a chat message does not.

**Prompt:**

```
Write the approved plan to FEATURE_PLAN.md with the chunk order, branch names and what each branch contains.
```

[Open step 2](https://stepgleam.com/guides/keep-agent-prs-small-one-concern-per-branch#step-2)

### Step 3: Execute one chunk per branch, each stacked on its parent

**Tool:** Git

Run one chunk at a time: one branch, one concern, one PR. Each branch is stacked on the previous chunk and targets its immediate parent, not main. The author lets the agent manage the stacking with the Git Town tool.

**Why this works:** Stacking lets later chunks build on earlier ones without waiting for merges.

[Open step 3](https://stepgleam.com/guides/keep-agent-prs-small-one-concern-per-branch#step-3)

### Step 4: Review and merge in order

**Tool:** GitHub

Review PR 1 (for example just the schema, about five minutes), then PR 2, and so on, merging in the same order. If you would rather not stack, Cursor's docs suggest a lighter version: build freely, then ask the agent to rework the history into small semantic commits before review.

**Why this works:** Small, ordered reviews replace one exhausting review of a giant diff.

[Open step 4](https://stepgleam.com/guides/keep-agent-prs-small-one-concern-per-branch#step-4)

## Pro tips

- Use this for multi-layer features; for a one-file fix it is overhead.
- Keep FEATURE_PLAN.md updated if a chunk changes scope.

## Common mistakes

- Letting a chunk touch two concerns "because it was easy".
- Targeting every stacked PR at main, which re-shows the earlier chunks in every diff.

## FAQ

### Do I need Git Town?

No. The author used it to let the agent handle stacking. Plain git branches based on each other work too, just with more manual rebasing.

---

Canonical guide: https://stepgleam.com/guides/keep-agent-prs-small-one-concern-per-branch
Read this guide as Markdown: https://stepgleam.com/guides/keep-agent-prs-small-one-concern-per-branch.md