Four cities built at the same time by four Claude Code sessions, and not one merge conflict
Toyama's masu press, Kanazawa's morning catch, Sapporo's seasons and Fukuoka's night-stall rushes were each built by a separate Claude Code session in parallel, touching only their own folder. One more session put them together. Our sushi chain now plays from Tokyo to the credits in about 3.5 hours. Part 9.
What we asked“Build Fukuoka as a city of the Neta chain, following CITIES.md. Fukuoka is the sixth and last stop, so reaching its goal rolls the credits: a Hakata night stall (yatai) by the Naka river with red lanterns, and goma-saba (mackerel in sesame sauce); its twist should come from the night stall: quiet stretches broken by rushes of guests. It must be a different place from Tokyo and Osaka, with its own floor plan, local fish, guests, music and look. Four cities are being built by separate sessions at the same time, so put everything in src/cities/fukuoka/ and do not change shared files; if a shared change is truly needed, describe it in your report instead. Balance it with npm run campaign -- --city fukuoka.”
What happened
- Four sessions started at the same minute, each with its own copy of the game: Toyama, Kanazawa, Sapporo and Fukuoka (above is Fukuoka's prompt; the others differ only in the city and its twist)
- Each built its city's room, local fish, guests, flavour classics, twist and music in its own folder, and balanced it with the campaign bots
- We diffed each copy against the original: only the city's own folder had changed, in all four
- We copied the four folders into one game and gave a fifth session all four reports
In part 8 every city of Neta became one folder, found automatically. This part tests that idea: four Claude Code sessions built the last four cities at the same time, then a fifth put them together. Neta now plays from Tokyo to the credits.
Play Fukuoka, the last stop
This opens straight in Fukuoka as if you had come along the whole route. Reaching its goal rolls the credits. Play the whole chain from Tokyo (saves your game).
1. Six places
Tokyo and Osaka from part 8, and the four new cities, each by a different session:
| City | Its twist | Session |
|---|---|---|
| Toyama | The masu press: press a round of 8 or 16 wedges at once. Fresh wedges sell for ×1.3, and the round goes stale after 90 seconds. | 43 min, $6.16 |
| Kanazawa | The morning catch: three fish a day with limited portions, selling for ×1.8 to ×4 until they run out. | 34 min, $5.99 |
| Sapporo | Four seasons; fish in season sell for ×2.5. | 33 min, $5.24 |
| Fukuoka | A night stall: quiet stretches, then rushes of guests. The cook fills a READY tray in the quiet. | 51 min, $7.69 |
Each brought its own local fish, guests, music and classic dishes: masu-zushi in Toyama, kaburazushi in Kanazawa, Rishiri uni gunkan in Sapporo and goma-saba in Fukuoka.
2. Zero shared files changed
Each session got its own copy of the game and the rule "put everything in your folder and do not change shared files; if a shared change is truly needed, describe it in your report instead". After they finished, we diffed each copy against the original: in all four, only the city's own folder had changed.
What kept them inside their folders was a written contract: every file a city has, every field it registers, and hooks for anything a city might change (the floor plan, the way guests are served, the music). And one command, npm run campaign -- --city <id>, that lets bots play the route up to and through one city, so each session could balance its city alone.
3. What the reports asked for
All four sessions ran into things the contract couldn't do, and wrote them down instead of editing shared code. Several found the same gaps:
- Local fish drawn as salmon. Three cities had no way to add art for a new fish, so king crab, buri and mackerel all looked like salmon.
- No real names. Toyama's classic was called "BRIGHT VINEGARED CHERRY SALMON PRESSED WITH BAMBOO LEAF" instead of masu-zushi.
- A ghost pin. The shared route called Sapporo
sapporo, but the city's folder ishokkaido, so the map drew a second pin. - A wrong price label that always showed ×1.3 for a city's signature dish.
- Possible id clashes. Two cities choosing the same card id would clash silently.
- Balance against the wrong neighbour. Each city was tuned to follow Osaka, because the cities between didn't exist yet.
4. One session to put it together
We copied the four folders into one game and gave a fifth session the four reports. It added the missing hooks (local art for 31 cards, real dish names, an arrivals hook for Fukuoka's rushes), fixed the pin and the label, and added a duplicate-id check, which found three clashes. Then it re-balanced the whole route and played it in a browser from Tokyo's tutorial to the credits.
| City | Median time to its goal |
|---|---|
| Tokyo | 37:05 |
| Osaka | 37:42 |
| Toyama | 37:30 |
| Kanazawa | 39:27 |
| Sapporo | 37:58 |
| Fukuoka | 41:39 |
| The whole route | 3:46 (all 8 bot seeds reach the credits) |
What it cost
Four city sessions, $25.08 together and 51 minutes of wall time (the slowest, Fukuoka), plus $8.27 to combine them: $33.35 for four cities. Run one after another, the same sessions would have taken almost three hours.
Still weak: a full run varies a lot, from 2:36 to 5:10 depending on what you invent early; a city still can't score its own sushi form, so Toyama uses the shared pressed form; and the bots don't fully account for each city's price rules.
Next: a playtest changes the core loop
The game is complete from start to end. Then someone played it and found it played like a simulation, not an incremental, so the next part rebuilds the loop around numbers.
Build your game in parallel
- Copy the skill below into
.claude/skills/parallel-content/, or download it. - Build the shared systems and one or two examples first, then write the contract from real code.
- Start one session per piece, each told to touch only its folder. Diff the copies, then give all the reports to one session to combine.
The skill that made it work
This is the method, written up as a skill after the fact: how to set a game up so content can be built by parallel sessions. You can also read the real contract the four sessions followed. Copy the rules below, or download the skill.
- One folder per piece. Everything a piece needs lives in `src/<kind>/<id>/`: its data, its art, its rules, its music, its tests. No shared file lists the pieces.
- Automatic discovery. Shared code finds the pieces at build time (`import.meta.glob` in the browser, a directory read in Node scripts and bots), so adding a folder is enough.
- Hooks, not edits. Anything a piece might need to change (a different floor plan, a different way of serving, its own art for a new ingredient, a local name) is a hook the piece registers from its folder. When a piece needs something there is no hook for, that is a shared change.
- A written contract. One document (e.g. `CITIES.md`) lists every file in a piece's folder, every field it registers and what each means, the id rules (prefix ids to avoid clashes), and one or two worked examples. Build the first examples before writing it, so it describes real code.
- A balance command per piece. A script that measures one piece in the context of the whole game (for example bots playing the route up to and through it), so each session can tune its piece alone.
- The parallel prompt. Each session gets a copy of the same game and the same skills, builds one piece, and is told: "put everything in your folder and do not change shared files; if a shared change is truly needed, describe it in your report instead."
- Check the copies. After the sessions finish, diff each copy against the original. Only its own folder should differ.
- Integrate in one session. Copy every folder into one game, give one session all the reports, and ask it to: make the shared changes the reports asked for, check for id clashes, re-balance the whole sequence (each piece was tuned without the others), merge the per-piece notes into the shared docs, and play the whole game from start to end.
- Report per piece: time, cost, whether shared files were touched, and what the integration fixed.
Save it as .claude/skills/parallel-content/SKILL.md in your project.
