How I used Claude Code + gstack to scaffold Miniworld's Move packages and get from zero to demo project in 1.5 hours

Sui Move smart contracts + React frontend + Node.js crank + Walrus snapshots = a persistent on-chain world that evolves itself every 60 seconds

tl;dr

I built the Miniworld MVP from scratch in 1.5 hours using gstack.

Miniworld is a base-layer world-building protocol on Sui. Sui holds the authoritative world state, Walrus holds all world data.

The Stage 1 Miniworld MVP delivers a 32x32 tile grid on Sui testnet where users place tiles via a simple UI, world pulses evolve the state via Game of Life rules, and Walrus stores snapshots for timeline replay.

Architecture

Layer 0: World Model

World (shared object) + Tile (vector<Option<Tile>>) + PulseCap (capability)

Layer 1: Rules

Game of Life (B3/S23, toroidal wrapping, inlined in world.move)

Layer 2: Crank

Node.js script: pulse execution + Walrus snapshot + manifest management

Layer 3: Frontend

React + @mysten/dapp-kit: grid renderer, tile placement, timeline replay

Getting going with gstack

Installation was easy enough: in my template project, I started Claude and pasted the following (all of it, since it’s a Claude command) as per the gstack github repo, being sure to grant Claude permission for git add and git commit.

Install gstack: run git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup then add a "gstack" section to CLAUDE.md that says to use the /browse skill from gstack for all web browsing, never use mcp__claude-in-chrome__* tools, and lists the available skills: /office-hours, /plan-ceo-review, /plan-eng-review, /plan-design-review, /design-consultation, /design-shotgun, /design-html, /review, /ship, /land-and-deploy, /canary, /benchmark, /browse, /connect-chrome, /qa, /qa-only, /design-review, /setup-browser-cookies, /setup-deploy, /retro, /investigate, /document-release, /codex, /cso, /autoplan, /careful, /freeze, /guard, /unfreeze, /gstack-upgrade, /learn. Then ask the user if they also want to add gstack to the current project so teammates get it.

And Claude replied:

⏺ Committed. Your teammates will now get the gstack configuration when they pull.

---

Step 1: /office-hours (25 minutes)

Start here.

Tell Claude what you want to build and then follow up with /office-hours to kick off the “office-hours” skill, where Claude will challenge your input and help to refine the product definition. You’ll be asked a number of setup questions, you can pick whatever you like here.

I told Claude Code I wanted to build the Miniworld MVP, and pasted the pitch text I had previously written for Walrus.

My honest review

Some of the questions were painfully annoying and thoroughly challenged my thesis. However, at the end, I was offered 3 approaches for my build and a recommendation.

     **APPROACH A: "Living Grid" (Minimal Viable)**                                                               
     - Summary: 16x16 tile grid on Sui testnet. Place tiles, watch pulses evolve the world (Game of Life-style    
     rules). Walrus stores snapshots for timeline scrubbing. One page, one world, one rule.                       
     - Effort: S (2-3 weeks)
     - Risk: Low
     - Pros: Ships fast, communicates thesis in one URL, perfect grant demo, validates Sui+Walrus pipeline      
     end-to-end                                                                            
     - Cons: May feel too simple to attract serious builders, limited discovery/exploration loop
     - Reuses: Existing React scaffold, @mysten/dapp-kit
     - Completeness: 6/10
                                               
     **APPROACH B: "Explorer" (Ideal Architecture)**                                                              
     - Summary: Full discovery-consequence loop. Procedurally revealed regions, discovery minting, artifact      
     publishing to Walrus, daily pulses that evolve the world. Multiple rule modules. Agent interface stubbed. 
     Walrus World Site explorer for browsing worlds.   
     - Effort: L (8-12 weeks, matches your M1-M2 milestones)  
     - Risk: Medium (scope creep, may not ship before grant review)                                     
     - Pros: Demonstrates the full protocol vision, compelling standalone game, strong starter kit foundation
     - Cons: Long timeline, many moving parts, risk of shipping nothing impressive quickly
     - Reuses: Existing scaffold + full protocol layer
     - Completeness: 9/10
                                           
     **APPROACH C: "Grid-to-Explorer" (Staged)**                                                            
     - Summary: Ship Approach A in 2-3 weeks as the grant proof-of-concept. Then layer on exploration, discovery  
     minting, and richer rules incrementally. Each stage is playable and deployable. The grid evolves into the 
     explorer without rewriting.                          
     - Effort: M to L (2-3 weeks for stage 1, then incremental)
     - Risk: Low-Medium (always have something to show)                                                     
     - Pros: Fast first demo, always shippable, incremental validation, matches milestone structure (M1→M2→M3→M4)
     - Cons: Architecture must be designed for growth from day 1 (slightly more upfront design than A)
     - Reuses: Everything from A, extends naturally
     - Completeness: 8/10

I chose Approach C (recommended): ship the Living Grid fast, then layer on exploration incrementally. I will always have something to show and this architecture supports growth without rewriting.

Step 1 wrote the design doc, located at:

~/.gstack/projects/<project>/<main-design-doc>.md)

