Sign in Subscribe

Shipping a Week's Work in a Day using Claude Code

Akash Joshi

• 5 min read
Shipping a Week's Work in a Day using Claude Code

You're staring at a Jira board. Five tickets in "To Do", all from the same epic, all due this sprint. You know the drill - pick one, context-switch, pick another, context-switch, repeat until Friday. Maybe you'll get through three of them.

What if you could ship all five today?

I did exactly this a few weeks ago. An entire signup epic - password validation, consent flows, plan selection, login links, UX polish - delivered in a single day instead of the week it would've taken sequentially. The trick was to work in parallel.

The idea is simple: run multiple Claude Code sessions simultaneously, each in its own git worktree, each tackling a different ticket, with you multiplexing between them to review and approve commits.

The three foundations

This workflow rests on three things:

  1. Git worktrees for filesystem isolation. Each agent gets its own copy of the repo. No branch-switching, no stashing, no conflicts while you're mid-flow.
  2. CLAUDE.md for structured output. Your repo's CLAUDE.md (or AGENTS.md) enforces coding standards, plan formats, and TDD discipline. Every agent produces consistent, reviewable output because the rules are baked into every session.
  3. Human-in-the-loop approval. Agents stop after every commit and wait for you. This is not fire-and-forget. You're the bottleneck by design, and that's the point.

When this works (and when it doesn't)

Use this when:

  • You have 2+ tickets from the same epic that can be worked on concurrently
  • The tickets touch different functional areas with low file overlap
  • You've scoped the tickets with your team and understand the requirements
  • Your repo has a CLAUDE.md that enforces coding standards
  • You have time to supervise

Don't use this when:

  • Tickets have heavy interdependencies or all modify the same files
  • Requirements are still unclear and need exploration
  • One ticket's output is a prerequisite for another

The workflow

Phase 1: Dependency analysis

Start from your epic or sprint board. Ask Claude to analyse which tickets can be parallelised by checking for different functional areas, low file overlap, and independent concerns that won't cause merge conflicts.

The output is a parallelisation map. Here's roughly what mine looked like:

  • Agent 1 - Password validation, auto-login, redirect (low conflict risk)
  • Agent 2 - Consent checkboxes, marketing API, locale-based age check (medium conflict risk with Agent 1)
  • Agent 3 - Plan selector with free/pro toggle and API call (low conflict risk)
  • Agent 4 - "Already have an account?" login link (very low conflict risk)
  • After all merge - UX polish: errors, focus states, button states (sequence last)

That last one is important. Cross-cutting UX tickets touch the same components as every other ticket. They go last, always.

Phase 2: Worktree creation

For each parallelisable ticket, spin up an isolated environment:

git worktree add <ticket-id>       # creates worktree and branch
cd <ticket-id>
code .                              # open in a separate IDE window
claude --dangerously-skip-permissions   # start a Claude session

You now have multiple IDE windows open, each with its own Claude session, each working on a different ticket.

Phase 3: Planning

The first thing you ask each Claude session to do is create a plan. The plan file gets saved as <ticket-id>-plan.md at the worktree root and serves as a living to-do list across sessions.

A good plan has:

  • A Context section explaining what exists and what's missing
  • Changes grouped as self-contained commits
  • Tests in the same commit as the code they test
  • Explicit file paths and function names, not vague descriptions
  • References to existing code to reuse
  • A STOP message after every commit

Here's a real example - the first two commits from one of my plans:

## Context

The signup page was scaffolded but is missing three functional requirements
that the legacy form already implements: password validation, auto-login
after signup, and post-signup redirect.

## Plan

### ⬜ Commit 1: Add password validation

**Tests (red phase):**
- Submitting with password < 8 chars shows error, does NOT call createAccount
- Submitting with control characters shows error
- Typing in password field clears error

**Implementation:**
- Import validateCharacters from existing validation helper
- Add passwordError state (same pattern as emailError)
- In handleSubmit, add length + character checks

STOP after this commit. Wait for review.

---

### ⬜ Commit 2: Pass auto-login parameters to createAccount

**Tests (red phase):**
- Assert createAccount is called with { email, password, login: true,
  keepLogin: true, locale: 'en' }

**Implementation:**
- Add useAppSelector to get interface language
- Update createAccount call to include login and locale params

STOP after this commit. Wait for review.

The format scales. Six commits for a complex ticket, one commit for a focused one.

Phase 4: Execution

Each agent works through commits one at a time:

  1. Writes failing tests (red phase)
  2. Implements code to pass tests (green phase)
  3. Runs the verification command
  4. Marks the commit as ✅ in the plan file
  5. Stops and waits for you

Meanwhile, you're cycling between IDE windows, reviewing diffs from whichever agent has finished a commit. This is where the parallelism pays off - while one agent is running tests and writing code, you're reviewing another agent's output.

You commit manually. Agents never commit on their own. Here's the real commit history from one of the tickets:

6b86ed1 feat: add password validation
3a2fb41 feat: pass autologin params to createAccount
fcd9f4a feat: add redirect after signup
c269e78 feat: save email to session storage for bot protection
c8e5082 feat: add comprehensive server error handling
f405498 feat: add tracking for signup success

Clean, atomic, reviewable. Each commit does one thing.

Phase 5: Merge and cleanup

Once a plan is fully executed, push the branch and open a merge request. Merge in order of dependency - lowest conflict risk first. If two branches touched the same file, merge one, then rebase the other and resolve conflicts.

Clean up after yourself:

git worktree remove <ticket-id>

The secret ingredient: CLAUDE.md

You might be reading this thinking "the workflow is straightforward enough." And you're right. The hard part isn't the process - it's the consistency.

Without a well-crafted CLAUDE.md, each agent will do its own thing. One will skip tests. Another will blast through three commits without stopping. A third will write code that doesn't match your project's patterns.

The critical bits your CLAUDE.md needs:

  • Plan format - commit groups with status indicators, brief requirements, red/green/verification phases, stop messages
  • TDD enforcement - tests before implementation, within the same commit
  • Stop-and-wait protocol - the agent must not proceed to the next commit without your approval
  • Code style rules - naming conventions, patterns to reuse, things to avoid

Think of it as onboarding documentation for a very fast, very literal junior developer. The more specific you are, the better the output.

Tips from the trenches

  • Always scope tickets with your team before parallelising. Don't assume tickets are independent just because Jira has no blocking links.
  • Start with two agents, not five. The review bottleneck is real. Once you're comfortable context-switching between two, add a third.
  • Use --dangerously-skip-permissions only in worktrees you're actively supervising. Don't leave unattended sessions running with this flag.
  • Cross-cutting tickets go last. If a ticket touches every component the other tickets are modifying, sequence it after everything else merges.
  • The plan file is your recovery point. If a session crashes or you need to pick up tomorrow, the ✅/⬜ markers tell you and Claude exactly where you left off.

Is this for everyone?

No. This workflow requires you to already be comfortable with Claude Code, git worktrees, and TDD. It requires tickets that are well-scoped and genuinely independent. And it requires your active attention - you're not delegating work, you're multiplexing it.

But if those conditions are met, the throughput is remarkable. A week of sequential work compressed into a day, with the same code quality and test coverage you'd expect from doing it manually.

Try it with two tickets first. See how it feels, and let me know by tweeting at me at x.com/thewritingdev