GStack Dev Workflow
/install gstack-workflow
Dev Workflow — Structured Development Sprint
A 6-phase development process that turns a vague idea into shipped code. Each phase has a clear role, a defined output, and feeds into the next. Run phases sequentially or skip ahead when context is clear.
Phases
| # | Phase | Role | Output |
|---|---|---|---|
| 1 | Think | YC Office Hours Coach | DESIGN.md |
| 2 | Plan | Eng Manager | PLAN.md |
| 3 | Build | Implementer | Code + Tests |
| 4 | Review | Staff Engineer | Review Report |
| 5 | Test | QA Lead | Bug Report + Fixes |
| 6 | Ship | Release Engineer | PR / Deploy |
How to Use
Full Sprint (recommended for new features)
# Start from scratch
"I want to build X" → run all 6 phases
# Or ask me:
"Run dev-workflow on [feature description]"
I will walk through each phase, spawning a focused subagent per phase with the right model and prompt.
Partial Sprint
Skip phases when you already have context:
- "Skip think, I have DESIGN.md" → start from Plan
- "Just review and ship this branch" → run Review → Test → Ship
- "I need a design review" → run Phase 2 (Plan) only
Single Phase
Any phase can run standalone:
/think— Reframe the problem, challenge assumptions, write DESIGN.md/plan— Architecture, data flow, test strategy, write PLAN.md/build— Implement from PLAN.md/review— Code review with auto-fix for obvious issues/test— Browser testing, regression tests, bug reports/ship— Sync, test, push, open PR
Phase Details
Phase 1: Think (YC Office Hours)
Goal: Reframe the problem before writing code.
Spawn a subagent (Sonnet) with the Think prompt from references/prompts.md. It will:
- Ask 6 forcing questions about the real pain, not the feature request
- Challenge the framing — "You said X but you actually need Y"
- Generate 3 implementation approaches with effort estimates
- Recommend the narrowest wedge to ship tomorrow
- Write
DESIGN.mdwith the distilled product vision
Key rule: Listen to the pain, not the feature request. The user says "daily briefing app" but means "personal chief of staff AI."
Phase 2: Plan (Eng Manager)
Goal: Lock architecture before building.
Spawn a subagent (Sonnet) with the Plan prompt. It reads DESIGN.md and produces PLAN.md containing:
- Architecture diagram (ASCII)
- Data flow and state machines
- File structure and module boundaries
- Test strategy and failure modes
- Milestone breakdown (what ships first)
Key rule: No code until the plan is approved. Challenge scope ruthlessly.
Phase 3: Build (Implementer)
Goal: Write code from PLAN.md.
Use the main session or spawn a subagent (Haiku for simple, Sonnet for complex). It reads PLAN.md and:
- Implements each milestone in order
- Writes tests alongside code (aim for >80% coverage)
- Commits atomically per milestone
- Updates PLAN.md with implementation notes
Key rule: Follow the plan. If the plan is wrong, update PLAN.md first, then code.
Phase 4: Review (Staff Engineer)
Goal: Find bugs that pass CI but blow up in production.
Spawn a subagent (Sonnet) with the Review prompt. It:
- Reads the diff against main/develop
- Catches logic errors, race conditions, edge cases
- Auto-fixes obvious issues (formatting, unused imports)
- Flags completeness gaps and security concerns
- Writes a review report
Key rule: Be paranoid. Assume the code will be hit by edge cases tomorrow.
Phase 5: Test (QA Lead)
Goal: Test like a user, not like a developer.
Spawn a subagent (Sonnet) with the Test prompt. It:
- Opens the app in a real browser (use
browsertool) - Clicks through every user flow
- Tests edge cases and error states
- Reports bugs with reproduction steps
- Auto-fixes and generates regression tests
Key rule: The user doesn't read code. Click the buttons. Break things.
Phase 6: Ship (Release Engineer)
Goal: One command to production.
Run in main session:
- Sync with remote (git pull/rebase)
- Run full test suite
- Audit test coverage
- Push and open PR
- Update project docs
Key rule: If tests fail, don't ship. Fix first.
Model Selection
| Phase | Model | Why |
|---|---|---|
| Think | Sonnet | Needs judgment to reframe problems |
| Plan | Sonnet | Architecture decisions need reasoning |
| Build | Haiku/Sonnet | Simple features → Haiku, complex → Sonnet |
| Review | Sonnet | Bug detection needs deep analysis |
| Test | Sonnet | Browser interaction needs context |
| Ship | Haiku | Mechanical execution |
Parallel Sprints
For large projects, run multiple sprints on different branches:
- Create feature branches for each sprint
- Spawn subagents per branch
- Each subagent works in isolation
- Review and merge sequentially
Max practical parallelism: 3-5 sprints (limited by context management).
Output Files
All phase outputs go to the project root:
DESIGN.md— Product vision from Think phasePLAN.md— Architecture and milestones from Plan phase- Review reports are written to stdout (capture in conversation)
- Test reports are written to stdout
Clean up output files after shipping if not needed long-term.
- Make sure OpenClaw is installed (local or Docker)
- Run the install command in chat:
/install gstack-workflow - After installation, invoke the skill by name or use
/gstack-workflow - Provide required inputs per the skill's parameter spec and get structured output
What is GStack Dev Workflow?
Structured development workflow inspired by Garry Tan's gstack. Use when the user wants to build a feature, start a project, do a code review, or ship code w... It is an AI Agent Skill for Claude Code / OpenClaw, with 130 downloads so far.
How do I install GStack Dev Workflow?
Run "/install gstack-workflow" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.
Is GStack Dev Workflow free?
Yes, GStack Dev Workflow is completely free, licensed under MIT-0. You can download, install and use it at no cost.
Which platforms does GStack Dev Workflow support?
GStack Dev Workflow is cross-platform and runs anywhere OpenClaw / Claude Code is available (cross-platform).
Who created GStack Dev Workflow?
It is built and maintained by Jahonn Ding (@jahonn); the current version is v1.0.0.