It covers: problem statement, demand evidence, status quo, target user, premises (including revised premise #5), cross-model perspective, all 3 approaches, the recommended Grid-to-Explorer staged approach with 4 stages mapped to grant milestones, protocol architecture, security model, failure modes, open questions, success criteria, distribution plan, and the assignment.

And asked me to approve it, which I did.

Finally, Handoff, during which I was asked if I would consider applying to YCombinator. Of course, I replied yes.

(I know it’s automated, but thanks for the support GStack!)

Step 2: /plan-eng-review (61 minutes)

Now, if you’re already familiar with the steps listed on gstack’s github, you’ll be asking “why /plan-eng-review already, what happened to /plan-ceo-review?”.

Here’s what: Claude made a judgement call.

I provided very detailed input in step 1 already, so I’m going to skip /plan-ceo-review for now.

The engineering review stage took a bit longer than step 1. But not by much!

Side note: I enjoyed watching Claude congratulating itself for improvements made.

I was asked to confirm some configuration settings in the MVP, and I also granted various permissions for alternative reviews from other AI agents, eg “outside voice”.

The outside voice critiqued the plan, including things like variable types, and significantly improved a number of assumptions in the engineering proposal. That same outside voice caught a vector-over-Table architecture issue, which was the biggest win of the session. It also alerted me to a number of areas for me to manually make note of and check later such as app security / hardening.

Importantly, outside voice raised that 16x16 is too small for interesting Game of Life behaviour; most random states stabilize in 20-50 generations, meaning users would place tiles, watch the grid go static in under 2 minutes, and leave. We bumped to 32x32 (1024 cells). This still fits the vector architecture easily, gives room for gliders, guns, and emergent complexity. CSS Grid still works at 16px per cell (512px total).

When the engineering review is completed, I was prompted to approve the plan. Then, Claude immediately progressed to implementing Phase 1 (scaffolding) and Phase 2 (Move contracts) - the critical path.

My honest review

Claude automatically added files and committed them during step 1, however during step 2 I noted that nothing was committed until I asked. I was annoyed about this part - like many devs, I like code / functionality to be committed in small logical increments - so I need to provide feedback about this to my Claude, since I don’t want all files to be included in just 1 large commit at the end of an implementation process.

6 commits in total today. 1,331 lines of code in two main commits. Ideally, this would have been split into smaller chunks…

I also confirmed that Claude will only push to github when I specifically request it - this is by design.

This step took an hour, but probably could have taken less time if I’d responded to some of the approval requests more rapidly.

By the end of step 2:

• Eng review with 4 architecture decisions (~29 min)

• Outside voice that caught the vector-vs-Table issue (and grid-size issue, as described above)

• Full Move contract implementation + 9 passing tests

• Crank script with Walrus integration - pulses fire every 60 seconds, snapshots written to Walrus after each evolution

• Complete frontend rewrite (5 new files, 2 deleted, 4 modified)

• TypeScript compiles, Vite builds, dev server runs

• The outside voice also flagged a number of areas to manually revisit later, including app security and hardening. These are noted TODOs before mainnet; for the testnet MVP demo they're acceptable known gaps.

1,331 lines of working code in an hour. Not bad for a greenfield protocol.

Step 3: /review (8 minutes)

I ran this one with minimal input needed from me - I had an appointment to get to, and the process didn't require much engagement anyway. The whole review only took 8 minutes from /review start to fixes committed. That covered a 1,666-line diff, structured critical pass, adversarial subagent that found a showstopper bug, and 5 fixes applied.

At this point, the next steps look like:

1. Deploy the Move package to testnet: cd move/miniworld && sui client publish --gas-budget 100000000

2. Call create_world to get the World object ID

3. Update the constants needed by the frontend with the real IDs

Prior to installing gstack I had already set up a testnet wallet with 1 SUI, so I don’t need to provide any further information to be able to ship.

My honest review

I don’t have much to say about this step, other than I feel like it would be great to get some more visibility on the steps to ship before I needed to ask how it looks and whether I would need to provide anything.

Step 4: /ship (90 seconds)

Interestingly, /ship is for creating PRs from feature branches. It’s not what I need for deploying, since I was on main and I needed to deploy to testnet, which is a Sui operation not a git operation. So I technically didn’t need /ship at all. Still, I typed /ship deploy to testnet and Claude went ahead and automatically sorted the deployment out for me.

Note that I also skipped /qa, because the Move contracts must be deployed before they or the frontend can be tested.

In summary, after a mere 90 seconds to deploy I’ve now got a simple frontend demo for Miniworld that actually works.

Before placing a tile

After placing tile

What next for Miniworld?

This is only the first stage of my roadmap for Miniworld. I’ve completed what I originally estimated to be ~4 weeks of work in about 1.5 hours. I didn’t even really need to look at the design doc, and I’ve got a solid basis for building the rest of my product.

The full Miniworld roadmap covers the following aspects:

1. Living Grid - done ✅

2. Discovery Layer - coming up 👷

3. Snapshots, Replays, Agents - coming up 👷

4. Explorer and Adoption - coming up 👷

Next up with gstack

As you can tell, I’ve not used a lot of the prompts listed in gstack’s readme, because they don’t really need to be applied to my MVP demo, but I’ll be using them as I continue to work on Miniworld. Stage 2 adds the Discovery Layer: procedurally revealed regions, on-chain discovery minting, and richer rule modules. The grid becomes explorable rather than just observable. I'll be documenting that build the same way - with the same honest account of where gstack helps and where it doesn't.