--- title: "gstack, CLAUDE.md, and founder coordination" description: "gstack formalizes role-based agent work. The harder part is still product rules, cross-session context, and isolated branches." canonical: https://prasad.tech/blog/gstack-solo-builder.html source: html generated_at: 2026-05-26T13:56:27.812Z --- [Home](/) / [Blog](/blog/) / Solo builder OS Mar 2026 13 min read Solo builder OS # gstack, CLAUDE.md, and founder coordination gstack formalizes role-based agent work. The harder part is still product rules, cross-session context, and isolated branches. gstack launched on March 12 and hit 40,000 GitHub stars in under two weeks. The excitement is justified. Assigning AI agents specific roles instead of treating them as generic assistants produces measurably better output. I have been running a similar workflow since mid-2025 while building Luminik across product, GTM, and content systems. Instruction files with detailed coding conventions. A specs repo that agents reference every session. Multiple agents running in parallel across repos overnight. gstack formalizes part of what I arrived at through trial and error. The argument in one paragraph gstack is a good starting point. So is building your own system. Either way you end up dealing with the same three unsolved problems: writing down product rules, coordinating across sessions, and isolating parallel agent work. None of these are framework problems. They are operating discipline problems. ## Where the approaches overlap gstack’s core idea: when you give an AI agent a specific persona with constrained responsibilities (a reviewer who only reviews, a planner who only plans), the output improves. This is correct. It maps to how engineering organizations actually work. A QA engineer thinks differently from a product lead. gstack codifies the separation into slash commands like `/build`, `/review`, `/ship`. I arrived at the same principle from a different direction. I kept watching Claude Code produce code that compiled and passed checks but felt subtly wrong. The patterns drifted. Naming was inconsistent. Architecture choices were locally reasonable and globally incoherent. The fix was writing CLAUDE.md files: project-level instruction files that Claude Code reads at session start. Cursor gets equivalent instructions via .cursorrules. Where the agent gets its rules Role**Slash command**Planner, builder, reviewer, shipper. Repo**CLAUDE.md**Coding conventions and local boundaries. Product**Specs repo**Business rules, data model, workflows. Memory**Queryable brain**Cross-session context that survives a single run. gstack helps most with the first layer. My setup spends more effort on the later layers. ## Where gstack’s scope stops gstack covers the development lifecycle: think, plan, build, review, test, ship, reflect. Within that scope it is well-designed. `/plan-ceo-review` asking “what is the 10-star product hiding inside this request” is a genuinely useful forcing function. The engineering workflow is roughly 40% of what agents do for me. The other 60% is domain-specific work no generic framework can anticipate. | | What gstack handles | What stays a founder's problem | | ------------------- | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | Role separation | Planner, builder, reviewer, shipper as slash commands | Domain context (vocabulary, workflow boundaries, data-model rules) only exists if you write it down | | Per-session quality | Constraint plus persona produces sharper output | Cross-session memory needs a specs repo. The framework cannot maintain it for you. | | Single-agent flow | Sequential think-plan-build-review-test-ship loop | Parallel agent work needs branch isolation and scope discipline. Concurrency is on you. | Three problems the framework cannot fix on your behalf. They are the founder's problem regardless of which tools you pick. ## 1\. Domain context is harder to encode than code conventions My CLAUDE.md files do not just encode engineering patterns. They encode business logic. For Luminik that means event-pipeline vocabulary, workflow boundaries, data-model assumptions, and the rules that keep source, enrich, sequence, capture, and attribute from drifting into five disconnected features. None of that is generic engineering knowledge. It is product-specific and changes as the product learns. Engineering conventions are relatively stable. Error handling patterns do not change week to week. Domain context does. Keeping instruction files current is significant ongoing work that any framework-level approach leaves to the user. ## 2\. Cross-session coordination needs a specs repo gstack’s slash commands are stateless. Each one runs in its own context. That works for a single feature cycle. It does not work for a product under continuous development for months, where decisions made in November constrain what is possible in March. I maintain a dedicated specs repo: business requirements broken into workflows, data model definitions, integration contracts, UI/UX requirements, testing criteria. Every agent session references it. After every pull request merge, specs get updated. The moment specs drift from the codebase, agents start making decisions on outdated assumptions. Features still ship. Then something breaks because the agent was building against a system that no longer exists. The operating-boundary update I added later Part of the answer turned out to be a runtime shift, not a framework one. Moving approved context into a queryable layer shrinks the drift window from “whenever I remember to look” to “the next scheduled check.” That setup lives in [Separating agent work from founder work](dedicated-mac-mini-solo-startup.html). ## 3\. Parallel agents need isolation and roles gstack’s model is sequential: one agent, switching roles. My workflow runs multiple agents in parallel. On a typical evening, Cursor on a frontend feature, Claude Code on a backend refactor, a cloud-hosted agent on test cleanup. Each works in a separate repo or branch. Each produces a discrete pull request by morning. The constraint that matters most is isolation. If two agents touch overlapping parts of the codebase, I wake up to merge conflicts and divergent assumptions. The biggest time compression I have found in solo development comes from running three or four agents simultaneously on well-separated work, not from making one agent cycle through roles faster. ## A note on output metrics gstack’s README reports impressive output numbers. 10,000 to 20,000 lines per day. 600,000-plus lines in 60 days. These numbers are plausible with AI agents. I have had similar volume weeks. > My most valuable days on Luminik are often the ones with the fewest lines committed. Sometimes a customer conversation reveals that the spec is carrying the wrong assumption. Rewriting that assumption before code hardens around it can save weeks. Deciding what to build, maintaining system coherence, writing down product rules, manually testing UI flows that agents consistently get wrong. That is where my hours go. None of it shows up in LOC counters. ## What I would recommend to someone starting this workflow Four things I would name earlier next time - **Write instruction files that encode business logic, not just code style.** The real value came when I added product rules to my CLAUDE.md files: vocabulary, workflow boundaries, data-model assumptions, and the trade-offs agents should preserve. - **Keep a specs repo and update it after every merge.** Update discipline is the hard part. Skip one week and agents start building against stale assumptions. - **Structure the codebase for parallel agent work.** Clear module boundaries let multiple agents run on different parts of the system without colliding. - **Manually test everything.** Agents generate code fast. They miss edge cases consistently. At a 0-to-1 stage I want my eyes on every interaction path. Where this leaves us gstack is well-packaged, open source, and validates a pattern that works. The problems I described here (domain context encoding, cross-session coordination, parallel orchestration) exist regardless of which framework you use. They are the unsolved parts of this workflow. I expect them to get easier as tooling matures, but the founder still has to decide what the system should preserve. ![Prasad Subrahmanya](/assets/images/header/prasad.jpeg) ## Prasad Subrahmanya Builder and operator at Luminik. Built Aura at Bain to $3.6M ARR, co-founded Mainteny through its $2.7M seed, and helped build the initial product and team. [LinkedIn](https://linkedin.com/in/prasadus) [GitHub](https://github.com/prasadus92) [ Back to blog](/blog/) ## Filed under Solo builder OS gstackCLAUDE.mdspecsAI agents ## Related notes [**Separating agent work from founder work**Why I moved recurring agent work out of my daily workspace, what the boundary controls, and which approvals still stay with me.](/blog/dedicated-mac-mini-solo-startup.html)[**Alfred: how I run repeated work as a solo founder**How I use Alfred to turn repeated company work into plans, summaries, draft replies, and pull requests I can review before anything ships.](/blog/alfred-solo-founder-operating-system.html)[**The real cost of solo product engineering in 2026**The tools got cheaper and faster. The harder work is still product direction, instruction files, review, and knowing what needs a human decision.](/blog/building-alone-in-2026.html)