A developer tripled solo dev velocity by running three parallel Claude Code instances with strict file ownership rules and a lightweight cross-instance PR system.

How to Run Parallel Claude Code Instances Without Git Conflicts

One developer just shipped what looks like a small team's output in a single day: 17 UI tabs, 39 database migrations, and 35 blog posts. Their secret? Running three Claude Code instances in parallel with military-grade file ownership rules.

The Architecture: Strict File Ownership

The core innovation isn't running multiple instances—it's preventing them from stepping on each other's toes. Each instance gets exclusive ownership of specific directories:

Instance 1 (VSCode): lib/ + supabase/functions/
Instance 2 (Windows App): docs/ + supabase/migrations/
Instance 3 (PowerShell): .github/workflows/

Hard rule: No instance touches files outside its zone. Ever. This eliminates 90% of Git conflicts before they happen.

Why This Works Better Than One Mega-Session

1. Eliminates Context Pollution

When one Claude session handles Dart, SQL, YAML, and TypeScript simultaneously, its judgment degrades. The model tries to maintain context across competing domains, leading to confused outputs. Separate instances stay razor-focused on their domain expertise.

2. Beats Context Window Limits

Long single sessions accumulate compression artifacts—early decisions get lost in token compression. Short, focused parallel sessions mean each instance starts with clean context every time.

3. Prevents Duplicate Work

Without coordination, multiple instances would implement the same feature independently. The solution? A shared state file.

The Coordination System That Makes It Work

Shared State: COMPRESSED_PROMPT_V3.md

All instances read this file at session start:

## Current Snapshot (as of Windows版#67)
- Edge Functions deployed: 15 (hard cap: ≤50)
- AI University: 54 providers in DB, 54 in UI
- LP features: 126
- Total pages: 219

## Instance Scope Table
| Instance | Owned Files |
|----------|-------------|
| VSCode   | lib/, supabase/functions/ |
| Windows  | docs/, supabase/migrations/ |
| PowerShell | .github/workflows/ |

This prevents "already implemented by another instance" duplicate work.

Cross-Instance PRs: docs/cross-instance-prs/

When one instance needs work from another, it drops a request file:

docs/cross-instance-prs/
├── 20260413_allenai_naver_provider_ui.md   # Windows → VSCode request
└── done/
    └── 20260412_groq_provider_ui.md         # completed

Example request format:

# AI University: Allen AI UI Addition (Windows#67 → VSCode)

## What to add
In `lib/pages/gemini_university_v2_page.dart`, add to `_providerMeta`:

| Key | Value |
|-----|-------|
| provider | `allen_ai` |
| name | `Allen AI (AI2)` |
| emoji | `🔬` |
| color | `Color(0xFF1565C0)` |

Migration already added: `20260413049000_seed_allenai_ai_university.sql`

The receiving instance implements the request and moves the file to done/. No Slack, no GitHub Issues, no async back-and-forth.

Memory System: ~/.claude/projects/my_web_app/memory/

Since Claude Code doesn't remember previous sessions, each instance writes to a shared memory directory:

memory/
├── MEMORY.md                     # Index, max 200 lines
├── user_instance_powershell.md   # This instance = PS版
├── project_20260413_ps55.md      # PS#55 completion state
├── feedback_success_*.md         # What worked
└── feedback_correction_*.md      # What to never do again

Session start ritual:

1. Read MEMORY.md — recent successes and corrections
2. Read COMPRESSED_PROMPT_V3.md — current state
3. Check docs/cross-instance-prs/ — pending requests

Daily Workflow in Practice

09:00 JST  Each instance starts → reads MEMORY.md + COMPRESSED_PROMPT
           ↓ Parallel work begins
VSCode     : AI university UI additions (lib/pages/)
Windows    : Migration files (supabase/migrations/)
PowerShell : Workflow fixes + blog dispatch

11:00 JST  Check cross-instance-prs
           Windows: "Allen AI migration added → requesting UI from VSCode"
           VSCode: Picks up request → implements → moves to done/

End of session:
           Each instance appends to GROWTH_STRATEGY_ROADMAP.md
           Saves success/failure patterns to memory/

CI/CD Management

The PowerShell instance owns all .github/workflows/ and enforces:

• 20 workflows, all health-checked every session
• Concurrency groups prevent deploy-prod from being cancelled mid-migration
• EF hard cap: ci.yml blocks any push that would exceed 50 deployed Edge Functions
• SQL artifact detection: blocks '"'"' bash quoting artifacts before they reach production

The Coordination Cost

This setup requires discipline:

• Strict file ownership rules — enforced by convention
• Cross-instance PR process — lightweight alternative to actual PRs
• Shared state file — needs regular maintenance
• Memory discipline — wrap-up at session end, or context is lost

The overhead is 10-15 minutes per instance per session. Worth it when each instance delivers 3-4× the output of an unfocused single session.

Try It Now

1. Define your domains: Split your codebase into logical chunks (frontend/backend/docs/CI)
2. Create COMPRESSED_PROMPT_V3.md: Include current state and instance ownership table
3. Set up cross-instance-prs/ directory: Simple markdown files for requests
4. Establish memory directory: Shared location for session recall
5. Launch separate instances: Each with its own terminal/IDE, each focused on its domain

The key insight: Claude is better at narrow, well-defined tasks than broad ones. Role separation makes that explicit.

---

Originally published on gentic.news