How I Use Claude Code to Ship a PR Every Hour

I don’t actually ship a PR every sixty minutes on the dot. But most days, I have something ready to merge about that often. The trick isn’t working faster — it’s structuring work so that multiple things are always in flight.

This is the workflow.

The bottleneck isn’t Claude — it’s you

Claude Code is fast. It can scaffold a feature, write tests, refactor a module, or fix a bug in minutes. But left to the default workflow — one terminal, one task at a time — you become the bottleneck.

You give Claude a task. It works. It asks for approval. You approve. It works more. It finishes. You review. You give it the next task. Repeat.

This is fine for simple things. But for any real workload, you’re spending half your time waiting and the other half context-switching. The throughput ceiling is one task at a time, gated by your review speed.

Pipeline your work like a factory

The solution is the same one manufacturing figured out a century ago: pipelining.

Instead of one task flowing through all stages sequentially, you have multiple tasks at different stages simultaneously. While one PR is in review, another is being coded, and a third is being planned. Your job shifts from “do each thing” to “keep the pipeline moving.”

For Claude Code, this means running multiple sessions in parallel, each working on a different task, each at a different stage of completion.

My daily setup

Every morning I look at the backlog and pick 3-5 tasks that are small enough to be a single PR. Good candidates:

  • Add a new API endpoint
  • Write missing tests for an existing module
  • Refactor a component to use a new pattern
  • Fix a reported bug
  • Update dependencies and verify nothing breaks

The key constraint: each task should be independently mergeable. No task depends on another task’s output. If they do depend on each other, they need to be sequenced in the same session, not parallelized.

I open Crystl, create an isolated shard for each task, and give each one clear instructions. Each isolated shard runs on its own git branch via a worktree, so the tasks genuinely can’t interfere with each other.

The rotation

Once all shards are running, I rotate between them based on what needs attention.

Starting a shard: Give Claude a clear prompt — what to build, what the acceptance criteria are, what files to touch and not touch. Then move on.

Checking in: When Crystl’s notifications tell me a shard needs attention (an approval, a question, or a completed task), I switch to it. The Crystal Rail makes this a single click.

Reviewing output: When a shard finishes, I review the changes. If they look good, I create the PR. If something needs adjustment, I give Claude the feedback and move to the next shard that needs attention.

Keeping the pipeline full: When a shard’s task is done and merged, I give it a new task. The goal is to never have all shards idle at the same time.

On a typical morning, I start 4 shards at 9:00. By noon I’ve merged 3-4 PRs and have 2-3 more in progress. The rhythm is: start tasks, respond to notifications, review completed work, refill the pipeline.

Why small PRs matter here

This workflow only works if each PR is small. A 50-line PR takes two minutes to review. A 500-line PR takes twenty. If your PRs are large, you can’t maintain the rotation — review time becomes the bottleneck and the pipeline stalls.

I aim for PRs under 200 lines of meaningful changes. If Claude’s output is bigger than that, the task was scoped too broadly. Split it.

Small PRs also merge cleaner. When you have 4 branches in flight, merge conflicts are inevitable if the branches are large. Small, focused branches rarely conflict.

The approval workflow

One thing that makes this practical in Crystl: approval modes.

I run most shards in a mode where Claude can read files and run tests without asking, but needs approval for file writes and shell commands. This means a shard can do its analysis and planning autonomously, then ping me only when it’s ready to make changes.

For trusted tasks — like writing tests for an existing module — I’ll use a more permissive approval mode so Claude can work start to finish without interruption. I review the output when it’s done rather than approving each step.

This flexibility is what keeps the pipeline moving. If every shard needed step-by-step approval, the rotation would be too slow to maintain.

What this actually produces

In a typical week using this workflow:

  • 15-20 PRs merged (versus 5-8 with the sequential approach)
  • Each PR is focused and reviewable — not a mega-PR that nobody wants to look at
  • Fewer merge conflicts because branches are short-lived
  • Better git history because each commit represents one logical change

The quality doesn’t suffer because each PR still gets human review. I’m not blindly merging Claude’s output. I’m reviewing it faster because there’s less to review per PR.

When this doesn’t work

This workflow assumes your tasks are parallelizable. If you’re building one feature with sequential steps — schema, then API, then UI — you can’t split those across branches. It also assumes you can context-switch quickly. Crystl helps here because each shard maintains its conversation context, so re-orienting is a glance at the last few messages rather than re-reading the whole branch.

Try it for a day

Pick a day when you have several independent tasks. Set up 3-4 isolated shards, give each one a task, and practice the rotation. The first hour will feel chaotic. By afternoon, it’ll feel like the only sane way to work.

Crystl is free — sign up at crystl.dev/login.